Skip to main content
Resources

Registry Services Evaluation Policy

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.

RSEP Process webpage

(Posted 25 July 2006, Effective Date 15 August 2006)

1. Definitions

1.1 Registry Services are defined as the following:

  1. those services that are both: (i) operations of the registry critical to the following tasks: the receipt of data from registrars concerning registrations of domain names and name servers; provision to registrars of status information relating to the zone servers for the TLD; dissemination of TLD zone files; operation of the registry zone servers; and dissemination of contact and other information concerning domain name server registrations in the TLD as required by the Registry Agreement; and (ii) provided by the Registry Operator as of the Effective Date of the Registry Agreement, as the case may be;

  2. other products or services that the Registry Operator is required to provide because of the establishment of a Consensus Policy (as defined above);

  3. any other products or services that only a registry operator is capable of providing, by reason of its designation as the registry operator; and

  4. material changes to any Registry Service within the scope of (A), (B) or (C) above. (Definition comes from .NET Agreement, as specified by the ICANN Board on 8 November 2005, http://www.icann.org/minutes/resolutions-08nov05.htm).

1.2 Security - An effect on security by the proposed Registry Service shall mean (A) the unauthorized disclosure, alteration, insertion or destruction of Registry Data, or (B) the unauthorized access to or disclosure of information or resources on the Internet by systems operating in accordance with all applicable standards. (Definition comes from GNSO Recommendation, located at http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5).

1.3 Stability - An effect on stability shall mean that the proposed Registry Service (A) is not compliant with applicable relevant standards that are authoritative and published by a well-established, recognized and authoritative standards body, such as relevant Standards-Track or Best Current Practice RFCs sponsored by the IETF or (B) creates a condition that adversely affects the throughput, response time, consistency or coherence of responses to Internet servers or end systems, operating in accordance with applicable relevant standards that are authoritative and published by a well-established, recognized and authoritative standards body, such as relevant Standards-Track or Best Current Practice RFCs and relying on Registry Operator's delegation information or provisioning services. (Definition comes from GNSO Recommendation, located at http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5).

1.4 Registry Service Technical Evaluation Panel - The Registry Service Technical Evaluation Panel shall consist of a total of 20 persons expert in the design, management and implementation of the complex systems and standards-protocols utilized in the Internet infrastructure and DNS (the "Registry Service Technical Evaluation Panel"). The members of the Registry Service Technical Evaluation Panel will be selected by its Chair. The Chair of the Registry Service Technical Evaluation Panel will be a person who is agreeable to both ICANN and the registry constituency of the supporting organizations then responsible for generic top level domain registry policies. All members of the Registry Service Technical Evaluation Panel and the Chair shall execute an agreement requiring that they shall consider the issues before the panel neutrally and according to the definitions of Security and Stability. For each matter referred to the Registry Services Technical Evaluation Panel, the Chair shall select no more than five members from the Registry Services Technical Evaluation Panel to evaluate the referred matter, none of which shall have an existing competitive, financial, or legal conflict of interest, and with due regard to the particular technical issues raised by the referral. (Definition comes from GNSO Recommendation, located at http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5).

2. Process for Consideration of Proposed Registry Services

2.1 Registry Operator or Sponsoring Organisation considers new registry service

A Registry operator or sponsoring organisation at any time may decide to change the architecture or operation of an existing TLD registry service or introduce a new TLD registry service (See RSEP Implementation Notes Introduction).

2.2 Determine whether the change requires ICANN review

A gTLD registry operator or sponsoring organisation in consultation with ICANN as described in Section 2.4 will determine whether a change to a service would require approval based on the contract between ICANN and the registry operator (See RSEP Implementation Notes Introduction).

2.3 Deliver to ICANN information on the proposed change

The Policy encourages proponents of a new registry service to collaborate with ICANN prior to submission of a request for new registry sevices. The aim of the Registry Services Evaluation Policy and approval process is to create an environment that encourages gTLD registry operators to discuss any changes that may impact third parties with ICANN before they are made.

The gTLD registry operator or sponsoring organisation should provide ICANN with sufficient information on a change to allow ICANN to assess whether the change should be subject to the approval process. The information should include a technical description of the change as would be seen by external users, and an assessment of the impact on external users. If the registry operator or sponsoring organisation has sought feedback from external parties and the community, details of the process and the results of that feedback should be included. At this stage in the process the information should be regarded by ICANN staff as confidential (See RSEP Implementation Notes Steps 1 and 2).

2.4 Preliminary Determination Period

Following written notification by Registry Operator to ICANN that Registry Operator may make a change in a Registry Service within the scope of the preceding paragraph:

  1. ICANN shall have 15 calendar days to make a "preliminary determination" whether a Registry Service requires further consideration by ICANN because it reasonably determines such Registry Service: (i) could raise significant Security or Stability issues or (ii) could raise significant competition issues.

  2. Registry Operator must provide sufficient information at the time of notification to ICANN that it may implement such a proposed Registry Service to enable ICANN to make an informed "preliminary determination." Information provided by Registry Operator and marked "CONFIDENTIAL" shall be treated as confidential by ICANN. Registry Operator will not designate "CONFIDENTIAL" information necessary to describe the purpose of the proposed Registry Service and the effect on users of the DNS.

  3. 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 Registry Service in order to make its "preliminary determination." To the extent ICANN determines to disclose confidential information to any such experts, it will provide notice to Registry Operator of the identity of the expert(s) and the information it intends to convey. For Security or Stability implications, ICANN may draw an expert from the Registry Services Technical Evaluation Panel described in 2.4(F) below.

  4. If ICANN determines during the 15 calendar day "preliminary determination" period that the proposed Registry Service, does not raise significant Security or Stability (as defined in Sections 1.3 and 1.4), or competition issues, Registry Operator shall be free to deploy it upon such a determination.

    If the implementation of a proposed service requires a material change to a Registry Agreement, the preliminary determination will be referred to the ICANN Board (See RSEP Implementation Notes Step 5).

2.5 Competition issues

In the event ICANN reasonably determines during the 15 calendar day "preliminary determination" period that the Registry Service might raise significant competition issues, ICANN shall refer the issue to the appropriate governmental competition authority or authorities with jurisdiction over the matter within five business days of making its determination, or two business days following the expiration of such 15 day period, whichever is earlier, with notice to Registry Operator.

Any such referral communication shall be posted on ICANN's website on the date of transmittal.

Following such referral, ICANN shall have no further responsibility, and Registry Operator shall have no further obligation to ICANN, with respect to any competition issues relating to the Registry Service. If such a referral occurs, the Registry Operator will not deploy the Registry Service until 45 calendar days following the referral, unless earlier cleared by the referred governmental competition authority (See RSEP Implementation Notes Steps 4-6).

2.6 Security and Stability Issues

In the event that ICANN reasonably determines during the 15 calendar day "preliminary determination" period that the proposed Registry Service might raise significant Stability or Security issues (as defined in Sections 1.3 and 1.4), ICANN will refer the proposal to the Registry Services Technical Evaluation Panel (as defined in Section 1.5) within five business days of making its determination, or two business days following the expiration of such 15 day period, whichever is earlier, and simultaneously invite public comment on the proposal.

The Registry Services Technical Evaluation Panel shall have 45 calendar days from the referral to prepare a written report regarding the proposed Registry Service's effect on Security or Stability (as defined in Sections 1.2 and 1.3), which report (along with a summary of any public comments) shall be forwarded to the ICANN Board. The report shall set forward the opinions of the Registry Services Technical Evaluation Panel, including, but not limited to, a detailed statement of the analysis, reasons, and information upon which the panel has relied in reaching their conclusions, along with the response to any specific questions that were included in the referral from ICANN staff. Upon ICANN's referral to the Registry Services Technical Evaluation Panel, Registry Operator may submit additional information or analyses regarding the likely effect on Security or Stability of the Registry Service.

Upon its evaluation of the proposed Registry Service, the Registry Services Technical Evaluation Panel will report on the likelihood and materiality of the proposed Registry Service's effects on Security or Stability, including whether the proposed Registry Service creates a reasonable risk of a meaningful adverse effect on Security or Stability (See RSEP Implementation Notes Steps 4-6).

2.7 ICANN Board decision

Following receipt of the Registry Service Technical Evaluation Panel's report, which will be posted (with appropriate confidentiality redactions made after consultation with Registry Operator) and available for public comment, the ICANN Board will have 30 calendar days to reach a decision. In the event the ICANN Board reasonably determines that the proposed Registry Service creates a reasonable risk of a meaningful adverse effect on Stability or Security, Registry Operator will not offer the proposed Registry Service.

An unredacted version of the Registry Service Technical Evaluation Panel's report shall be provided to Registry Operator upon the posting of the report. The Registry Operator may respond to the report of the Registry Service Technical Evaluation Panel or otherwise submit to the ICANN Board additional information or analyses regarding the likely effect on Security or Stability of the Registry Service (See RSEP Implementation Note Step 5).

3. Reconsideration

gTLD registry operators or registry sponsoring organizations affected by an ICANN decision on a proposed new registry service may use the existing reconsideration processes in the ICANN bylaws.

The authoritative source for information on the Reconsideration process is the ICANN bylaws (see Article IV: Section 2 http://www.icann.org/general/bylaws.htm#IV). The reconsideration applies to staff actions that contradict an ICANN policy, or to an ICANN Board action taken without consideration of material information. Information on past reconsideration processes is available at http://www.icann.org/committees/reconsideration.

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