Registrar Competition: Testbed and Accreditation Update #2


To: Post-Testbed Registrars and Pending Applicants
From: Andrew McLaughlin, ICANN
Date: 14 June 1999
Re: Registrar Competition - Testbed and Accreditation Update #2

This memo is to give you an update on the status of ICANN's Registrar Accreditation Program and various activities in connection with the testing of the Shared Registry System (SRS). As you know, the SRS is being deployed by NSI as required by its agreement with the US Government to enable the opening the .com, .net, and .org TLDs to competition in registration services. In particular, I want to give some additional details on the procedures for a registrar's entry into competition that have become better defined as the testbed has progressed. We hope these details will assist you in your planning, so that you can begin offering registration services at the earliest possible time.

1. Status of the testbed.

As reported at ICANN's Berlin meeting, significant technical problems were encountered early in the testbed period. As a result, the first accredited registrar to offer competitive registration services (register.com) inaugurated its service last week -- six weeks into the two-month testbed period. Although NSI has declined to publicly explain the reasons for these delays, it appears that some aspects of the SRS did not initially work as expected, so that testbed registrars have experienced great difficulties in connecting to the SRS and implementing and testing their interfaces to the system.

Even register.com's system does not presently support important aspects of the SRS (such as transfer of domain name registrations and SLD holder data between registrars). We are hopeful, however, that the more basic technical problems with the SRS system have been resolved so that thorough testing can proceed promptly. We expect other testbed registrars to begin offering registration services within the next two weeks.

It is up to NSI and the US Department of Commerce to decide whether to extend the testbed period. As far as ICANN is aware, no decision has yet been made to extend the testbed. It should be kept in mind, however, that the US Government's Statement of Policy (a.k.a., the White Paper) calls for competition to be introduced in a manner that preserves the operational stability of the Internet. At the present time, there are unresolved technical problems with the SRS that should be solved before introduction of additional registrars on the system. While the testbed registrars are attempting to resolve those issues as promptly as possible, so that they themselves can offer the full range of registration services, it is possible that some extension of the testbed may become necessary.

2. NSI's Registrar Operations During and After the Testbed.

During the testbed period, NSI is being permitted to continue offering registration services on a legacy basis. This allows the new, competitive system for registrations to be introduced in a stable manner, while providing customers with access to the long-established mechanisms for registration. NSI may not substantially change the nature of its legacy services without approval from the US Government. This means that during the testbed period NSI and the testbed registrars are operating under somewhat different ground rules. The testbed registrars must operate in conformity with ICANN's registrar-accreditation policy, which allows each registrar to set its own pricing competitively, but which establishes various best practices for registrars including, for example, the requirement for prepayment of registration fees. NSI, on the other hand, is instead required to conform to the conditions of its cooperative agreement with the US Government, which does not require prepayment, but fixes NSI's prices at $70 for an initial, two- year registration and $35 for one-year renewals.

During the testbed period, NSI is adjusting its business and technical systems to separate its operation of the registry from its registrar business. Although earlier this month NSI was not using some aspects of the SRS in its own registrar business, it appears that NSI has recently been migrating its systems to employ the SRS.

After the conclusion of the testbed period, NSI will be required to operate its registry business on the same terms and conditions as all other registrars, including accreditation by ICANN.

3. Summary of Process for Gaining Access to SRS.

As the testbed has proceeded, details in the sequence of procedures for registrars have been better defined. For your planning purposes, those procedures may be summarized as follows:

a. Apply for accreditation by ICANN. The addressees of this memo have all completed this step.

b. Receive notification that you qualify for accreditation. Upon review and verification of the information in the application and resolution of any outstanding questions regarding the application, ICANN will inform the applicant whether its application qualified for accreditation. In addition to the five testbed registrars, thirty-seven applicants have completed this step. Ordinarily, this occurs within thirty days of the application.

c. Sign an accreditation agreement with ICANN. Signing the registrar accreditation agreement is required as the final step in becoming accredited by ICANN. The agreements are not yet available for signature by post-testbed registrars, but will be before the conclusion of the testbed period. The agreements will be sent in hard copy by mail and should be signed and returned promptly upon receipt.

d. Sign a confidentiality agreement with NSI. NSI requires that you sign a Confidentiality Agreement before you are given access to certain SRS software and documentation. See Exhibit C to the Registrar License and Agreement at [http://www.ntia.doc.gov/ntiahome/domainname/rla42199.htm].

e. Obtain a performance bond. The version of the Registrar License and Agreement currently approved for use by NSI during the testbed requires registrars to have in place a $100,000 performance bond before their license with NSI to use the SRS becomes effective. Although the burden on registrars associated with the requirement for a bond in the post-testbed period is a matter of concern to ICANN and the bonding requirement remains a subject of negotiations between NSI and the US Government, it would be prudent, in order to avoid unnecessary delays, for registrars to assume that this requirement may remain, and take steps to ensure that a bond will be promptly available to them.

f. Arrange to obtain an appropriate SSL license. Your system's communications with the SRS will employ a secure sockets layer interface. Testbed registrars have experienced compatability problems with certain SSL toolkits. These compatibility issues are still being investigated; we hope an accurate list of compatible toolkits will be available soon. Also under discussion is whether certificates generated by third-party Certificate Authorities will be required.

g. Prepare to sign a post-testbed Registrar License and Agreement with NSI. To date, only the terms of the NSI-Registrar License and Agreement for use in the testbed period have been agreed by NSI and the US Government. The terms of the post-testbed NSI-Registrar agreement remain to be negotiated by the U.S. Department of Commerce and NSI, and must be approved by the Department of Commerce. (Any comments you have on matters that should be negotiated should be sent to ICANN at [mclaughlin@icann.org] and [lltouton@jonesday.com] and will be passed on to the negotiators at the US Department of Commerce.)

h. Prepare to pay NSI's License Fee. NSI's SRS software license fee is currently a $10,000 one-time fee, but also remains subject to NSI's negotiation with and approval by the US Department of Commerce. Before you are allowed to connect with the SRS system, you will be required to pay this fee to NSI.

i. Obtain the SRS software and documentation from NSI. According to the ordinary procedures, you will receive the SRS software (including the APIs, a reference implementation for Java, and documentation) from NSI after you have: (1) signed the post-testbed Registrar License and Agreement, (2) signed the Confidentiality Agreement, and (3) paid the NSI license fee. To allow post-testbed registrars to obtain early access to the software and documentation so that they can begin working during the testbed period to prepare their systems, the US Department of Commerce has made special arrangements with NSI so that, beginning June 15, you can obtain the SRS software and documentation from NSI by: (1) signing the **testbed** Registrar License and Agreement (review section 6.1(a) and (d) of the agreement as to the effect of this); (2) signing a confidentiality agreement; and (3) paying the license fee. While these steps are not themselves sufficient to permit you to connect with the SRS, they will give you a head start in preparing to do so.

j. Prepare your systems to interface with the system. The C and Java languages are supported by the APIs. In addition to the direct registration functions to be implemented through the SRS, your system must also provide Whois (or similar) service for the names you will register for customers and must support the ICANN data escrow program.

k. Test your software. NSI has established a test platform for your use in testing your system's interoperability with the SRS. You will be given a userid and password for this system.

l. Verification of your system's functionality. NSI will verify that your system properly interfaces to the SRS.

m. Make arrangements with NSI for payment of registration fees. NSI will require that before you may actually register domain names through the SRS, you must make arrangements to pay the registry fees through a letter of credit, deposit account, or other credit terms acceptable to NSI.

n. Complete preparation of your agreement with customers and your domain-name dispute policy. The ICANN accreditation agreement provides some guidance on these requirements. At present, ICANN has endorsed the principle that registrars in the .com, .net, and .org TLDs should have a uniform dispute resolution policy, but the details of the policy to be adopted by ICANN are under consideration and will not be finalized until at least August. In the meantime, each registrar is required to adopt its own policy for use in its registration operations unitl the ICANN policy is finalized. The testbed registrars have been working together on a voluntary basis to formulate a common interim dispute resolution policy. You should soon receive a copy of a draft of that policy from register.com, which is coordinating the drafting effort, offering you an opportunity to comment.

o. Inaugurate your service. After the above steps have been completed, you should be in a position to begin offering services to the public.

4. Current Whois Situation

The introduction of the SRS has resulted in the reformulation of Whois service for the .com, .net, and .org TLDs. Partly because these changes have not been understood by the Internet user community, significant confusion has resulted. This confusion has been compounded by technical issues involving the sequence of transition to the SRS. In brief terms, NSI is providing a registry-level Whois service (web interface available at www.nsiregistry.com) that basically gives the domain name, the sponsoring registrar, and the nameservers for all SLDs registered in the .com, .net, and .org TLDs. Under NSI's technical plan, each registrar is to provide registrar-level Whois service giving additional details (e.g., SLD holder's name and technical contacts) **as to the names it sponsors only**. (NSI's registrar-level Whois service is currently located at internic.net and netsol.com.) While ICANN does not believe that this is a satisfactory long-term solution, it is the situation that NSI has imposed for the short term. ICANN plans to provide more detailed information in a later memo. In the meantime, those of you providing Whois service in your reseller operations may wish to adjust the service to minimize public confusion.

5. DNSO Registrar Constituency

As mentioned in my May 13 memo, one important way for registrars to have input into decisions affecting their interests is the Registrar Constituency group of ICANN's Domain Name Supporting Organization (DNSO). That constituency was provisionally recognized by the ICANN Board of Directors at its recent Berlin meeting, and is attempting to give voice to the concerns of current and prospective competitive registrars. For more information, contact the registrar consitiuency group's acting secretatiat, Michael D. Palage of InfoNetworks at mpalage@ipwarehouse.com.

6. ICANN Registrar Web Pages

ICANN has posted a revised set of registrar and accreditation web pages at [http://www.icann.org/registrars/accreditation.html]. Since you have all navigated the process of applying for registrar accreditation--and because many of you are, or employ, experienced web designers--we encourage you to look at those pages and pass on any suggestions you might have for improvement. In addition, you should be sure to check your company's entry on the listing of post-testbed registrars at [http://www.icann.org/registrars/accreditation-qualified-list.html] to ensure that the description, link, and contact information are up-to-date.

7. Feedback Comments on ICANN accreditation should be addressed to Andrew McLaughlin at [mclaughlin@icann.org] and to Louis Touton at [lltouton@jonesday.com].

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

Page Updated 22-Feb-2003
©1999, 2003 The Internet Corporation for Assigned Names and Numbers. All rights reserved.