2017-09-07 New gTLD Subsequent Procedures PDP Work Track 2

Notes/ Action Items

. SOI Updates

 - No updates

3. CC2 Comments: Registrant Protections (continued) - Background Checks

- Hoping to get feedback from ICANN Org on their experience with background checks and areas for future improvements.

CC2 Question 2.3.3 (beginning on slide 20)

-- RySG - maintain current criteria for background screening

-- John Poole - background requirements should be stricter.

-- Valideus - applicants that are publicly traded corporations listed and in good standing on any of the worlds largest 25 stock exchanges should 

not be required to provide detailed information on the entity, officers, directors, and major shareholders if it will not be subject to background screening. 

-- BRG - Background check requirements not appropriate for all different types of applicants, especially 

things like personal address, DOB, etc. Same level of info for company directors as appears on corporate web sites should be adequate.

-- Jannik Skou - geo TLDs and applicants listed on stock exchanges should not go through criminal background

 checks - already done by public authorities

-- Michael F. - difficult, at least in APAC, to negotiate changes to applicant information. Did not always seem to be consistent.

-- Paul - The standards of background checks don't mean anything if ICANN doesn't do anything with them]

(e.g., evidence of excessive cybersquatting activity). There should a formal response process when a complaint to the process is filed.

- The standards should be different for publicly traded companies and other types of companies that have 

 internal governance enforced by other third parties. Could apply to the financial review as well, especially as it relates to dot Brands.

- Streamlining this process could also lower costs.

-- Alan - Not all applicants are equal, do differentiating may be ok. Is there another way to achieve the goals without 

ICANN having to perform the background check itself. Challenges and ability to conduct reviews are different across the world.

-- Michael F. - Opinions and laws on privacy are vastly different in the world. Availability of relevant information is impacted by this.

-- Greg - Can waive background checks if there are existing mechanisms, that might be more rigourous, already in place 

(e.g., conducted internally or through a third party). There might be well recognized existing processes or practices that 

ICANN could rely on. Need to be flexible to other cultural norms rather than forcing applicants to confirm to ICANN's rules.

-- Jim - Will GDPR, or other privacy laws, impact the level of information that ICANN can ask for? Michael F. Could depend on 

purpose and usage.

-- CLO - Echoing Heather, relying on public information is most efficient and transparent. In certain locales and jurisdictions,

 there may be instability that will impact accessibility and and quality of information. The level of comfort is different in different

 locales as well. Might be helpful to again consider what purpose or goal is.

-- Paul - Geo TLDs, run by public authorities, presumably do their own due diligence. Lower level of review by ICANN might be warranted.

ACTION ITEM - Determine how GDPR might impact ICANN's ability to conduct background checks. See if that can or is already an 

element of the legal opinion it's seeking now.

-- RySG - Barring cybersquatters makes sense. However, breach of RA or RAA should not, de facto, lead to disqualification.

-- Valideus - Cybersuatting or registrants losing two or more UDRPs should not be officer of registry.

-- Jannik Skou - 

-- Nominet - An applicant who operates a failed gTLD should be scrutinized carefully, but each application should not necessarily 

be considered dependent.

-- Alan - How should the policy be adjusted based on the comments being reviewed?

-- Paul - Claim is different than abjudication of breach. Or cured breach. There are breaches related to paying bills. Need to 

determine what level of breach should warrant action.

ACTION ITEM - need to determine what types of breaches would warrant action. Maybe reach out to RySG

-- Afilias - advocated for ensuring ICANN is aware of changes in mgmt structure and integrating compliance in to application review 

process, since they are aware of past and current performance.

-- Alan - Compliance should be able to identify past bad actors but may be reluctant to play this role. More about enforcing contracts.

-- BRG - due diligence should performed an early stage during the application process. ICANN may have to repeat process prior 

to signing RA. 

- Michael - This did occur

-- John Poole- why screen twice 

-- RySG - At the time of application, changes, and post-contracting cchanges.

-- ALAC - at application and at time of contract signing

ACTION ITEM - were any applicants disqualified by background screening?

Michael - background info needed upon changes, throughout process, during the 2012 round. Also had to be performed

 twice in many cases (e.g., at application and prior to contracting).