Skip to main content

Protection of Registrants Workshop – input welcomed

A Protection of Registrants’ Workshop will be held tomorrow, Monday 25 June 2007, at ICANN’s meeting in Puerto Rico at 1pm (EST) that will cover changes in the registrar market, a significant part of which will be suggested alterations to the Registrar Accreditation Agreement in response to the RegisterFly situation.

You can see the relevant webpage for the meeting here. Remote participants will be able to place comments in a chatroom during the meeting and to post comments. The comments will be reviewed and relevant responses introduced into the meeting by ICANN’s general manager of public participation. There is also a post on the public participation website that will be reviewed.

Below is a summary of the issues that will covered during the meeting.


Protections for Registrants – A Summary

Overview

Recent events in the gTLD name space demonstrate that procedural and contractual protections for registrants must be implemented.
The five major issues are:

  • The increase in numbers of gTLD registrars increase the likelihood of registrar failure
  • The anticipated consensus policy for delegating new gTLDs make a registry failure inevitable
  • The seven-year-old registrar accreditation agreement does not address market developments
  • The recent expansion in domain name registrations, registries, registrars and their associated business models require a proactive contractual compliance program

The program to protect registrants can be described by five separate efforts, some of which overlap.

  • Registrar data escrow
  • Proposed amendments to the registrars’ accreditation agreement (RAA)
  • Registry failover
  • Contractual compliance
  • Process for transfer of names in the event of registrar de-accreditation

Issue 1 – Registrar Data Escrow

Three milestones nearing completion by ICANN staff:

  • Published an escrow specifications document
  • Issued a Request for Proposals for retention of an escrow service provider. Seven applications were received; two are being considered.
  • Drafted an application to be used by prospective third party providers of escrow services. Draft is still being reviewed, but is scheduled for publication with the announcement of the selection of the data escrow provider.

Nearly 100% of gTLD registrars are expected to begin escrowing data by the close of 2007.
Staff is also working to resolve the added challenge created by the use of Whois privacy and proxy services through amendment of the Registrar Accreditation Agreement.

Issue 2 – Process for Amending the Registrar Accreditation Agreement

The current agreement with 900 registrars has not been changed for more than seven years because:

  • Changes can only be made through the consensus-based process of a supporting organization.
  • Changes are made so rarely that there is a reluctance to move forward due to a concern that important issues will be missed and therefore left unaddressed for many years.

The new process being suggested would streamline changes (still with supporting organisation endorsement) and make RAA review a regularly scheduled process so that issues missed in one round could be considered in a relatively short time frame.
The streamlined process is not intended to obviate the need for a policy development process. If the new procedure is not effective, as determined by the ICANN constituencies and community, a PDP on the agreement could be undertaken.

Issue 3 – Registry Failover

Triggered by the introduction of several new sTLDs and the expected designation of many new gTLDs through the anticipated GNSO consensus policy. The program for addressing these issues has published key documents describing work that will contribute to the implementation of a registry failover program.

  • Several well-developed registries have implemented competent contingency plans. ICANN will build on that work to create a best practices document to be adopted by new TLDs or included in the new registry agreements.
  • The core issue is defining ICANN’s role in the event of a registry failure. Each registry must have a contingency plan to maintain registry operations for a period of time so that:
    1. A replacement operator or sponsor can be found and a transfer effected, or
    2. Provide a notice period to registrants that the registry is closing.

Other questions and potential solutions to be discussed: To what extent should names be perpetual and what is ICANN’s role in ensuring registry operations?

Issue 4 – Contractual Compliance

Significant work completed this year:

  • Publishing and executing a program plan and executing according to schedule that includes a staffing and operational plan. Several proactive audits were completed and the next set of audits is planned.
  • These audits produced many warning and breach letters to registrars, many of whom are now in compliance. Past due payables have been drastically reduced. Other areas of contractual compliance can also be considered and prosecuted.

Issue 5 – De-accreditation Process

A detailed process is needed for the timing and steps to transfer names from a de-accredited registrar to one with ongoing operations. ICANN published a procedure to appoint a service provider to transfer names from the de-accredited party to a registrar of the registrant’s choosing.
Several questions have been raised regarding implementation details. An exercise should be undertaken to develop a process and test it through simulation. A different, market based approach may be the best approach to determining a “gaining” registrar.
This work is to be done in the first half of fiscal year 2007–08.

Comments

    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."