Skip to main content

Fast Track RSEP Process

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). For several of these services, ICANN org established simplified RSEP request forms for a Fast Track RSEP process. This webpage identifies the services available through the Fast Track RSEP process.

This webpage will be updated from time to time with additional services that fit this description. Note, the IDN Service utilizes standardized authorization language, visit IDN Service requests page for more information.

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


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