ICANN | Supplemental Question #9 to NeuStar (With Response)

Supplemental Question #9 to NeuStar (With Response)

Supplemental Question #9 to NeuStar (With Response)

Supplemental Question No. 9:
(posed to NeuStar on 9 September for response by 11 September 2002)

In section 2.2.3.2 of NeuStar's Response to the Evaluation of Technical Criteria by Gartner, Inc., you state:

2.2.3.2 Gartner also omitted credit for NeuStar’s fluency over other applicants when it came to the SRS protocol.

In reviewing the RFPs for fluency with registry-registrar protocols, Gartner also missed the fact that NeuStar is the only applicant to have authored and implemented an extension to the base protocol (i.e., EPP usTLD Extensions). usTLD Extensions added two additional parameters required for the .us registry. Implementing the usTLD extensions required significant coordination, documentation, development, and registrar support. This included:

Documenting the additional parameters at the IETF;

Deploying the new capabilities in the registry including the .us database;

Distributing an updated toolkit to the registrars;

Providing an OT&E environment for the registrars;

Supporting the registrars’ testing needs; and

Coordinating the process of going live with the new capabilities in a real-time landrush environment.

Gartner should have included this important experience in its evaluation of the Criterion. ICANN Staff should include this when drafting the final report to the ICANN Board.

In connection with this statement, please provide the following additional information:

[a] Please provide a citation to the specific portion of your proposal (as submitted by the 18 June 2002 deadline) that describes "the fact that NeuStar is the only applicant to have authored and implemented an extension to the base protocol (i.e., EPP usTLD Extensions)."

[b] No Internet-draft submission relating to "EPP usTLD Extensions" appears on the IETF Internet-Draft index, Provreg section. An individual Internet-draft submission was made by Hong Liu, Ning Zhang, Tom McGarry, Joseph Amsden, and Ayesha Damaraju entitled "New EPP Parameters for the usTLD" <http://www.ietf.org/internet-drafts/draft-liu-epp-ustld-00.txt> on 18 February 2002, but has been allowed to expire. Please provide a citation to the Internet-draft to which you refer. Please describe in detail your efforts to advance the EPP usTLD Extensions toward standards status within the IETF and to make those extensions available for adoption as a standard by the registry community.

[c] A review of the IETF Provreg working group's mailing list archive shows participation by technical personnel of VeriSign Global Registry Services (including authoring of all six of the working group's Internet-drafts); register.com, Afilias, RIRs, and several ccTLDs, in addition to participation by NeuStar. Is it NeuStar's contention that those participants, and the registry community generally, have not broadly contributed to the Provreg working group's efforts? Is it NeuStar's contention that the technical personnel of the other applicants are not well-versed with the EPP Internet-drafts?

Response to Supplemental Question No. 9:

NeuStar Response

Response to [a]. NeuStar made this statement in our response to the Gartner Evaluation Report to point out that Gartner did not give proper weighting for NeuStar's registry-registrar protocol fluency relative to other applicants. Gartner did not miss the specific assertion related to the EPP usTLD extensions. Although NeuStar's assertion regarding its EPP usTLD activities is factually correct, NeuStar should have referenced its EPP-related work which is documented in our proposal, Section C22, sub-heading The migration to EPP, where we state:

NeuStar has authored two drafts of the EPP protocol in the Provreg Working Group, the IETF Working Group responsible for EPP, and has participated in the crafting of all of the drafts produced in the working group.

This work was not given proper consideration in evaluating NeuStar's fluency with registry-registrar protocols.

In addition, NeuStar's comments regarding its operational experience were not given proper consideration. There is a detailed description of the .us launch at the end of Section C18, Attachment 2: ".us Transition and Launch". A review of these sections illustrates the significant effort required in managing the SRS interface and therefore its protocol. Consistent with Criteria 8, our experience in managing a large registry, which is dependent on the SRS protocol, demonstrates our "ability and commitment to support, function in, and adapt protocol changes in the shared registry system."

Response to [b]. The draft NeuStar referred to as “EPP usTLD Extensions” is indeed the same draft referenced in ICANN’s question to NeuStar, "New EPP Parameters for the usTLD". This document was created by NeuStar as an Informational draft to document our implementation of these parameters for the rollout of .us and was not the result of WG action. According to The Internet Standards Process (RFC 2026), Informational drafts that were not the result of a WG action are submitted to the RFC Editor – not the WG. Section 4.2.3 of RFC 2026 The Internet Standards Process states:

Procedures for Experimental and Informational RFCs - Unless they are the result of IETF Working Group action, documents intended to be published with Experimental or Informational status should be submitted directly to the RFC Editor.

Therefore, it would not appear "on the IETF Internet-Draft index, Provreg section".

However, NeuStar wanted to receive the input of the Provreg WG and wanted the Provreg WG to have the benefit of reviewing one possible method for adding extensions to EPP. Even though it was not necessary for the Provreg WG to review the draft, we submitted it to the discussion list for these purposes.

NeuStar allowed this draft to expire because we are in the process of modifying it to be consistent with the evolving concepts by which extensions to the EPP protocol are documented and implemented. The expiration of industry standards documents is a common step in any standards process. This option exists, among other reasons, to allow for situations like the one described herein.

The new draft will also be an Informational draft and will be specific to the .us registry. NeuStar will progress the new Informational draft to RFC status. However, we have no plans of seeking standard status. In addition, since these parameters are only pertinent to the .us registry, it is unlikely they will be of interest to the broader registry community.

EPP was specifically designed to include extensions to the base protocol. The existing draft provided the Provreg WG, as well as NeuStar, with a better understanding of the various methods for adding EPP extensions. Prior to NeuStar’s document, there was no clear example of how EPP extensions could be added. In response to that draft, the WG recognized the need to develop a formal process for documenting and implementing future EPP extensions. This draft contributed to the process that resulted in the recently released EPP WG draft, Guidelines for Extending the Extensible Provisioning Protocol.

NeuStar has already written a revised draft for internal review with regard to the usTLD extensions that takes into account many of the concepts we anticipated would be included in a draft dealing with extensions. We have not submitted a revised version of the draft to the IETF because we will plan its release to integrate with other work, as necessary, within the operations of the registry such as:

Deploying the new capabilities in the registry;

Notifying the registrars;

Distributing an updated toolkit to the registrars;

Providing an OT&E environment for the registrars;

Supporting the registrars’ testing needs; and

Coordinating the cutover process.

NeuStar will submit the new draft in order to advance the EPP usTLD Extensions toward RFC status.

Response to [c]. This was definitely not NeuStar's contention.

Note: Public submissions relevant to Supplemental Question #9 were sent to the public comment forum on 11 and 16 September 2002..

Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.