ICANN ICANN Email List Archives

[2gtld-evaluation]


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

NetChoice comment on Evaluation of mechanisms to prevent abusive registrations

  • To: <2gtld-evaluation@xxxxxxxxx>
  • Subject: NetChoice comment on Evaluation of mechanisms to prevent abusive registrations
  • From: Steve DelBianco <sdelbianco@xxxxxxxxxxxxx>
  • Date: Mon, 13 Apr 2009 19:14:44 -0400

The NetChoice Coalition
Steve DelBianco, Executive Director
1401 K St NW, Suite 502
Washington, DC  20005

13 April 2009
 
Dr. Paul Twomey, President
Mr. Peter Dengate Thrush, Chairman
Internet Corporation for Assigned Names and Numbers  (ICANN)
 
Submitted via email to 2gtld-evaluation@xxxxxxxxx  (PDF version attached)
 
Subject: Comment regarding gTLD Draft Applicant Guidebook version 2
 
In our comments regarding version 1 of the Draft Applicant Guidebook (DAG),
NetChoice endorsed the comments of the Business Constituency and other
groups raising similar concerns over abusive registrations.   We also
offered two suggested improvements to Evaluation question 31 of Module 2,
where applicants are to describe their approach to  ?minimize abusive
registrations and other activities that affect the legal rights of others.¹
 
To summarize, we recommended two changes in ICANN¹s approach to this
critical evaluation question:
 
1. Raise the curtain. Provide for greater transparency and stakeholder
inquiry of an applicant¹s proposed mechanisms to minimize abusive
registrations and other activities that affect the legal rights of others.
 
An essential aspect of transparency is to let stakeholders query applicants
about specifics and contingencies regarding their plan for rights
protection. ICANN must require applicants to provide substantive responses
to these queries, and to publish questions and responses for public review.
Only this level of transparency will enable the stakeholder community to
evaluate proposed mechanisms and compare them to superior mechanisms offered
by other applicants.
 
2. Raise the bar. Increase the criteria for earning a minimum acceptable
score on proposed policies to minimize abusive registrations.
 
A passing score of 1 on Question 31 should only be given to applicants whose
proposed mechanisms meet registry best practices for minimizing abusive
registrations.  The standard, or ?bar¹ for minimizing abusive registrations
should be set by looking at the best mechanisms employed by existing
registries or proposed by other registry applicants in the new round of
gTLDs. 
 
[see NetChoice comments at
<http://forum.icann.org/lists/gtld-evaluation/msg00017.html>  ]
 
At ICANN¹s Mexico City meeting, we learned that version 2 of the DAG does
not include requested changes to improve mechanisms for rights protection or
for minimizing abusive registrations. (Question 31, for instance, was not
amended in version 2, other than to re-number it as question 43.)   We are
now anticipating that rights protection mechanisms will be addressed in
future versions of the DAG, pending the work of the Implementation
Recommendation Team (IRT) and subsequent community review.
 
Hopefully, the IRT work will lead to new minimum rights protection
mechanisms for registry applicants. In DAG version 1, no minimum mechanisms
were required, and an applicant could receive a passing grade for merely
describing their intended mechanisms, even if they were likely to have
little effect in preventing abusive registrations.
 
We are therefore encouraged that the IRT will recommend specific mechanisms,
possibly including a global brand registry, thick Whois, rapid take-down,
etc.  Presumably, some level of implementation of these mechanisms will
survive through community review and board endorsement, and become minimum
requirements for new TLD applications.
 
But these mechanisms will be designed to fight existential threats from
today¹s abusive registration schemes, so some measures will soon become
obsolete or irrelevant.  Just as generals ask for weapons systems to win the
previous war, ICANN may end up with defense measures that won¹t work against
rapidly-evolving threats from notoriously clever criminal elements. ICANN
must move beyond static definitions of present mechanisms, and find a way to
accommodate dynamic proposals to fight new threats to consumers and brand
owners.
 
Moreover, it¹s inherent in the ICANN consensus process that these minimum
mechanisms will be less than consumers and brand owners want to have, and
more than aspiring registries want to offer.  Without a more adaptive and
dynamic process, ICANN's consensus approach will settle for minimum
mechanisms that will satisfy no one.
 
Consequently, the next version of the DAG is likely to include rights
protection requirements that are minimally effective against today¹s
threats, and not necessarily adaptive to tomorrow¹s threats.  For that
reason, we encourage ICANN to begin now with consideration of our
recommendations to improve the process for application evaluation in Module
2.  
 
Whatever mechanisms are eventually adopted as minimum requirements, ICANN
should be designing a more transparent and interactive process for letting
evaluators and stakeholders query applicants about how their proposed
mechanisms will work against emerging threats.
 
More important, our second recommendation envisions a process where
competing TLD applicants (and their registry operators) are rewarded for
proposing ever more effective and adaptive rights protection mechanisms.
New threats will evolve and vendors will respond with solutions much faster
than can be accommodated by ICANN¹s policy development process.
 
The need for these kinds of process improvements can best be demonstrated by
an actual example: 
 
About a dozen members of three stakeholder groups (Business, Intellectual
Property, and Registry Constituencies) met in Mexico City in March to
discuss rights protection mechanisms that current gTLD operators could offer
when they propose IDN (Internationalized Domain Name) versions of their
current TLDs. 
 
There¹s a real need for rights protection mechanisms for IDN translations
and transliterations of existing gTLDs, which are a special case that¹s not
likely to be addressed by the broader agenda of the IRT.  At the same time,
there is building pressure from ccTLD operators to launch their ?fast track¹
IDN ccTLDs while the gTLD Guidebook undergoes lengthy debate and revisions.
We believe that the billions of people who don¹t use the Latin alphabet
deserve to have access to IDN versions of common existing gTLDs -- not just
IDN versions of their ccTLD.
 
The specifics of this new mechanism are still under discussion, but the
general idea is that current registries want to propose multiple IDN
versions of the gTLDs they operate today.  Being aware of the concerns of
global brands and current domain name owners, some current gTLD registries
are contemplating unprecedented protections for current domain name
registrants. 
 
First, current gTLD registries may impose strict limits on the availability
of existing second-level address strings in any IDN versions of the gTLD
that they would operate.  Under this proposal, the registrant of a
NetChoice.org address would be the only person allowed to register
?NetChoice¹ in IDN versions of .org.
 
Second, this proposal would apply to IDN second-level domains as well. For
example, a registrant holding Korean and Arabic script versions of
?NetChoice¹ in the .org TLD would be the only one who could register those
strings in Korean and Arabic script versions of .org.
 
The idea is simple: domain holders would not be required to defensively
register current gTLD domain names in any IDN version of that TLD run by the
same registry.  
 
This is an actual example of innovation that could dramatically improve
rights protection and minimize user confusion in the case of IDN versions of
existing gTLDs.  There will undoubtedly be other examples of innovations
proposed by applicants seeking to improve their chances of winning a TLD
contract, especially when competing with other applicants for the same or
similar string.   Applicants could, for example, propose security and
stability mechanisms that exceed ICANN¹s present minimum requirements.
 
In the next version of the Guidebook, ICANN should design a process that
actively encourages applicants to offer more than the minimum requirements,
and then rewards that kind of initiative ­ with more than just an extra
point on a single evaluation question.
 
Another process improvement would be to harvest these innovations into an
evolving set of ?best practices¹ for aspiring registry operators.  Competing
applicants who meet the most practice mechanisms could be rewarded with
extra evaluation points.
 
For all of the above reasons, we wish to repeat our DAG version 1 comments
and ask that they be kept under active consideration for the next version of
the DAG. 
 
Steve DelBianco 
Executive Director, NetChoice

Attachment: NetChoice comment on gTLD DAGv2.pdf
Description: Adobe PDF Document



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

Privacy Policy | Terms of Service | Cookies Policy