ICANN ICANN Email List Archives

[draft-registrar-dp]


<<< Chronological Index >>>    <<< Thread Index >>>

IPC comments on disqualification procedures

  • To: <draft-registrar-dp@xxxxxxxxx>
  • Subject: IPC comments on disqualification procedures
  • From: "Metalitz, Steven" <met@xxxxxxx>
  • Date: Thu, 28 May 2009 07:10:25 -0700

The Intellectual Property Constituency appreciates this opportunity to
comment on the Draft Registrar Disqualification Procedure (see
http://www.icann.org/en/public-comment/#prdp).   

IPC commends ICANN for developing and proposing this procedure.  In
general, our comments address how this proposed procedure relates to the
contractual obligations of accredited registrars, and to the enforcement
of those obligations.   In some instances, in order for the
disqualification procedure to be effective, some changes may be needed
to the underlying contractual obligations and ICANN's enforcement
processes.  

Triggering Actions

The draft procedure's list of triggering actions may be incomplete, and
also includes at least some occurrences of which ICANN might not
necessarily become aware.  

For example, under 1.2.3, a registrar's material breach of a
Registry-Registrar Agreement (RRA) with any gTLD registry, leading to
termination of the RRA, is a "triggering action" that should lead to
consideration of disqualification.  Is either the registry or the
registrar obligated to report any such termination to ICANN?    If not,
and if the registrar does not voluntarily "abandon" working with the
Registry in question (see RAA section 5.5), how would the termination
necessarily come to the attention of ICANN?  Point 1.2.3 is not likely
to work as intended in the absence of a clear contractual obligation for
all material breaches of the RRA to be reported to ICANN, presumably by
the registry.  

Notably, although criminal convictions or adjudications of fraud or
similar misconduct are grounds for ICANN to refuse to accredit an
registrar applicant (Statement of Registrar Accreditation Policy,
paragraph I.B.3), under the draft procedure such convictions or
adjudications are not "triggering actions" for the purposes of
disqualification after accreditation has occurred. Perhaps, in some
cases, when ICANN learns of these events, it will demand that the
registrar cure the breach (RAA section 5.3.3) by removing the convicted
or adjudicated person.  If the registrar refuses to do so, then point
1.2.2 would make this a "triggering action."  But why require this
indirect route to the same end?  The list of "triggering actions" should
be expanded to include any occurrence listed in paragraph I.B.3 of the
Statement of Registrar Accreditation Policy, and the RAA should be
amended to require an accredited registrar to report any such occurrence
to ICANN.  Otherwise, it is quite probable that ICANN will not be aware
of such occurrences, and the disqualification procedure will never be
invoked.    

Finally, ICANN should review the list of "triggering actions" to ensure
that it comprehensively covers the range of registrar misconduct that
threatens significant harm to registrants.  There may well be scenarios
in which registrants are harmed by registrar actions that do not
constitute a breach of the RAA  and do not meet the rather amorphous
standard of "threaten[ing] or compromis[ing] the security and stability
of the domain name system."   Some the actions described in section 3.1
may fit this description.  As other commenters have noted, ICANN should
not be powerless to disqualify bad actors in these scenarios.  

People and Entities Subject to Disqualification

Once a triggering event occurs, IPC agrees that ICANN should consider
(though not necessarily that it should conclude) disqualification of
registrar directors and officers, and, in appropriate cases, of
managers, employees, and owners.  The question is whether ICANN will
know who these people are, and how to contact them?  While the registrar
accreditation application requires the applicant to list all directors,
officers, "relevant managers," and owners of more than a five percent
interest, its obligation to keep this information current, and to
provide contact information for these people, is far less clear.  It is
also unclear whether the application question 9(iv) extends to
beneficial owners. In order for the threat of disqualification to be
meaningful and thus an incentive to avoid the occurrence of a
"triggering action," registrars should be contractually obligated to
inform ICANN of all changes to its directors, officers, owners, and
senior managers, and to provide full contact information on each of them
(and/or document the consent of each of them for the registrar to accept
service upon them of any notification under point 5.1 of the draft
procedure). 

Determination of Disqualification     

As some other commenters have noted, point 3.2.3 is ambiguous and should
be re-drafted.  If a registrar is owned by A during year 1, when a bad
act described in section 3.1  occurred, the fact that it sold the
registrar to B the next year should not immunize it from
disqualification. If, however, the bad act did not occur until year 2,
and there is no evidence of A's involvement in it, A should not be
disqualified.  

Other Comments

The draft procedure describes the circumstances under which it can or
must be invoked, but does not say who may invoke it.  It is apparently
assumed that only ICANN staff can initiate the process leading to
disqualification.  This should be spelled out.  Furthermore, provision
should be made for ICANN to receive, consider, and promptly act upon
complaints from third parties that a "triggering action" has occurred.
The procedure should also spell out  ICANN staff's ability to seek
further information from registrars subject to disqualification, and
from any third party, in carrying out the disqualification procedure.
Finally, as noted by previous commenters, the procedure could benefit
from clear definitions of several key terms.    
Respectfully submitted, 
Steve Metalitz, IPC president



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy