[AfrICANN-discuss] ICANN's gTLD Registry Failover Plan

[Anne-Rachel Inné]

ICANN's gTLD Registry Failover Plan

20 October 2007

ICANN is today posting its gTLD Registry Failover
Plan<http://www.icann.org/registries/failover/draft-plan-20oct07.htm>for
public comment. Comments on the plan may be submitted to
registry-failover-plan at icann.org
<%20registry-failover-plan at 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<http://www.icann.org/registries/failover/draft-plan-20oct07.htm>and
flow
chart<http://www.icann.org/registries/failover/draft-plan-flow-chart-20oct07.pdf>[PDF,
84K] form) and Best
Practices<http://www.icann.org/registries/failover/draft-plan-best-practices-20oct07.pdf>[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.afrinic.net/pipermail/africann/attachments/20071021/fd0a1829/attachment-0001.htm