Skip to main content

Fast Track RSEP Process and Standard Authorization Language

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.

Certain registry services that are commonly requested by registry operators through the RSEP process have resulted in standardized authorization language (typically a Registry Agreement (RA) amendment), referred to as known services. For several of these known services, ICANN org also established simplified RSEP request forms for a Fast Track RSEP process. This webpage identifies the services available through the Fast Track RSEP process and other known services with standard authorization language.

This webpage will be updated from time to time with additional services that fit this description.

Fast Track RSEP Process

The Fast Track RSEP process is a streamlined version of the RSEP process which requires the registry operator to use the specified authorization language (typically as an amendment to the RA) without modification. Fast Track RSEP requests are intended to result in a shorter process duration, from submission to authorization, than a standard RSEP request.

If a registry operator wishes to modify the authorization language of a Fast Track RSEP request, it must be submitted as a standard RSEP request. A registry operator may withdraw its RSEP request at any point by submitting a comment in the Naming Services portal case.

There are four (4) phases in the Fast Track RSEP process:

  1. Submit Fast Track RSEP Request – listed under the title "RSEP Fast Track–[Service Name]" in the Naming Services portal. Follow the steps to (a) confirm the proposed service, (b) confirm the standardized authorization language, (c) respond to standard competition questions, (d) and provide signatory information (contact with authority to execute an amendment to the RA).
  2. ICANN Org Completeness Check (expected duration: 5 calendar days) – a request is considered complete if the registry operator has fully responded to all required fields in the form. During this phase, the RSEP request is not published.
  3. ICANN Review (expected duration: 12 calendar days) - as soon as the request proceeds to ICANN Review, it is published on the RSEP Process webpage. ICANN org reviews the proposed service to determine if it raises significant security, stability, or competition issues. At the end of ICANN Review, ICANN org will notify the registry operator of the preliminary determination on the proposed service.
    1. If the proposed service also requires changing the provider of a Critical Function (as identified in Specification 10, Section 6 of the RA), ICANN org will remind the registry operator that it is required to submit a Material Subcontracting Arrangement (MSA) change request once the RSEP request is approved (example: Registration Validation per Applicable Law with Proxy).
  4. Determination & Final Processing (expected duration to initiate this phase: 5 calendar days) – if approved following ICANN Review, ICANN org will initiate the authorization process (to execute an RA amendment or issue a free to deploy letter) within 5 calendar days. The Determination and Authorization are published on the RSEP Process webpage.

The Fast Track RSEP process is available for the following services:

Service Name Description Pre-Approved RA Amendment Language

Bulk Transfer After Partial Portfolio Acquisition (BTAPPA)

Permits registry operators to offer registrars the ability to conduct a bulk transfer, per the specifications of the RA amendment, in the circumstance where (a) a registrar purchases a portion, but not all, of another registrar's domain name portfolio in the TLD, or (b) a newly accredited registrar requests a transfer of all domain names from the losing registrar for which the gaining registrar has served as the reseller.

Bulk Transfer after Partial Portfolio Acquisition (BTAPPA)

Registration Validation per Applicable Law with or without Proxy

Permits registry operators to perform registration validation to comply with applicable law in a given jurisdiction. Registry operators may offer this service with or without a supplementary registration proxy as identified in the pre-approved RA amendment language options.

Registry Lock

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 Extensible Provisioning Protocol (EPP) statuses.

Registry Lock

Other Known Services with Standard Amendment Language

The following services are not available in the Fast Track RSEP process, but still utilize pre-approved RA amendment language which will help streamline the standard RSEP process. For these services, submit a standard RSEP request (see RSEP Guide) and include a link to the appropriate RA amendment language (below) in the applicable section of the RSEP request form.

Service Name Description Pre-Approved RA Amendment Language

Internationalized Domain Names (IDNs) – this service permits registry operators to offer non-ASCII domain names at the second- or lower-levels.

Registry operators are encouraged to use standardized, pre-approved Reference Label Generation Rules (LGR) tables.

(a) Add an IDN Service and May Activate Variants

For registry operators who have not been previously approved to offer IDNs. The registry operator will activate variants.

Add an IDN Service and May Activate Variants

(b) Add an IDN Service and Will Block Variants

For registry operators who have not been previously approved to offer IDNs. The registry operator will block variants.

Add an IDN Service and Will Block Variants

(c) Add an IDN Service and Will Not Offer Variants

For registry operators who have not been previously approved to offer IDNs. The registry operator will not offer variants.

Add an IDN Service and Will Not Offer Variants

(d) Add IDN Languages/Scripts

For registry operators who have been approved to offer IDNs and plan to offer IDNs in additional languages/scripts.

Adding IDN Languages/Scripts

(e) Remove IDN Languages/Scripts

For registry operators who plan to stop offering IDNs in specific languages/scripts.

Removing IDN Languages/Scripts


This webpage was updated in June 2019 as part of operational improvements to the RSEP process (see the ICANN org blog post). The archived version of this webpage is 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"""" is not an IDN."