Registry Transition Processes

Definitions

For purposes of this document the following terms are defined as follows:

Back-End Registry Operator: An organization contracted by a registry to run one or more of the Critical Functions of a gTLD registry.

Critical Functions: Functions that are critical to the operation of a gTLD registry:

1. DNS resolution
2. DNSSEC properly signed zone (if DNSSEC is offered by the registry)
3. Shared Registration System (SRS), usually by means of the Extensible Provisioning Protocol (EPP)
4. Registration Data Directory Services (RDDS), e.g., WHOIS provided over both port 43 and through a web based service.
5. Registry Data Escrow

Registry Transition: A change in the contracting party of a gTLD Registry Agreement with ICANN. Examples of circumstances leading to a Registry Transition are: name change of the organization running the gTLD, a sale or transfer of the registry, current registry is in breach of Registry Agreement, etc.

Successor Registry: The new contracting party of a gTLD Registry Agreement with ICANN after a Registry Transition.

Registry Transition Processes

Affirmation of Commitments, section 9.2, states as one the commitments of ICANN:

Preserving security, stability and resiliency [of the DNS].¹

ICANN bylaws identify the core values of the organization. Core value #1 is as follows:

Preserving and enhancing the operational stability, reliability, security, and global interoperability of the Internet.²

The 2006-2007 ICANN Operating Plan (section 1.1.2) states that ICANN will:

Establish a comprehensive plan to be followed in the event of financial, technical, or business failure of a registry operator, including full compliance with data escrow requirements and recovery testing.³

The process was created in FY06-07 and has been continuously updated; it is now called the Registry Continuity Framework⁴. The Incident and Event Management Process depicted in the Registry Continuity Framework identifies the need for handling situations where Critical Registry Functions are negatively affected.

In pursuit of its core value #1, and as a result of the development of the Registry Continuity Framework, ICANN has identified the need to define processes to transition a gTLD in a secure, stable and reliable manner; while minimizing the impact on registrants and gTLD users, and providing transparency to the parties involved in the transition.

The following three processes have been developed and are described in this document:

1. Registry Transition Process with proposed successor
2. Registry Transition Process with Request For Proposals (RFP)
3. Emergency Back-End Registry Operator Temporary Transition Process

 

1. Registry Transition Process with Proposed Successor

   This process will be used when a registry requests that ICANN assign its Registry Agreement to a prospective successor (e.g., the registry is being acquired, there is a name change in the organization, a transition to the registry services continuity provider). This process will also be used if at the end of the registry agreement term, or by means of a court order by a legal authority with jurisdiction, the relevant Government or Public authority withdraws its support to the registry operator of a gTLD that is a geographic name, and proposes a successor registry. A flowchart of this process is in Appendix 2.

   The appropriate level of scrutiny will be exercised at all times when evaluating the proposed successor. For example, in the case of a name change, the evaluation will focus on ensuring it is legitimate to guarantee there is no opportunity for hijacking the TLD.

   Upon receipt of the request from the current registry or relevant government or public authority (in the case of geographic gTLDs), ICANN will assess the situation from the gathered facts, conversations with the current registry, and government or public authority (if applicable), and an analysis of the Registry Agreement. The assessment will focus on the following questions:

   • Would there be a change in an entity providing any of the Back-End Registry functions?
   • Does the TLD have a relevant community that must be consulted?
   • Is this a gTLD a geographic name according to the definition in the Applicant Guidebook? (Or, was government support required at the time of the application?)
   • Are there any restrictions in the Registry Agreement that might affect a transition?

   ICANN will also perform a risk assessment of the gTLD, current registry, and Back-End Registry Operator (if there is a change in that respect). The assessment will focus on particularities of the triple as a whole and the triplets themselves. For example, it will be checked if the gTLD is heavily used by financial institutions or for electronic commerce, which may lead to stricter measures about the security of the transition.

   After these assessments are complete, the proposed successor registry will be checked to ensure that it has the required outside support, if that is required. If the gTLD is a geographic name, as defined in the New gTLD Applicant Guidebook, ICANN will direct the proposed successor to solicit the relevant government or public authority for support for the prospective successor and collect documentation of support/non-objection. If the Registry Agreement defines any community that must be consulted at time of transition, ICANN will consult them at this stage. In these cases, there must be support for the proposed successor from the relevant community for the process to continue to transition.

   If the proposed successor has the required support or if no support is required, ICANN will then proceed to evaluate the applicant using the processes defined in the Applicant Guidebook for new gTLDs. Based on criteria set forth in the Prospective Registry Evaluation Matrix described in Appendix 1, ICANN will determine which evaluations are necessary and collect the information and evaluation fee. The fee will cover the cost of the evaluations that are conducted by external providers.

   Evaluations performed internally by ICANN will be at no cost for the applicant.

   The scope of the evaluations will vary for each case depending on the required and appropriate level of scrutiny. The three levels of scrutiny are presented in Appendix 1. The most extensive level (i.e., Full) will be similar in scope to the review of new gTLD applicants. The assessment will be performed by one of the firms engaged in evaluating applications for new gTLDs. The next level (i.e., Limited) represents a more narrow scope of review. For example, the Technical and Operations evaluation could consist of ensuring that the new organization has similar arrangements in place with the existing Back-End Registry Operator. The third level (i.e., Minimal) represents a very narrow scope of review that would be performed internally by ICANN.

   The evaluation provider will then perform the required evaluations and provide a report to the applicant and ICANN. If the applicant does not pass the evaluation, there will be a chance for the applicant to cure the deficiencies within three weeks of the failed evaluation (an extended evaluation). If the applicant does not pass evaluation in the second opportunity, the process will end with no transition and a refund will be provided to the applicant equal to what was collected less actual evaluation costs.

   If the prospective successor passes the evaluation, ICANN will seek the necessary approvals and enter into a Registry Agreement with the successor if approved. If the prospective successor is not approved, the process will end without transition.

   Once the successor is approved, this outcome will be communicated internally and externally as necessary and appropriate. If the transition does not involve a change in Back-End Registry Operator, the successor must then request the change in sponsoring organization with IANA.

   If there is a change in the entity providing Back-End Registry Operator services, the successor will have to pass pre-delegation testing as defined in the Applicant Guidebook for new gTLDs. This is the case whether the Back–End provider is the Registry Operator or a contractor to the Registry Operator. Once the testing is successfully completed, the new registry operator must proceed to change the sponsoring organization with IANA in the IANA root zone database. After the IANA step has been completed, the successor registry operator will then carry out the migration of data and services, and will request changes to DNS and RDDS (WHOIS) records with IANA.

   The final steps in the transition process will be to communicate internally and externally as necessary and appropriate and for ICANN to update its public and internal information about the gTLD registry.

2. Registry Transition Process with RFP

   This process will be used primarily when a gTLD registry is in breach of is Registry Agreement (leading to termination) and does not identify a successor registry. This process will also be used if at the end of the registry agreement term, or by means of a court order by a legal authority with jurisdiction, the relevant Government or Public Authority withdraws its support to the registry of a geographic gTLD and does not provide a proposed successor registry. A flowchart of this process is in Appendix 3.

   This process is similar to a Registry Transition Process with proposed successor described above, except that it includes a Request for Proposals (RFP) subprocess. The purpose of the RFP is to identify and solicit applications from prospective, successor registries.

   The RFP process will be launched following the risk assessment of the gTLD, as it may produce findings that might be important to disclose in the RFP. The RFP will describe the necessary services to be provided by the successor registry. In addition, expected costs for evaluation services will be included in the RFP and will serve as the minimum acceptable economic proposal from an applicant.

   If the registry is operating a gTLD that is a geographic name, as defined in the Applicant Guidebook, ICANN will consult with the relevant Government or Public Authority for their input in the RFP. Further, if the Registry Agreement contains a provision that requires ICANN to consult with a specified community about a potential successor before a transition, it will be done at this stage in the process.

   Once the RFP has been approved, it will be posted for 45 days, and applicants will have until the end of the posting period to provide a response.

   The applicant proposing the highest payment to the original registry will then be checked for necessary support and will be evaluated as described in the Registry Transition process with proposed successor. This selection mechanism provides the maximum return for the original registry and minimizes unnecessary expenses for the non-winner applicants while still ensuring the winner is qualified.

   If the applicant has the necessary support (or if no support is required) and passes the evaluation, the process will continue as described in the aforementioned process. If the applicant does not have the required support or does not pass the evaluation, the next highest proposal applicant will be considered and so on, until there is a successfully supported and evaluated applicant or there are no more proposals.

   If there are no proposals received during the RFP process, or there are no qualified applicants, due to lack of appropriate support or inability to pass the evaluation, the TLD sunset process will be invoked in order to close the gTLD. If a viable candidate is identified after a closed RFP process that did not identify a successor, that candidate might be considered based upon circumstances present at the time and that such a decision serves the public interest.

   If there is a qualified successor registry identified through this process, any funds collected from this applicant less evaluation costs and outstanding fees due will go to the registry operator disposing of the gTLD.

3. Emergency Back-End Registry Operator Temporary Transition Process

   This process will be used for new gTLDs primarily when two conditions are met: (1) the registry is in breach of its Registry Agreement and (2) a Critical Function is being performed below the Emergency Thresholds, as defined in the Registry Agreement, resulting in a situation of unacceptable risk as defined below. In such a case, operations can be transferred to an emergency provider of Back-End services until the registry operator can restore normal operations. This temporary transition could also be initiated at the request of the registry operator if they are aware of or anticipate an inability to adequately provide the Critical Functions.

   Measurements to detect the Emergency Threshold for Critical Functions (except Data Escrow) will be drawn from the registry SLA (Service Level Agreement) monitoring system used by ICANN as described in the Registry Agreement.

   It is also worth noting that this transition process is intended to be a temporary measure to protect registrants and gTLD users. The temporary transition of Critical Functions will remain in effect until the underlying issues are resolved, or the gTLD is transitioned to another operator using one of the previously described Registry Transition processes. In order to allow this temporary transition, Registry Agreement for new gTLDs includes pre-authorization from the registry operator to changes in the IANA database for DNS and RDDS (WHOIS) records, in case of emergency.

   Once the registry operator is ready to resume operations and has remedied all issues that may have caused it to be in breach, it can initiate a Registry Transition Process with proposed successor in order to regain control of gTLD operations. This option will be available to the registry operator until the expiry of the cure period for the breach. The registry operator will identify itself as the proposed successor in that process.

   ICANN will maintain, at least, two pre-selected Emergency Back-End Registry Operators (Emergency Operators) under contract. An Emergency-Operator RFP process will be issued every five years to renew the contracts and/or identify and select new Emergency Operators. Emergency Operators that are selected will be from geographically diverse regions in order to increase the reliability of the Emergency Operators as a whole; should there be a catastrophe in a region affecting one Emergency-Operator's ability to function, the other would still be ready to operate. The basic eligibility requirements for Emergency Operators are at least three years of experience operating DNS and one year of experience operating RDSS (e.g., WHOIS) and EPP services.

   ICANN will select Emergency Operators based on value; the best mix of service and price. Funding for use of the Emergency-Operator's services for each case will be drawn from the respective Continued Operations Instruments required for new gTLD registry operators as specified in Specification 8 of the Registry Agreement.

   Emergency Operator applicants will be evaluated using similar processes for new gTLDs, including pre-delegation testing on the infrastructure to be used in an emergency. Infrastructure must be ready to operate during the evaluation. ICANN may, from time to time, require testing the Emergency Operator capabilities and readiness to accept and act upon an emergency transition.

   As soon as ICANN selects the Emergency Operators, they will offer a lightweight Registry-Registrar Agreement to all registrars that will enable the Emergency Operators to perform SRS functions during a temporary transition process. Registrars will be encouraged to engage the Emergency Operators before any emergency happens so they are ready to operate (e.g., an agreement is in place, credentials for accessing the SRS are already distributed, operational testing with the Emergency Operators is done, etc.) should an emergency transition happen for a particular gTLD.

   When an emergency occurs and Emergency Operator services are required, ICANN will seek to engage one of the Emergency Operators. If the selected provider is not able to take the operation or if there is a conflict of interest, ICANN will engage another provider. An active Emergency Operator will be eligible to apply to become the definitive successor registry or Back-End operator of the gTLD in the event there is a Registry Transition, according to the normal rules of the RFP. In order to have a balanced bidding process, an active Emergency Operator will provide operational informational to ICANN required to be included in an RFP for the operation of the gTLD.

   There may be cases in which the current Back-End Registry Operator may serve as the Emergency Operator, that is, if:

   • the registry operator requested to ICANN the emergency transition to the Back-End Registry Operator as the Emergency Operator;
   • the current Back-End Registry Operator is operating the Critical Functions within the terms of the Service Levels defined in the Registry Agreement;
   • the Back-End Registry Operator company is not related to or affiliated with the registry operator; and
   • the Back-End Registry Operator accepts to operate the gTLD under better or equal terms than those agreed by the Emergency Operators.

   Then ICANN, at its sole discretion, may offer to the Back-End Registry Operator to perform the registry functions for the gTLD. In such a case, the Back-End Registry Operator serving as Emergency Operator will be paid out of the proceeds from the Continued Operations Instrument.

   Emergency Operators will have Service Level Requirements (SLR) for activation of each of the Critical Functions as follows.

   Critical Function	Service Level Requirement
   DNS / DNSSEC	4 hours upon request from ICANN
   RDDS	24 hours upon receipt of data
   SRS (EPP)*	72 hours upon receipt of data
   Data Escrow	24 hours upon start of SRS operation

   *SRS servers ready to accept requests from registrars.

   Emergency Operators will maintain an archive of, at least, daily zone files for all gTLDs to allow the selected Emergency Operator to quickly resume DNS service in case of emergency. For the other Critical Functions, data will be obtained from the current registry and/or data escrow deposits.

   Escrow Agents for new gTLDs will be required to agree to a requirement for release of gTLD data within 24 hours upon request, in case of emergency.

   During emergency operation of Critical Functions for a gTLD, an Emergency Operator will not bill SRS operations from registrars.

   Typically, the Emergency Operator will not accept new domains, domain renewals, domain transfers, or domain name deletions from registrars. However, under certain exceptional cases the aforementioned operations will be accepted, e.g., under the Expedited Registry Security Request ⁵, UDRP, or any other ICANN domain name dispute resolution procedures. Bulk domain transfers can be approved by ICANN for domains sponsored by registrars that no longer can service them (e.g., registrar has been de-accredited). Emergency Operator will not expire registrations or auto-renew them; and will include in the RDDS (e.g., WHOIS) output a short explanation (approved by ICANN) atop the legal disclaimer (if any) as described in section 1.1 of Specification 4 of the Registry Agreement of why the expiry date is in the past. The rest of the standard domain name, contact, and host (RFC 5730-34, 5910) SRS operations will be allowed. The Emergency Operator will work with all the accredited registrars that have domains under sponsorship in the gTLD.

   A successor registry will be permitted to charge renewal or fractional renewals as of the effective date of the start of its operations. Successor registry will inherit the fees of the failed registry and will have to follow the process defined in the registry agreement in order to change them.

   A flowchart of the process to be followed in case of emergency is in Appendix 4.

   When transitioning from an Emergency Operator back to the previous registry operator or to a new registry operator, the Emergency Operator will collaborate and cooperate with the new operator in order to achieve an orderly transition with minimum impact to registrants and gTLD users.

   ICANN will monitor and document emergency transition processes when/if they happen. Metrics will be developed including registry operator and EBERO performance in the five critical functions. ICANN will note what worked well and what could be improved in order to propose modifications to this process.

---

• Appendix 1 | Prospective Registry Evaluation Matrix
• Appendix 2-1 | Registry Transition Process with Proposed Successor
• Appendix 2-2 | Registry Transition Process with Proposed Successor - Check Support
• Appendix 2-3 | Registry Transition Process with Proposed Successor - Evaluate
• Appendix 2-4 | Registry Transition Process with Proposed Successor - Communicate
• Appendix 3-1 | Registry Transition Process with Request for Proposals
• Appendix 3-2 | Registry Transition Process with Request for Proposals - Check Support
• Appendix 3-3 | Registry Transition Process with Request for Proposals - Evaluate
• Appendix 3-4 | Registry Transition Process with Request for Proposals - RFP
• Appendix 3-5 | Registry Transition Process with Request for Proposals - Communicate
• Appendix 4-1 | Emergency Back-End Registry Operator Temporary Transition Process
• Appendix 4-2 | Emergency Back-End Registry Operator Transition Process - DNS
• Appendix 4-3 | Emergency Back-End Registry Operator Transition Process - RDDS
• Appendix 4-4 | Emergency Back-End Registry Operator Transition Process - SRS
• Appendix 4-5 | Emergency Back-End Registry Operator Transition Process - Data Escrow
• Appendix 4-6 | Emergency Back-End Registry Operator Transition Process - Communicate

---

¹ ICANN. (2009, September 30). Affirmation of Commitments. Retrieved from http://www.icann.org/en/documents/affirmation-of-commitments-30sep09-en.htm

² ICANN. (2009, September 30). ICANN bylaws. Retrieved from http://www.icann.org/en/general/bylaws.htm#I

³ ICANN. (2006, June 22). 2006-2007 ICANN Operating Plan. Retrieved from http://www.icann.org/announcements/operating-plan-22jun06.htm

⁴ ICANN. (2009). gTLD Registry Continuity. Retrieved from http://www.icann.org/en/registries/continuity/

⁵ http://icann.org/en/registries/ersr/