ICANN ICANN Email List Archives

[4gtld-guide]


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

Seltzer Comments on Draft Applicant Guidebook

  • To: 4gtld-guide@xxxxxxxxx
  • Subject: Seltzer Comments on Draft Applicant Guidebook
  • From: Wendy Seltzer <wendy@xxxxxxxxxxx>
  • Date: Wed, 21 Jul 2010 12:21:37 -0400

Below please find several comments on sections of Draft Applicant Guidebook v4. Where pagenumbers are indicated, they refer to sequentially numbered pages of the complete redline, <http://www.icann.org/en/topics/new-gtlds/draft-rfp-redline-28may10-en.pdf>


Decisions without appeal (Module 2 and general):
The currently described process includes three places where an applicant
or application can fail without opportunity for appeal or extended
review: the background check, string similarity, and DNS stability
tests. Without this missing procedural safeguard, applicants and ICANN are deprived of opportunity to correct errors. The lack of safety-valve of an appeal mechanism within the application process may leave ICANN with greater litigation exposure in the courts. I would recommend that in every case, the applicant have an opportunity within ICANN process to request reconsideration of an erroneous or adverse decision.

“Denial of service” via objections (Module 3):
The lack of standing restriction for “morality and public order”
objection opens applicants to the equivalent of a distributed denial of
service attack, whereby a well-funded opponent or astroturf group could
generate multiple complaints, delaying the application and taxing the
resources of the decision forum.  Along with the quick dismissal of
“frivolous or abusive” objections, the process should consider a means
of speedy dismissal of duplicative objections.

Board approval of registry agreements (Module 5):
While the Board is ultimately responsible for the decisions of the
corporation, I am concerned that the explicit requirement of Board
approval for each new registry agreement will add delay and uncertainty
to what should be made a routine process.  The Board is able to request
informational updates and to intervene against a harmful decision
without this procedural step.

Amendment Working Group composition (Registry Agreement 7.6(e)(iv)):
As all members of the wider GNSO community, particularly registrants,
may be directly affected by amendments to registry agreements, each GNSO
Stakeholder Groups should be guaranteed representation in the working
group convened to consider amendments; the addition of members beyond
registries should not be left to ICANN's discretion.

New WHOIS requirements (Spec. 4, 1.8):
This paragraph poses both substantive and procedural problems.
The bracketed language proposes additional requirements for exposure of
WHOIS data.  The requirement would place unwarranted additional burdens
on registries and registrants without corresponding benefits to the
community at-large.  Further, bracketed text buried deep in DAG4 is not
the appropriate place to make WHOIS policy

Additional nits:
2.1.5 regarding use of registry data (p. 289 of redline) seems to have
changed in meaning to say that the registry can permit misuse, but isn't
required to allow it!

Thank you for your consideration,

--Wendy Seltzer

--
Wendy Seltzer -- wendy@xxxxxxxxxxx
Fellow, Silicon Flatirons Center at University of Colorado Law School
Fellow, Berkman Center for Internet & Society at Harvard University
http://cyber.law.harvard.edu/seltzer.html
http://www.chillingeffects.org/
https://www.torproject.org/





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

Privacy Policy | Terms of Service | Cookies Policy