Skip to main content
Resources

RSEP Implementation Notes

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.

Effective 17 June 2019

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. This 2019 version of the RSEP Implementation Notes reflects the agreed upon changes effective on 17 June 2019.

Click here to return to the RSEP Process webpage.

Introduction

On 8 November 2005, the ICANN Board directed implementation of the GNSO's recommended procedure for considering requests for new Registry Services to be guided by the provisions in the .NET Registry Agreement concerning definitions of Registry Services. These Implementation Notes are a synopsis of the Registry Services Evaluation Policy (RSEP) process and intend to provide high-level information regarding implementation of the Policy by ICANN org. ICANN org may review the effectiveness of this implementation on a periodic basis with input from relevant registry operators and constituencies.

In 2019, a Registries Stakeholder Group (RySG) discussion group collaborated with ICANN org to update the Implementation Notes without altering the Policy itself. These revised Implementation Notes are designed to make the RSEP process easier to understand, establish greater predictability, and ensure ongoing alignment with the underlying Policy.

A gTLD registry operator may submit an RSEP request to ICANN org to add a proposed Registry Service, modify an existing Registry Service, or remove a Registry Service. If ICANN org determines a proposed service in an RSEP request does not qualify as a Registry Service as defined in the Registry Agreement, ICANN org will notify the registry operator and close the request. The registry operator may withdraw its request at any point.

In response to differences between the RSEP Consensus Policy and the contractual terms in certain legacy gTLD Registry Agreements, ICANN org created a reconciliation between Consensus Policy and the contractual terms in gTLD Agreements containing the evaluation 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. ICANN org will take the reconciliation into account for any RSEP requests for Registry Agreements with these differences.

All references to days are defined as calendar days unless otherwise noted.

Step 1 - Submission

Registry operators may submit RSEP requests to ICANN org using the appropriate request form based on the criteria below:

  1. Standard RSEP request form: for RSEP requests to add a proposed Registry Service, remove an existing Registry Service, or materially modify an existing Registry Service, registry operators must respond to a set of standard questions intended to provide ICANN org with sufficient information to evaluate the request. Registry operators may designate information submitted in the RSEP request as "CONFIDENTIAL" with the exception of information necessary to describe the purpose of the proposed Registry Service and the effect on users of the DNS.

    In order to adhere to Policy timelines and offer more predictability for registry operators, the Policy and ICANN org encourage registry operators to consult with ICANN org prior to the submission of a standard RSEP request form. This step is not intended to create additional burden on the registry operator, but rather to help ensure that necessary information is assembled ahead of time for consideration of the RSEP request. This is also an opportunity to discuss whether the request qualifies under the Policy, note and clarify any concerns that might arise in the formal review of the request, and agree to appropriate authorization language as quickly as possible.

  2. Simplified RSEP request form: for certain known services (services that have been reviewed repeatedly by ICANN org for Security and Stability, have not raised significant Security or Stability issues, have been approved before, and have a published amendment template available), the registry operator completes a simplified request form and confirms use of a standard template amendment without modification. This step may reduce the duration of a known service RSEP request from submission to authorization.

Step 2 - ICANN Completeness Check

RSEP requests remain unpublished while in Completeness Check and all interaction between ICANN org and the registry operator regarding the RSEP request remains confidential. Once a request is submitted, ICANN org conducts a review for completeness, which should take less than 15 days. A request must meet the following criteria in order to proceed to Step 3 - ICANN Review:

  1. Sufficient information: the request must include sufficient information to enable ICANN org to make an informed preliminary determination during ICANN Review. Complete submissions for standard RSEP requests include substantive responses to all relevant questions, including a complete description of the proposed service, an assessment of the impact on external users, a list and explanation of contractual provisions impacted by the new service (if any), proposed amendment language (when an amendment is required), feedback from external parties and the community (if obtained), and any other supporting documents helpful to the preliminary determination.

  2. Authorization Document: by the end of Step 2, ICANN org and the registry operator should agree to the type of authorization document and, for a Registry Agreement (RA) amendment, the amendment language before the request will proceed to ICANN Review. Reasons why ICANN org may not be able to proceed with agreeing to an authorization document include when the proposed service conflicts with ICANN Consensus Policy or ICANN Board direction.

    Authorization document type and criteria:

    • RA Amendment: used when the proposed service (i) contradicts existing provisions in the RA or (ii) is not contemplated in the RA and, therefore, needs to be added to Exhibit A of the RA and/or as an appropriate addendum/appendix.
    • Free to Deploy letter: used when the proposed service is already contemplated in the RA and does not contradict contractual provisions.

ICANN org may identify that additional information is needed in the RSEP request for ICANN org to conduct its evaluation and to be included in the published request. In this situation, ICANN org may consult with the registry operator and/or ask the registry operator to re-submit its request with additional information, which may lengthen Step 2 - Completeness Check. ICANN org will work with the registry operator in good faith through this process.

2A - Request to Proceed

If the parties agree criteria 1 of Step 2 is complete, but the registry operator and ICANN org have not agreed to the authorization document type and/or amendment language, the registry operator may submit a Request to Proceed to Step 3 - ICANN Review before the authorization document is finalized. ICANN org will consider all Requests to Proceed in a timely manner and will assess the progress of the negotiations in good faith.

ICANN org may take one of the following actions if a Request to Proceed is submitted:

  • If the negotiations are almost complete, ICANN org may grant the Request to Proceed and the RSEP request will move to Step 3 - ICANN Review, at which point the RSEP request will be published. Both parties will continue negotiations during Step 3 with the aim to reach agreement by the end of ICANN Review.
  • If the negotiations are not close to complete, ICANN org may request additional negotiation with escalation within ICANN org leadership. This escalation will take place prior to the RSEP request moving to Step 3. If ICANN org grants the Request to Proceed following the escalation, ICANN org may publish the proposed authorization document for public comment if the proposed Registry Service sets new precedent or has substantial effect on ICANN, third parties, or the Domain Name System. The public comment would occur following Step 3 - ICANN Review.
  • If ICANN org determines that the registry operator has not negotiated in good faith, ICANN org may reject the Request to Proceed.

Step 3 - ICANN Review

Once ICANN org determines a request is complete or grants a Request to Proceed in Step 2, ICANN org will begin the 15-day review process and publish the proposed Registry Service.

During ICANN Review, a preliminary determination will be made on whether the proposed Registry Service raises significant Security, Stability, or competition issues. ICANN org will follow the published guidelines on the preliminary determination of competition issues and may seek expert advice from entities or persons subject to confidentiality agreements on the Security, Stability, or competition implications of the proposed Registry Service. Such experts may include members of the Registry Services Technical Evaluation Panel (RSTEP). This review will not exceed 15 days as required by the Policy.

At the end of Step 3 - ICANN Review, ICANN org will notify the requesting registry operator of the preliminary determination on the proposed Registry Service.

Step 4 - Approval or Referral

The preliminary determination from Step 3 will result in one of the following outcomes:

  1. Approval of the RSEP request,
  2. Referral to the Registry Services Technical Evaluation Panel (RSTEP),
  3. Referral to the applicable government competition authority, or
  4. Referral to both the RSTEP and the applicable government competition authority.

If the preliminary determination results in outcomes 2-4, the registry operator will be notified and must confirm it intends to move forward with the review process or withdraw its RSEP request. If needed, the registry operator may consult with ICANN org regarding the outcome.

Outcome Determination Next Steps

(1) Approval

No apparent significant Security, Stability, or competition issues

The request is considered complete and will proceed to Step 6 - Authorization.

(2) Referral to the RSTEP

Could raise significant Security or Stability issues

If the registry operator confirms it wishes to move forward, the proposed service is evaluated by the RSTEP (list of RSTEP members is published here). Once a request is referred to the RSTEP, the panel will have 45 days to review the proposed service and create a report on any Security or Stability issues. An unredacted version of the RSTEP's final report will be provided to the registry operator. Step 5 - Public Comment & ICANN Consideration is required.

(3) Referral to the applicable government competition authority

Could raise significant competition issues

If the registry operator confirms it wishes to move forward, ICANN org will refer the issue to the appropriate governmental competition authority or authorities with jurisdiction over the matter within five business days of the registry operator's confirmation to proceed. Step 5 - Public Comment & ICANN Consideration is required.

(4) Referral to both the RSTEP and the applicable government competition authority

Could raise significant Security or Stability issues and competition issues

If the registry operator confirms it wishes to move forward, ICANN org will follow the steps of outcomes 2 and 3.

Step 5 - Public Comment & ICANN Consideration (if applicable)

A public comment period on a proposed authorization document resulting from the RSEP request is required if the proposed Registry Service was referred to the RSTEP or competition authority in Step 4 or under the conditions described in 2A – Request to Proceed.

  • Referral to RSTEP: the proposed Registry Service and draft authorization document will be published for public comment while the RSTEP conducts its review. Once the RSTEP evaluation report is complete, it will be added to the ongoing public comment period. After the public comment period concludes, the registry operator may respond to comments and the draft authorization document may be updated.

  • Referral to Competition Authority: The proposed Registry Service and authorization document will be published for public comment during the 45-day referral to the applicable government competition authority.

    • If the competition authority raises issues within the 45-day referral window, the registry operator may work with ICANN org to address the issues and the draft authorization document may be updated.
    • If the competition authority does not raise issues within the 45-day referral window or the request is cleared earlier, ICANN org will consider this in its analysis of the public comments. 
    • After the public comment period concludes, the registry operator may respond to comments and the draft authorization may be updated.

Following the public comment period, approval of the RSEP request will be considered by ICANN org or will be referred to the ICANN Board.

If referred to the ICANN Board, the ICANN Board will aim to reach a decision within 30 days from the finalization of the public comment summary and analysis report. The ICANN Board may decide to 1) approve the RSEP request, 2) decline the RSEP request, or 3) defer the RSEP request for more information.

If ICANN org or the ICANN Board approves the RSEP request, the registry operator and ICANN org will proceed to Step 6 - Authorization. If the ICANN Board declines the request, the request will not proceed.

Step 6 - Authorization

As with the prior ICANN implementation of the Policy, once an RSEP request has been approved and ICANN org and the registry operator agree to the authorization document, ICANN org will initiate the authorization process. Within 5 days of meeting these conditions, ICANN org will either:

  1. Issue the Free to Deploy letter to the registry operator (as agreed to in Step 2) at which point the registry operator may deploy the service or
  2. Initiate the RA Amendment execution process using the agreed to RA amendment from Step 2 or Step 5 if updates are made following Public Comment. The registry operator may deploy the requested service after execution of the amendment by both registry operator and ICANN org.

ICANN org will publish notice of the approved Registry Service as well as the authorization document on the RSEP webpage and the Registry Agreement webpage specific to the TLD(s).

If the registry operator deploys without an authorization document, the registry operator may be considered out of compliance.

RSEP Process Workflow

See the RSEP Process Workflow for a high-level representation of the RSEP process containing references to these Implementation Notes.

Archive

This webpage was updated in June 2019 as part of operational improvements to the RSEP process (see the ICANN org blog post). The archived Implementation Notes are available here.

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