Skip to main content

.NET Agreement Update

Following the request-for-proposal process and re-bid set out in the expired .NET agreement, which included an independent evaluation of applications for the operation the .NET registry (see, http://www.icann.org/tlds/dotnet-reassignment/dotnet-general.htm) and subsequent negotiations, the ICANN Board approved a Registry Agreement executed by ICANN and VeriSign. The registrar community, along with other members of the ICANN community, voiced complaints concerning the content of the .NET agreement at the Luxembourg meetings and in postings thereafter. VeriSign issued a statement agreeing to renegotiate terms relating to the wholesale price of names to registrars and the terms Registry-Registrar agreement. Subsequent to that, VeriSign extended the period for the submission of comments concerning those contract terms.

Since that time, ICANN staff have been contacting registrars in order to find areas of agreement across the registrar constituency with the intent to relate the registrar positions to VeriSign in the re-negotiation of the .NET agreement. In addition, the registrar constituency has appointed a task force to synthesize the constituency position regarding the Registry-Registrar agreement. There have also been preliminary discussions between ICANN and VeriSign regarding the input to date and how the re-opened negotiation points might be resolved.

A summary of these discussions is below, organized by contractual issue.

1) PRICE PER NAME

The price per name (the price VeriSign charges the registrars) in the recently executed .NET agreement is $4.25 per name. However, the contract provides that the price controls or "price cap" be removed in January 2007. Since that time, discussions with registrars have yielded a wide variety of positions. As indicated, there is not a consensus among registrars regarding price but rather a "continuum" of positions. Here are examples of the individual registrar positions:

  1. The price must be maintained at $4.25 and not changed for the remainder of the contract term of six years.
  2. The price could rise over time, limited by a fixed escalation percentage (10%) and not to exceed $6 per name over the six-year period of the agreement.
  3. The price could rise over time, limited by a fixed escalation percentage.
  4. It may be acceptable to lift price controls so long as ICANN starts adding TLDs immediately, rapidly and in (relatively) great number in order to create competition.
  5. Price controls are somewhat important to registrars in the .NET agreement but ICANN and VeriSign should provide assurances that price controls will be included in the renegotiation of the .COM agreement.

VeriSign has been approached directly by individual registrars and reacted positively to some aspects of price controls without committing to a formula or amount.

2) REGISTRY-REGISTRAR AGREEMENT (RRA)

The approved .NET agreement called for a registrar consultation period prior to the new RRA becoming effective. In the Mar del Plata and Luxembourg meetings, Registrars requested that they have the opportunity to negotiate terms of the RRA. The period for discussion has been extended by VeriSign at ICANN request. The registrar constituency created a task force that designated Jon Nevett of NSI to synthesize the various registrar constituency members’ positions on the RRA into a single document. It is reported that all registrars have had an opportunity to participate on the task force, and have had an opportunity to review the Task Force document. That document was presented to ICANN on 19 August in a conference call among Jon Nevett, Ross Raeder (Tucows), John Jeffrey (ICANN) and Kurt Pritz (ICANN). (An earlier conference call among Jon Nevett, Tim Ruiz (GoDaddy), John Jeffrey and Kurt Pritz provided some indication of potential suggestions.) The document has been forwarded to VeriSign. Follow-up discussions among the registrar task force representatives, VeriSign and ICANN are being arranged to discuss the RRA.

3) VOLUME DISCOUNTS

Historically, the .NET and .COM agreements were the only registry agreements not to permit volume discounts. (Provision for volume discounts were actually described in the main bodies of the .NET and .COM agreements but then removed by a clause in Appendix W.) The volume discounts were removed because VeriSign owned and operated the registries and the NSI registrar thereby providing the opportunity for favourable pricing terms for the in-house client. (See, http://www.icann.org/correspondence/lynn-letter-to-sclavos-31mar01.htm.) That condition no longer exists.

One registrar (potentially voicing the same opinion as many others) has voiced displeasure with the provision for volume discounts, citing that they may result in a barrier to entry for new and small registrars. Other registrars have signalled support or indifference. Preliminary conversations with VeriSign indicate to us that they wish to retain the right to provide volume discounts if the proper business rationale presents itself. The discussions with VeriSign thus far also indicate that volume discounts would be based upon incremental registrations that, in the scenarios presented to us, are likely to provide some opportunities to registrars regardless of size.

4) THE PROCESS FOR CONSIDERING NEW REGISTRY SERVICES AND RESTRICTIONS ON CONSENSUS POLICY

During the Luxembourg meeting, registrars indicated disagreement with the terms of the agreement that limited the effects of consensus policy for three years. Discussions with registrars since that time indicate that many registrars have come to an understanding that those limitations are generally restricted to the process for considering new registry services or areas described in previous agreements. There is also a general (but not universal) understanding that the process for considering new registry services in the .NET agreement essentially matches the GNSO developed policy for consideration of new registry services. Much of the disagreement in this area seems to have dissipated but some criticism remains. In its discussions with registrars, ICANN is working to demonstrate how the "funnel" will capture a wider range of offerings than the previous contract (and therefore provide better service and "protection" for registrars) and will also appropriately limit ICANN activity to its technical coordination mandate. Some registrars want ICANN to play a more regulatory role than exists in the ICANN formation documents or in the funnel.

CONCLUSION

As indicated above, there is a consensus among registrars in some areas and a continuum of opinions in other areas. VeriSign remains willing to reach accord on a few key terms consistent with some of the positions of the Registrars. ICANN will continue to work toward timely resolution of these issues. We plan to post updates and the revised agreement for public comment as soon as practicable.


More Announcements
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."