Skip to main content

Implementation Notes

17 June 2019 Update

Following several months of discussion, the RySG RSEP Improvements Discussion Group and the ICANN organization agreed to a set of operational improvements to enable efficiencies and predictability within the process while adhering to the Policy. The process changes are reflected in the updated RSEP Implementation Notes, effective 17 June 2019. This version of the Implementation Notes is now archived.

Please note that the English language version of all translated content and documents are the official versions and that translations in other languages are for informational purposes only.

This is a synopsis of the process and is intended to provide high-level information regarding the policy implementation of the Registry Services Evaluation Policy ("the Policy").

Process for new registry services

On 8 November 2005 the ICANN Board directed implementation of the process for considering requests for new registry services and stated that the process shall be guided by the provisions in the .NET Registry Agreement concerning definitions of registry services and confidentiality.

Step 1

gTLD registry operators and sponsoring organizations may submit requests for new registry services to ICANN. The process is designed to encourage communication between ICANN and the registry operator or registry sponsoring organization before requests are submitted. Once a request has been submitted, ICANN will confirm receipt of the request and conduct a completeness review.

Online tool for submitting requests for new registry services

A secure web-based application is under development and will be made available that will allow gTLD registry operators and registry sponsoring organizations to submit requests under the Policy directly to ICANN, and allow ICANN to review those requests in a timely, predictable, and transparent manner in accordance with the recommendations in the Registry Services Evaluation Policy. The application will ask gTLD registry operators or registry sponsoring organizations to respond to a set of questions intended to provide ICANN with sufficient information to evaluate the proposed new registry service. The questions include:

  1. Information on consultations concerning the proposed service. If the registry is a sponsored TLD, the registry is encouraged to describe consultations with the sponsored TLD community.
  2. Description of the timeline for implementation of the proposed service, how the proposed service is being offered, testing of the proposed service
  3. List of any contractual provisions impacted by the proposed service and describe any necessary contractual amendments for the proposed service.
  4. Description of the benefits of the proposed service.
  5. Explanation of whether the proposed service will effect similar services offered by registrars; will treat registrars differently; or will lessen competition among registrants for domain names.
  6. Discussion of whether the proposed service alter the storage and input of registry data.
  7. Explanation of how the proposed service will effect the throughput, response time, consistency or coherence of responses to Internet servers or end systems.
  8. Discussion of any intellectual property concerns raised by the proposed service or does the proposed service contain intellectual property exclusive to your gTLD registry.
  9. Description of any other information relevant to evaluation of the proposed service.

The application will be available for registry testing on or before 15 August 2006, and will be located on the ICANN website at a link to be provided later.

Step 2

Once ICANN determines that the request as submitted through the online tool is complete, ICANN will notify the requesting registry operator or sponsoring organization that the 15 calendar day review process has commenced. ICANN will conduct within 15 days a preliminary determination on whether the proposed service raises significant Security and Stability issues or competition issues.

During the 15-day preliminary determination period, ICANN will communicate with the requesting registry operator or registry sponsoring organization if additional information is needed. Information provided by the registry operator or registry sponsoring organization during the preliminary determination period may be designated as "CONFIDENTIAL", but the registry operator or registry sponsoring organization may not designate "CONFIDENTIAL" information necessary to describe the purpose of the proposed Registry Service and the effect on users of the DNS.

ICANN may seek expert advice during the preliminary determination period from entities or persons subject to confidentiality agreements on the competition, security or stability implications of the proposed registry service. Such experts may include members of the Registry Services Technical Evaluation Panel.

Step 3

By the end of 15 calendar days, ICANN will notify the requesting registry operator of a preliminary determination on the proposed new registry service. Depending on timing, two to five consultation days are available at the end of the 15-day preliminary determination period for notification and discussion with the registry operators.

Step 4

The preliminary determination will result in either 1) approval of the request, 2) referral of the request to the Technical Evaluation Panel, 3) referral of the request to the applicable government competition authority, 4) referral to both the Technical Evaluation Panel and applicable government competition authority, 5) referral to the ICANN Board, or 6) withdrawal of the request by the registry operator or registry sponsoring organization.

Step 5

If a determination has been made to send the proposed service to a government competition authority or to the Technical Evaluation Panel, the registry operator or registry sponsoring organization must either confirm that it intends to move forward with the review process or withdraw its proposed new registry service application.

If no competition or security and stability concerns have been identified by ICANN, the requesting registry operator or registry sponsoring organization may deploy requested service and inform ICANN of its implementation plans. Notice of the approved new registry service will then be published on the ICANN website. If the implementation of the proposed new registry service requires a material change to a Registry Agreement, the preliminary determination will be referred to the ICANN Board for consideration.

Step 6

The process provides for the evaluation by an independent team of experts of proposed new or amended registry services with respect to their potential impact on Internet security or stability. On 26 January 2006, Lyman Chapin was nominated to Chair the Registry Services Technical Evaluation Panel. After a period of public comment, the Board approved the nomination on 31 March 2006 at the ICANN Meeting in Wellington, New Zealand.

Since 31 March, Lyman Chapin has coordinated the seating of technical experts and advisors on the Technical Evaluation Panel. The Technical Evaluation Panel will only review requests for new or amended registry services that have been referred to it by ICANN. Once requests are referred to the Technical Evaluation Panel, it will have 45 days to review each proposed service and report any security or stability issues to the ICANN Board.

Members of the Technical Evaluation Panel will be announced separately.

Step 7

Once the Technical Evaluation Panel has completed its review of the proposed registry service, the evaluation report will be posted for public comment on the ICANN website and provided to the ICANN Board. The ICANN Board will have 30 calendar days to reach a decision. The ICANN Board may decide to 1) approve the request, 2) decline the request, or 3) defer the request for more information.

Step 8

Parties affected by a decision on a proposed new registry service may use the Reconsideration process specified in the ICANN Bylaws.

Reconciliation between Consensus Policy and the contractual terms in gTLD Agreements containing the evaluation process - In response to community discussion and questions, this reconciliation describes differences between these versions of the process. The reconciliation is intended to demonstrate that the consensus policy implementation results in a process that is not inconsistent with either the consensus policy or the terms in any current gTLD Agreements.

Registry Services Workflow - This document provides a graphic representation of the workflow for the Registry Services Evaluation Process.

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"""" is not an IDN."