Comment on Paragraph 1(d) of New Criteria for Sponsored TLDs

["Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>]

NeuStar, Inc., the Registry Operator for the .us country-code top-level domain and the ninety percent owner of NeuLevel, the Registry Operator for the .biz generic Top-Level Domain, would like to commend ICANN for its initial draft of Criteria to Be Used in the Selection of new Sponsored TLDs and would like to offer its  support for the introduction of a limited number of Sponsored TLDs during this extremely important Proof of Concept Phase. 

 

In serving as a current Registry Operator of several TLDs, NeuStar would like to offer some comments to Section 1(d), entitled "Assures continuity in the event of business failure."  As ICANN itself recognized, "it is critical that registry operations can continue through a business failure" and "Regular data escrow is a key pre-requisite to ensure this."  However, it goes on to state that "a new registry operator should provide "regular testing of independent third-party backup capabilities and means for quick transfer of operational responsibility in the event of business failure."

 

Although NeuStar understands ICANN's concerns that "financial status may or may not be a good predictor of future viability," it does not believe that ICANN should impose technical requirements as a substitute for predicting future viability.  More specifically NeuStar takes issue with ICANN requiring registry operators in essence to have back-up registry operations in the event that it fails or that registry operators  regularly test with independent back-up facilities.  Not only would such requirements if placed on existing unsponsored registry operators be unduly burdensome and cost prohibitive, but for Sponsored TLDs, which are usually more limited in scope, these requirements may have the unintended effect of providing a substantial barrier of entry for any new TLD. 

 

The feasibility of conducting tests between registry operators, or between a registry operator and a wholly independent entity has yet to be examined by the registry community, the ICANN or any technical standards body.  To include this as a requirement in the new round of TLDs is premature at best.  To the best of NeuStar's knowledge, few registry operators use the same technical protocol (i.e., RRP vs. EPP), or even if some do, they run different versions of that protocol (i.e., .biz uses EPP version 4, while .info uses EPP version 2).  In addition, even if there are two Registry Operators that use the same version of the same protocol, they can have employ their own extensions that are used to meet that TLDs particular requirements.  For example, both .BIZ and .US use EPP version 4, however, .US runs several extensions to that version which are needed to satisfy the United States Department of Commerce's Nexus Requirements.  Requiring testing with back-up facilities under such circumstances at this stage does not seem feasible. 

 

Domain name registrants in a particular TLD may need to be protected from a business failure or bankruptcy in that it would be highly undesirable to have businesses and/or websites immediately shut down because of such failure.  However, providing adequate data escrow will usually suffice in such events.   Adequate escrow of zone file data, coupled with the appropriate agreements providing for transfer of the zone file data in the event of bankruptcy or business failure will ensure that existing users of that particular TLD will be minimally affected in the short term by such failure.  With such data alone, any existing registry, or even the ICANN itself, can take over the DNS operations of the failed registry until such time as a new registry operator is found or until such TLD is phased out.  Although some registry functions, including the acceptance of new registrations may not be operational, such activities may not be feasible or even desirable at the time of a TLD or registry failure.

 

NeuStar believes that ICANN should separately consider the issue of what to do with a Sponsored TLD that fails.   Is it really appropriate for ICANN to require that a failing TLD continue to exist in perpetuity?  Can the ICANN truly require other registry operators to take over the operations of such a TLD?  Even if a registry operator (or the ICANN) could perform the technical registry operations, is it realistic to assume that a back-up registry can also continue the policy and other operations of the Registry?  Is it appropriate for ICANN to require that back-up registries continue to perform all registry operations for a TLD that continues to lose money or has very few registrations?  These are just a few of the many questions that need to be addressed prior to making anything other than escrow of registry data a requirement of a registry operator.

 

In summary, registrants in a particular TLD should be given adequate notice before that TLD fails and it should have ample opportunity to make other arrangements in such cases.  However, such notice and opportunity can be effectively be achieved with adequate escrow and procedures for the immediate transfer of zone file data to another operator (possibly even the ICANN itself) in the event of failure. To require anything further at this stage is not only not feasible, cost prohibitive and incredibly burdensome, but also provides a substantial barrier of entry for new registry operators.

 

We would be happy to answer any questions that you may have.  Thank you for this opportunity to provide our comments.  

 

 

Jeffrey J. Neuman, Esq.
Director, Law & Policy
NeuStar, Inc.
Loudoun Tech Center
46000 Center Oak Plaza
Building X
Sterling, VA 20166
p: (571) 434-5772
f:  (571) 434-5735
e-mail: Jeff.Neuman@Neustar.us

The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this e-mail message and any attachments hereto in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.