<div id="doctitle">
<p class="title">ICANN's gTLD Registry Failover Plan</p>
<p class="docdate">20 October 2007</p>
</div>
<p>ICANN is today posting its <a href="http://www.icann.org/registries/failover/draft-plan-20oct07.htm">gTLD Registry Failover Plan</a> for public comment. Comments on the plan may be submitted to <a href="mailto:%20registry-failover-plan@icann.org">
registry-failover-plan@icann.org</a> through 19 November 2007 23:59 UTC and may be viewed at <a href="http://forum.icann.org/lists/registry-failover-plan">http://forum.icann.org/lists/registry-failover-plan</a>/.</p>
<h4>Executive Summary</h4>
<p>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.</p>
<p>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.</p>
<p>The draft Failover Plan (described in <a href="http://www.icann.org/registries/failover/draft-plan-20oct07.htm">written</a> and <a href="http://www.icann.org/registries/failover/draft-plan-flow-chart-20oct07.pdf">flow chart
</a> [PDF, 84K] form) and <a href="http://www.icann.org/registries/failover/draft-plan-best-practices-20oct07.pdf">Best Practices</a>
[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. </p>
<p>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.</p>
<p>The Registry Failover project will be complete when:</p>
<ul><li style="margin-bottom: 15px;">elements of the Best Practice
document are incorporated into the basic registry agreement published
as part of the new gTLD process, and</li><li style="margin-bottom: 15px;"> the Failover Plan is adopted by the Registry Constituency and ICANN staff.</li></ul>
<p>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.</p>
<p>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:</p>
<ul><li style="margin-bottom: 15px;">A replacement operator or sponsor can be found and a transfer effected, or</li><li style="margin-bottom: 15px;"> Absent the designation of a replacement, provide a notice period to registrants that the registry is closing.
</li></ul>
<h4>Background</h4>
<p>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 (<a href="http://www.icann.org/announcements/announcement-4-01jun07.htm">http://www.icann.org/announcements/announcement-4-01jun07.htm</a> and <a href="http://www.icann.org/registries/reports/registry-failover-01jun07.htm">
http://www.icann.org/registries/reports/registry-failover-01jun07.htm</a>).</p>
<p>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.</p>
<p>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.</p>
<h4>Discussion of Issues</h4>
<p>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:</p>
<p>Provide a period of ongoing operations until a replacement entity may be engaged, or </p>
<p>Failing that, provide a period of notice to registrants of impending
closure so that registrants may take their own remedial measures.</p>
<p>These goals were developed in answer to the following issues:</p>
<ul><li style="margin-bottom: 15px;">Definition of ICANN's duty to registrants in the event of a failure of a gTLD registry?</li><li style="margin-bottom: 15px;"> To what extent should there be a guarantee that a registry will not fail?
</li><li style="margin-bottom: 15px;"> How should ICANN aid in securing services for operation of a registry?</li><li style="margin-bottom: 15px;">
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?</li><li style="margin-bottom: 15px;"> What are the scenarios in which a registry would be allowed to fail without such a temporary or permanent failover mechanism?</li></ul>
<p>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.</p>
<p>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.</p>
<h4>Summary of Recommendations</h4>
<p>ICANN's 1 June 2007 registry failure report, posted at <a href="http://www.icann.org/announcements/announcement-4-01jun07.htm">http://www.icann.org/announcements/announcement-4-01jun07.htm</a>, identified seven critical functions of a registry:
</p>
<ol><li style="margin-bottom: 15px;">maintenance of nameservers and DNS</li><li style="margin-bottom: 15px;">the Shared Registration System</li><li style="margin-bottom: 15px;">WHOIS</li><li style="margin-bottom: 15px;">
Registrar Billing and Accounting Information</li><li style="margin-bottom: 15px;">Data security and Data Escrow</li><li style="margin-bottom: 15px;">IDN tables (for those registries offering IDNs), and</li><li style="margin-bottom: 15px;">
DNSSEC keys (for those registries that have employed DNSSEC). </li></ol>
<p>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:</p>
<ol><li style="margin-bottom: 15px;">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.</li><li style="margin-bottom: 15px;">Registries must develop and implement their own contingency plans, including the designation of a backup registry operator.</li><li style="margin-bottom: 15px;">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.</li><li style="margin-bottom: 15px;">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.</li><li style="margin-bottom: 15px;">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.</li><li style="margin-bottom: 15px;">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.</li><li style="margin-bottom: 15px;">Registries should implement geographic diversity of DNS services.</li><li style="margin-bottom: 15px;">Where appropriate, ICANN will consult with experts in contingency and scenario planning, and the event of registry failure.
</li><li style="margin-bottom: 15px;">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.</li><li style="margin-bottom: 15px;">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.</li><li style="margin-bottom: 15px;">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.</li><li style="margin-bottom: 15px;">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.</li><li style="margin-bottom: 15px;">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: <ol style="list-style-type: lower-alpha;"><li style="margin-bottom: 15px;">Expiration without renewal of registry or sponsorship agreement</li><li style="margin-bottom: 15px;">Termination of registry or sponsorship has been terminated
</li><li style="margin-bottom: 15px;">Joint request by registry and ICANN</li><li style="margin-bottom: 15px;">No successful verification reports for a Full Deposit in a one-month period</li><li style="margin-bottom: 15px;">
Nonpayment of fees by registry</li><li style="margin-bottom: 15px;">Mandated release by a court, arbitral, legislative, or government agency of competent jurisdiction</li></ol>
</li></ol>
<h4>Conclusion</h4>
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