ICANN ICANN Email List Archives


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

Registrar Constituency Position on New gTLD Draft Applicant Guidebook

  • To: "gtld-guide@xxxxxxxxx" <gtld-guide@xxxxxxxxx>
  • Subject: Registrar Constituency Position on New gTLD Draft Applicant Guidebook
  • From: "Clarke D. Walton" <clarke.walton@xxxxxxxxxxxxxx>
  • Date: Mon, 15 Dec 2008 16:51:48 -0500

Registrar Constituency Position on New gTLD Draft Applicant Guidebook

                                                December 15, 2008


In November 2008, the members of the Registrar Constituency ("RC") were asked 
to provide feedback regarding ICANN's New gTLD Draft Applicant Guidebook ("gTLD 
Draft Guidebook").  This Position Paper captures the overall sentiment 
expressed by the RC members who provided feedback about this matter and seems 
to reflect the general sense of the RC.  However, due to time constraints, no 
formal vote regarding this Position Paper was taken.


The RC supports the timely introduction of new gTLDs.  The introduction of new 
gTLDs will foster competition at the registry level, which will help ICANN meet 
its core objective of promoting competition while ensuring the ongoing security 
and stability of the Internet.  The RC anticipates that the introduction of new 
gTLDs will have a positive effect on the ICANN community.  The RC recognizes 
that ICANN has committed significant resources to this initiative, and the RC 
shares ICANN's commitment to seeing the new gTLD process succeed.  Accordingly, 
after reviewing the gTLD Draft Guidebook, RC members have raised a variety of 

 1.  New gTLD Annual Fees Are Too High.

New gTLD fees should not be so high that they prohibit new registry operators 
from entering the market.  The proposed new gTLD annual fees (> $75,000 or 5% 
of revenues) are difficult to reconcile with ICANN's commitment to promote 
competition.  At the proposed annual fee level, niche registries serving 
specific communities may not be viable.  Additionally, the proposed new gTLD 
annual fees are difficult to justify when compared with annual fees other gTLD 
registries have recently paid.[1]  Greater annual fees are likely to be passed 
on to registrars and registrants, undermining the benefits of competition noted 
above.[2]  Moreover, in calculating the 5%, ICANN proposes to include "all 
bundled products or services that may be offered by Registry Operator and 
include or are offered in conjunction with a domain name registration."   ICANN 
fees should only be paid on domain registrations and not other value added 

Similarly, some RC Members argue that the proposed application fees are too 
high and cannot be justified at $185,000.  In light of previous application 
fees, as well as ICANN's stated objective to promote competition, some RC 
Members feel that the proposed application fees of $185,000 are excessive.  If 
it can be demonstrated that new gTLD program costs are sufficiently recovered 
during the first round of applications, the RC would like ICANN to commit to 
maintaining (or reducing) the application fees for subsequent application 

 1.  How Will ICANN Use Annual Fees to Protect Stability of Internet?

RC Members note the high Annual Fees for new gTLDs and question how ICANN 
intends to use those fees to ensure new gTLDs are successful.  RC Members 
desire clarification about how the new gTLD Annual Fees will be used to protect 
the stability of the Internet from failed registries.

 1.  Integral Contract Terms Need to Be Included in New gTLD Agreement.

The absence of several fundamental provisions in the new gTLD Agreement could 
negatively impact registrars and their registrants, as well as create 
artificial competitive disadvantages in the domain registration market.  These 

 *   ICANN must include the limit on the transactional component of the 
Variable Registry-Level Fee currently not to exceed $0.25 per Section 
7.2(c)(i).  This cap on ICANN fees is an important accountability measure.  
Without it, ICANN essentially could write itself a "blank check" at the expense 
of registries, registrars, and registrants.

 *   ICANN must include in its covenants with the new operators the same 
promises it has with its existing operators, including without limitation, the 
obligations to be open and transparent and to provide equitable treatment.

 *   ICANN should specify the subject matter limitation of consensus policies.  
This is important for registry operators and the broader community as it 
provides a contractual basis for determining what issues can be raised by a 
policy process.

 *   ICANN should mandate an explicit requirement of non-discriminatory access 
to Registry Services.  This is essential for competition. All existing registry 
operators are bound by such a non-discrimination clause.  The absence of this 
requirement could allow new operators to favor preferred resellers, to the 
detriment of other registrars and their registrants.  Without this requirement, 
registrants, registrars, and other registry operators whose contracts forbid 
discriminatory treatment would find themselves at a competitive disadvantage.

 *   ICANN must revise the draft agreement to strike its ability to change the 
contract terms unilaterally.  It is unprecedented to propose a unilateral 
change and have it ratified by the Board of Directors even if 2/3 of the 
Registry Constituency opposes the change.  This would undermine the foundation 
of ICANN's policy making model; bottom-up, consensus-based decision making 
based on the active solicitation of input from the community.

 1.  The RFP Should Be More Explicit in a Few Areas.

The proposed RFP document, while very comprehensive, should be more explicit in 
a few areas.  First, there should be a clearer distinction and explanation 
between an open and community based TLD.  Second, the withdrawal and refund 
policy should be delineated in the RFP with specificity.

 1.  Implementation of New gTLDs Must Not Delay Implementation of IDN gTLDs.

IDN TLD support is critically important to the greater adoption of the Internet 
in Europe and Asia. In light of ICANN's proposed timeline for implementation of 
new gTLDs, RC Members are concerned that implementation of IDN gTLDs may be 
delayed.  RC Members urge ICANN to implement new gTLDs without causing a delay 
in the implementation of IDN gTLDs.

 1.  Section 2.8 of The Proposed New gTLD Agreement ("Registrar Relations") 
Should Explicitly Require The Accredited Registrar Model.

Section 2.8 of the Proposed New gTLD Agreement concerning covenants of registry 
operators does not yet define registrar relations.  Rather, the Proposed New 
gTLD Agreement says that the Registrar Relations section is "TBD" and refers 
readers to the paper posted on ICANN's web site discussing registrar 
marketplace issues (the "CRAI Report").

In the RC's view, the Accredited Registrar model should be required regardless 
of how the vertical integration and separation issues are resolved.  The 
concept that registries must register names only through Accredited Registrars 
is one that does not depend on decisions regarding the CRAI Report.


The opinions expressed by the RC in this Position Paper should not be 
interpreted to reflect the individual opinion of any particular RC member.


[1] (a) VeriSign only paid $100,000 in .com fees in 2002 and $151,000 in 2005 
when it had 21MM+ and 38MM+ .coms under management, respectively;

(b) VeriSign paid less than 2% of their .com revenues in FY2008 ($8M on some 
68M .coms @ $6.00-$6.42);

(c) biz/info/org only pay a little over 2% of their revenues (currently $0.15 
on $6.42, $6.75 and $6.75, respectively).

[2] Some RC Members also believe that high evaluation and startup costs may 
increase the likelihood for registry failure. CORE has provided an alternative 
proposal regarding annual fees, which RC Members supporting this view would 
like ICANN to consider:  

Attachment: RC Position - gTLD Draft Applicant Guidebook v1-4.pdf
Description: RC Position - gTLD Draft Applicant Guidebook v1-4.pdf

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

Privacy Policy | Terms of Service | Cookies Policy