Internet Corporation for Assigned Names and Numbers

  |  Subscribe: Newsletters & News Alerts  |  ICANN Blog  |  Public Comment

• Home
• About
• News
• Policy
• Current Topics
• Events
• Structure
• Processes
• Resources
• Documents
• Contact    

^ Home

> News

ICANN is today posting its gTLD Registry Failover Plan for public comment. Comments on the plan may be submitted to registry-failover-plan@icann.org through 19 November 2007 23:59 UTC and may be viewed at http://forum.icann.org/lists/registry-failover-plan/.

Executive Summary

The Registry Failover Project is one of ICANN's key projects in the 2007-2008 ICANN Operating Plan and aligns with ICANN's mission to preserve the operational stability of the Internet.

The introduction of new gTLDs through the anticipated GNSO consensus policy raises the possibility of registry failure. The program team (consisting of gTLD and ccTLD registry representatives and ICANN staff) responsible for addressing these issues has previously published key documents describing work that will contribute to the implementation of a registry failover program. ICANN has completed a draft Registry Failover Plan and has been reviewing that plan with technical and registry experts and other stakeholders in the community in order to ensure its completeness.

The draft Failover Plan (described in written and flow chart [PDF, 84K] form) and Best Practices [PDF, 56K] document are linked to this announcement. The Failover Plan identifies the process and procedures to be undertaken when a specific set of events indicating a potential gTLD registry failure is identified. The draft Plan is designed to protect the interests of registrants and provide the best opportunity for continued registry operations.

The Best Practices document intends to be the source of contractual terms that will become part of every new registry agreement. These terms are intended to provide registries a tool for ensuring ongoing operations and also to provide a backstop process in the case of failure.

The Registry Failover project will be complete when:

• elements of the Best Practice document are incorporated into the basic registry agreement published as part of the new gTLD process, and
• the Failover Plan is adopted by the Registry Constituency and ICANN staff.

It is important to recognize that several well-developed registries have implemented competent contingency plans. ICANN has built on that work (rather than attempt to duplicate it) and has developed a draft “best practices document.” The document can be adopted by ICANN in creating new TLDs registry agreements.

An important issue is to define ICANN's role in the event of a registry failure. This registry failover program mandates that each registry must have a contingency plan to maintain the critical functions of a registry for a period of time so that:

• A replacement operator or sponsor can be found and a transfer effected, or
• Absent the designation of a replacement, provide a notice period to registrants that the registry is closing.

Background

ICANN has conducted extensive research and outreach on the topic of registry failover. On 1 June 2007, ICANN published the first comprehensive registry failure report (http://www.icann.org/announcements/announcement-4-01jun07.htm and http://www.icann.org/registries/reports/registry-failover-01jun07.htm).

In developing this report, ICANN conducted a review of the critical functions of a registry, examined transition of a registry from one operator to another, and examined potential failure scenarios. This report finds that the identification of critical functions, along with establishment of best practices by registries will serve for the protection of registrants in the event that a registry failure occurs. The report provides the elements of the registry failover plan and initial recommendations based on current registry practices.

The report was discussed in San Juan in presentations to: the gTLD Registry Constituency, the ccNSO, SSAC Open Forum, and Protections for Registrants workshop. Following the San Juan meeting, ICANN engaged in consultations with a panel of gTLD and ccTLD registry representatives, completed the draft gTLD Registry Failover Plan and synthesized a best practices document describing registry failover mechanisms. These mechanisms will provide guidance or be incorporated into ICANN's new gTLD process and potentially as a contractual requirement.

Discussion of Issues

As currently envisioned, the implementation of registry failover procedures is intended to define a contractual requirement that registries provide failover mechanisms as a prerequisite to delegation as a registry. The failover mechanisms will, in the event of registry failure:

Provide a period of ongoing operations until a replacement entity may be engaged, or

Failing that, provide a period of notice to registrants of impending closure so that registrants may take their own remedial measures.

These goals were developed in answer to the following issues:

• Definition of ICANN's duty to registrants in the event of a failure of a gTLD registry?
• To what extent should there be a guarantee that a registry will not fail?
• How should ICANN aid in securing services for operation of a registry?
• Should a registry be required to designate a back-up registry operator that would step in to maintain the registry in the event of a long-term failure?
• What are the scenarios in which a registry would be allowed to fail without such a temporary or permanent failover mechanism?

If a registry fails and an RFP does not result in the identification of a successor operator, ICANN suggests here a process to terminate the registry and remove the TLD from the root. This process is outlined in the Registry Failover Plan. ICANN is not in the position to fund or take over operation of a failed TLD, nor is any entity that cannot pursue a viable model for the the failed registry. In such a case, the community might be best served by being informed that registries may be allowed to fail, and that a failed registry may be removed from the root zone.

Many existing gTLD registry agreements provide for failover testing every two years. This provision appears in the .ASIA, .JOBS, .MOBI, and .TRAVEL registry agreements. ICANN is working with these registries to coordinate failover testing criteria. The failover testing parameters will be added as one of the Best Practices contractual requirements for new gTLDs and added to existing gTLD agreements as those agreements are renewed.

Summary of Recommendations

ICANN's 1 June 2007 registry failure report, posted at http://www.icann.org/announcements/announcement-4-01jun07.htm, identified seven critical functions of a registry:

1. maintenance of nameservers and DNS
2. the Shared Registration System
3. WHOIS
4. Registrar Billing and Accounting Information
5. Data security and Data Escrow
6. IDN tables (for those registries offering IDNs), and
7. DNSSEC keys (for those registries that have employed DNSSEC).

In addition, ICANN's draft gTLD Registry Failover Plan includes a set of assumptions, requirements and processes. These were generated through ICANN interaction with the ccTLD and gTLD group described above and through consultation with others. Key elements of the plan are described in greater detail below:

1. ICANN will have a role in the event of failure of a gTLD registry. This may be a primary communication role with the registry, registrars and the end user community.
2. Registries must develop and implement their own contingency plans, including the designation of a backup registry operator.
3. ICANN will not take over operation of a registry, but could operate nameservers or designate a nameserver operator on a temporary basis in the event of an emergency.
4. Registry agreement amendments wil be required to adequately implement ICANN's gTLD Registry Failover Plan. Registry failover will be addressed in new gTLD agreements, and may otherwise be addressed in renewals, and in proposed consensus policy.
5. Registries should have a designated contact person who is authorized to act on behalf of the registry and who can serve as a point of contact with ICANN and the public on critical registry functions.
6. Registries should set aside necessary financial resources, such as a bond, to provide temporary funding of registry functions until a successor registry can be named.
7. Registries should implement geographic diversity of DNS services.
8. Where appropriate, ICANN will consult with experts in contingency and scenario planning, and the event of registry failure.
9. In the event of registry failure, in consultation with the registry, ICANN will identify the type of failure as a technical, business or other failure and determine whether the failure is long-term or temporary. A temporary failure would trigger an established set of responses from ICANN, while a long-term failure would trigger a different set of responses.
10. ICANN should define metrics for failover (the threshold that indicates an event that triggers failover procedures) in the gTLD registry agreements. Failover practice and testing obligations in gTLD registry agreements should be clarified.
11. ICANN has created a Registry Continuity Assistance Panel, consisting of 5 ccTLD registry representatives and 5 gTLD registry representatives to assist with the maintenance and testing of the gTLD Registry Failover Plan.
12. The Registry Failover Plan includes a procedure for designating a replacement registry operator. In the event that a replacement cannot be found, with notice to the community, the plan envisions that ICANN will follow a process for closing registry operations. ICANN should look closely at the transition and termination provisions in the existing registry agreements to determine whether these provisions should be clarified or amended in new agreements.
13. ICANN should establish a procedure for release of escrowed data to ICANN. The procedure must closely safeguard data security. Under the terms of the standard escrow agreement, registry escrow deposits may be released to ICANN under certain conditions. These are:
    1. Expiration without renewal of registry or sponsorship agreement
    2. Termination of registry or sponsorship has been terminated
    3. Joint request by registry and ICANN
    4. No successful verification reports for a Full Deposit in a one-month period
    5. Nonpayment of fees by registry
    6. Mandated release by a court, arbitral, legislative, or government agency of competent jurisdiction

Conclusion

ICANN's gTLD Registry Failover Plan is intended to provide protection for registrants, and add to the security and stability of the Internet through collaboration with registries, registrars and members of the Internet community. The next steps in the project are to complete approval of the procedure, the base contract for new gTLDs.

This file last modified 20-Oct-2007

© 2008 Internet Corporation For Assigned Names and Numbers