Skip to main content

Summary Analysis of RSEP Requests: 2006-2017

(Published 28 February 2018)

The Registry Services Evaluation Policy (RSEP) process is the mechanism registry operators use to request ICANN's approval to add or modify a registry service. ICANN evaluates proposed services for potential effects on security, stability, and competition. This page provides information on statistics for recent RSEP requests and a historical look at the RSEP. The RSEP policy can be read here. To find more information regarding RSEP requests, please see the RSEP Requests webpage.

An initial analysis report was published in May 2016 and later updated in August 2016 containing partial data from 2016 requests. This report includes cumulative data through December 2017.

Overview of the RSEP Process Steps and Statuses

Below is a general overview of the RSEP process steps. For a more detailed view, refer to the workflow here: This analysis excludes those requests that have been withdrawn before they reached ICANN Review (step 3).

RSEP Process Steps Workflow

Completeness Check: ICANN reviews the request for sufficient information to evaluate Security, Stability and competition effects of the proposed service. The RSEP request remains confidential during this step.

ICANN Review: ICANN publishes the RSEP request and reviews the request for potential Security, Stability and competition issues.

ICANN Authorization: If the request does not raise significant Security, Stability or competition issues, ICANN issues the appropriate authorizing document(s) to enable the registry to implement the service in accordance with their registry agreement.*

*In some cases, ICANN publishes the draft amendment for public comment and refers the amendment to the Board for consideration. From 2015-2017, except requests for release of country and territory names, five requests have been published for public comment and none of those have been referred to the Board. In rare cases, ICANN cannot provide an amendment to implement the proposal.

RSEP Requests by Category (2015-2017)

RSEP Requests by Category (2015-2017)

195 total RSEP requests were received and published 2015 through 2017, categorized as follows.

Blue Arrow Internationalized Domain Names: 40% of total requests
Requests related to Internationalized Domain Names (IDNs) include adding, changing or removing the languages or scripts available for domain registrations in a gTLD. IDN requests have consistently ranked in the top two of RSEP request types since the first new gTLDs launched in 2013.
Teal Arrow Country & Territory Names: 28% of total requests
Requests for release of reserved country and territory names (CTNs) significantly decreased after the ICANN Board passed a resolution on the matter on 18 May 2017. More information regarding the handling of country and territory names can be found here:
Orange Arrow Registration Validation per Applicable Law: 9% of total requests
Requests for registration validation services per applicable law tripled from 2015 to 2017.
Red Arrow Other: 23% of total requests
"Other" requests (requests that do not fall into the categories of IDNs, country and territory names, and registration validation per applicable law) include services to support increased security, such as the Registry Lock service, or rights protections such as the Protected Marks List service.

Details of "Other" Requests in 2017

Registration Verification Modification
Some registry operators include a verification process during the domain registration lifecycle and later modify the way verification is performed or eliminate their verification process.
Registry Lock
This service helps protect against inadvertent transfers, modifications to or deletions of domain name registration data by allowing an authorized representative from the sponsoring registrar to request the activation or deactivation of certain EPP statuses.
Bulk Transfer After Partial Portfolio Acquisition (BTAPPA)
This service permits registry operators to offer to registrars a domain registration bulk transfer service where an ICANN-accredited registrar purchases a portion but not all of another ICANN-accredited registrar's domain name portfolio in the top-level domain (TLD).
Change in Representation of Host Information in the SRS
This modification changes how host nameserver information is represented.
Consolidate Renewal
This service allows a registrant with multiple domain registrations to extend the domain name expiration dates to a later, consolidated date.
DNS and WHOIS Query Data Publication
This service allows the registrant and administrative contact to have access to DNS and WHOIS query data for their domain name.
Legacy gTLD Migration to New gTLD Technical Specifications
This modification involves the migration of a legacy gTLD onto new gTLD technical specifications.
Protected Marks List
This service allows trademark rights holders to block corresponding labels across multiple top-level domains (TLDs). Labels may be unblocked under certain circumstances.
Removal of grace periods
This modification removes existing voluntary grace periods.

Historical Look at RSEP

Annual Number of RSEP Requests Reviewed by ICANN

Annual Number of RSEP Requests Reviewed by ICANN
  • 326 requests have been received and published since the RSEP was developed in 2006.
  • In 2006, four RSEP requests were received and published. From 2006 through 2012, prior to the delegations that resulted from the New gTLD Program, the average number of RSEP requests per year was eight.
  • Since the launch of new gTLDs in 2013, the number of requests has increased. The average annual number of RSEP requests between 2013 through 2017 is 54, likely driven by the following factors:
    • The increase in the number of gTLDs
    • Alignment of service offerings across gTLDs supported by common back-end registry service providers
    • Requests for release of reserved names

Community comments in the RSEP Forum

Once an RSEP request reaches step 3 as shown in the overview above, it is available for comment by the community via the RSEP comment forum (

  • In 2017, one comment was received in the RSEP Forum regarding an RSEP request with a currently pending amendment.
  • No comments were received from 2015 through 2016.
  • For the analysis of comments received prior to 2015, see the Summary Analysis of RSEP Requests (2006-August 2016).
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."