Summary of Comments Received: Proposed / Draft Registrar Disqualification Procedure

[Mike Zupke <Mike.Zupke@xxxxxxxxx>]

Proposed / Draft Registrar Disqualification Procedure
Summary of Comments Received 
Comment period: 27 February 2009 through 28 May 2009

Background: The Statement of Registrar Accreditation Policy 
(http://www.icann.org/en/registrars/policy_statement.html) establishes the 
standards applied by ICANN in granting gTLD registrar accreditation.  In 
addition to setting minimum qualifications, the policy describes "matters 
potentially leading to ineligibility" for accreditation, including 
disqualification of a "registrar or registry administrator, or any officer, 
director, manager, employee, or owner (including beneficial owners) from being 
an ICANN-accredited registrar or registry administrator" in accordance with 
procedures established by ICANN.  The Registrar Disqualification Procedure 
("RDP") would establish and formalize ICANN's procedures for registrar 
disqualification.  

As part of its ongoing efforts to enhance protections for registrants, ICANN 
recently implemented a revised Registrar Accreditation Agreement ("RAA") 
following its approval by the Generic Names Supporting Organization and 
adoption by the ICANN Board of Directors.  (See 
http://www.icann.org/en/topics/raa.)  The 2009 RAA includes several new 
provisions to ensure registrar compliance with ICANN obligations and policies, 
as well as provide enhanced protections for registrants, including new 
provisions that are similar to some of the suggestions received in this public 
comment process.   As of 24 November 2009, ICANN reported that 88% of all gTLD 
registrations were covered by the 2009 RAA, in large part, due to the voluntary 
early adoption of the revised agreement by registrars.  Efforts are currently 
underway within the GNSO to consider and potentially implement further 
amendments to the RAA.

The posted draft RDP contained six substantive sections.  The comments received 
are summarized below under the most applicable section heading, with general or 
non-section-specific comments included at the end.  ICANN staff will consider 
this feedback in light of the additional protections afforded by the 2009 RAA 
and ongoing RAA amendment efforts before proceeding with any implementation.


Section One: Circumstances that May Trigger the RDP

- Triggering Actions should generally have been voluntarily or knowingly 
caused.  An involuntary or accidental action that threatens or compromises the 
security or stability of the DNS should not trigger the RDP.  (Sect. 1.2.5)

- If termination of a registry-registrar agreement ("RRA") due to material 
breach by the registrar is a Triggering Action under the RDP, "precedence [is 
given] to the registry position in all situations" even though the purported 
breach may be disputed by the registrar.  (Sect. 1.2.3)

- Termination of an RRA would not be an effective Triggering Action unless the 
registries have an obligation to report all material breaches of the RRA to 
ICANN.  (Sect. 1.2.3)

- As Triggering Actions, acts that threaten or compromise the security or 
stability of the DNS should only trigger the RDP if they were committed 
intentionally, knowingly, or maliciously.  (Sect. 1.2.5)

- It is unclear whether a third-party or representative of a harmed group could 
submit evidence and request initiation of the RDP (i.e., request 
disqualification of an individual or entity); such a process should be built 
into the RDP in order to protect against harms to registrants that are not 
matters within the Registrar Accreditation Agreement, provided that it could 
not readily be used for frivolous claims.

- A referee should be called upon to resolve complaints of harm by registrars 
to Internet users (such as, the harm in providing DNS service for fast-flux 
botnets or failing to respond to complaints of DNS abuse) in a procedure 
similar to the Uniform Domain Name Dispute Resolution Policy.

- Although the Statement of Accreditation Policy permits ICANN to refuse to 
accredit a registrar-applicant on the basis criminal convictions, adjudications 
of fraud, and similar misconduct, none is a Triggering Action under the RDP.  
The list of Triggering Actions should be expanded to include any occurrence 
listed in section IB3 of the Statement of Accreditation Policy ("Matters 
Potentially Leading to Ineligibility") and the RAA should be amended to require 
registrars to report such occurrences to ICANN.

- The list of Triggering Actions should comprehensively cover the range of 
registrar misconduct that threatens significant harm to registrants, even 
though such misconduct might not constitute a breach of the RAA or threaten or 
compromise the security or stability of the DNS.  (Sect. 1.2)

- If (a) a registrar is engaged in cybersquatting activity or (b) its director, 
officer, employee or others associated with a registrar is engaged in 
cybersquatting activity and if ICANN determines that (i) such cybersquatting 
activity was a result of registrar's failure to maintain appropriate policies 
to prevent such activity or to take appropriate precautionary measures to 
remedy such activity; (ii) such cybersquatting activity appears to be a pattern 
or practice or (iii) based on such factors like the size of the registrar or 
the control exerted by the principals of the registrar, the activities of 
directors, officers, employees or others associated with a registrar are the 
same as the acts of the registrar itself, should constitute a Triggering 
Action.  (Sect. 1.2)

- The failure by a registrar to follow applicable laws, as specified in section 
3.7.2 of the Registrar Accreditation Agreement, should be a Triggering Action.  
(Sect. 1.2)


Section Two: People and Entities Potentially Subject to Disqualification

- Employees who have no knowledge of the bad actions of their employer should 
not be subject to disqualification.  (Sect. 2.1.2)

- ICANN should disqualify individuals and entities who are truly culpable and 
in a position to benefit, not those who are minimally involved in a Triggering 
Action.  In order to avoid disqualifying individuals who might not have even 
had knowledge of a Triggering Action, individuals should only be disqualified 
when (a) they have knowledge and awareness of the Triggering Action; and (b) 
the ability to remedy the Triggering Action during the prescribed cure period, 
but failed to do so; and (c) derived some personal benefit from the Triggering 
Action.  

- Under the current version of the RDP, the improper actions of one registrar 
employee or contractor could jeopardize a registrar's accreditation. 

- Registrars should be contractually obligated to notify ICANN of all changes 
to its directors, officers, owners, and senior managers, and provide full 
contact information for each of them.


Section Three: Determination of Disqualification

- Greater specificity or examples of the acts that could lead to 
disqualification under the RDP is necessary.  (Sect. 3.1)

- Disqualification may be appropriate where there is harm to ICANN (e.g., 
routinely permitting inaccurate Whois data), harm to registries (e.g., 
permitting abuse of a large number of domains in a particular TLD to the point 
that a registry's value is potentially irreparably diminished), or harm to 
registrants (e.g., making transfers unconscionably difficult, tricking 
registrants into transferring domains, and failing to forward email when acting 
as Whois proxy/privacy service).  (Sect. 3.2)

- The phrases "permanent or irreparable harm to registrants" and "reckless 
disregard" are unclear and should be further defined.  (Sect. 3.1.1 and 3.1.3)

- The harm registrars can carry out most often is to Internet users, not 
registrants or the DNS (e.g., by allowing fast-flux botnets and hosting 
phishing sites).  An individual or entity should be subject to disqualification 
where its "repeated and willful inaction compromised or threatened the security 
of a wide-group [of] Internet users, specifically: personal, private, 
financial, and medical information."  (Sect. 3.1)

- Disqualification of a former registrar owner who sold its interest in the 
registrar to another party, for the bad acts of the succeeding owner, would 
unfairly penalize the former owner.  (Sect. 3.2.3)

- A former registrar ownership should not be immune for its own bad acts solely 
because it sold the registrar.  (Sect. 3.2.3)

- A former registrar owner should only be disqualified where specific evidence 
exists of its bad faith actions.  (Sect. 3.2.3)

- The liabilities of a seller of a registrar should be left to principles of 
contract law and negotiated between buyer and seller of the registrar.  (Sect. 
3.2.3)

- Disqualification should only be applied to the individuals who meet the 
disqualifying; imputation to others may unfairly penalize good faith registrar 
operators and community participants.  (Sect. 3.2)

- The heading of section 3.1 should be revised by removing the word "direct" to 
avoid the complication of establishing the involvement of disqualifying acts by 
various entities and individuals.  (Sect. 3.1)

- The RDP should be clear that it allows ICANN to take exculpatory or 
mitigating circumstances into account and could choose not to disqualify an 
individual or entity.  (Sect. 3.1)


Section Four: Duration of Disqualification

- It is unclear which of the listed considerations for duration of 
disqualification are mitigating factors and which are exacerbating factors.  
(Sect. 4.2)

- Section 4.1 of the draft RDP seems to establish a 1-year minimum period of 
disqualification, so the implication of mitigating and exacerbating 
circumstances should be more clear.  (Sect. 4.1 & 4.2)

- Further clarification of phrases such as "duration and pattern" is 
recommended.  (Sect. 4.2.5)

- The phrase "harm to registrants" should be clarified.  (Sect. 4.2.1)


Section Five: Communication and Review of Disqualification Decision

- Publication of disqualifications is a good idea, but must be done carefully 
to avoid claims of defamation.  (Sect. 5.3)

- Publication of the names of disqualified individuals or entities could create 
an unnecessarily high litigation risk to ICANN.  (Sect. 5.3)

- Instead of publishing a list of disqualified individuals and entities 
publicly, ICANN could publish the list to a site accessible only to registrars, 
to help them avoid hiring disqualified individuals.  (Sect. 5.3)

- Where a disqualified individual or entity seeks review of the 
disqualification under the RDP, publication of the disqualification should be 
stayed until the review is complete.  (Sect. 5.2)

- Where a disqualification decision is contested through a review process 
outside the RDP (e.g., through a complaint to the ICANN Ombudsman), publication 
of the disqualification should be stayed until the review is complete.  (Sect. 
5.2)

- The RDP should be clear about the number of review requests that can be made 
by a disqualified individual or entity.  (Sect. 5.2)

- The RDP should be clear about when a review request may be made, and what the 
review criteria are.  (Sect. 5.2)

- The RDP does not specify the time frame during which ICANN would conduct a 
review of a disqualification decision, if requested.  (Sect. 5.2)

- Individuals or entities potentially subject to disqualification under the RDP 
should be informed of the potential disqualification before a disqualification 
decision is made.  (Sect. 5.1)

- Some operational limits should be placed on disqualified registrars during 
the review period if a review of the disqualification decision is requested.  
(Sect. 5.2)

- Publication of a list of disqualified individuals may impugn their 
professional reputations, even though the individual may dispute the 
circumstances of the disqualification.  An (unspecified) alternative may exist. 
 (Sect. 5.3)

- Individuals who will be involved in disqualification decision-making and 
decision-reviews should be identified.  (Sect. 5.1 & 5.2)

- It was questioned whether the reviewers of a disqualification decision should 
be different than the original disqualification decision-makers.  (Sect. 5.2)

- More details about decision-making and review processes should be provided in 
the RDP. 

- A third-party arbitrator or referee should handle review requests.

- An authority in administrative law could provide guidance into ensuring the 
RDP and its review mechanism are fair.


Other Comments

- Terms that are defined in the "background" section of the posted document 
should be defined within the RDP itself.  

- Process should be swift and strong enough to replace other anti-spam measures.

- Registrars must be accountable for their actions and the actions of their 
registrants.

- The RDP should also cover affiliates of registrars. 

- The RDP is only a first step toward enhanced protection of Internet users.

- It is perceived that the RDP could serve to disqualify an individual from 
working in his or her field of expertise and that this poses a legal risk to 
ICANN. 

- ICANN should reevaluate whether all elements of the draft RDP are necessary 
in light of the adoption of a revised registrar accreditation agreement.

- The significance of disqualification is unclear: e.g., would it apply upon 
application for renewal or assignment of a Registrar Accreditation Agreement, 
or only to new accreditation applications?

- The RDP should disqualify individuals and entities from entering into any 
contractual relationships with ICANN, not just the Registrar Accreditation 
Agreement. 

- The RDP should spell out ICANN's ability to seek further information from 
registrars subject to potential disqualification. 

- ICANN should make a public database available via the web that includes all 
complaints, documents, and processes related to all Triggering Actions and 
resulting invocations of the RDP. 

- The language of the RDP should clarify how disqualification or 
de-accreditation of a registrar might affect any monetary remedies an 
interested party, such as a trademark owner, might have in respect to that 
registrar.