ICANN ICANN Email List Archives

[registry-failover-plan]


<<< Chronological Index >>>    <<< Thread Index    

Revised Summary and Analysis of Comments

  • To: <registry-failover-plan@xxxxxxxxx>
  • Subject: Revised Summary and Analysis of Comments
  • From: Patrick Jones <patrick.jones@xxxxxxxxx>
  • Date: Thu, 21 Aug 2008 11:38:35 -0700

Revised Summary and Analysis of Public Comments for: ICANN's gTLD Registry
Failover Plan

The original summary and analysis of comments was posted on 18 August 2008.
VeriSign submitted a comment on 13 August 2008, but this was initially
posted on the wrong forum. The VeriSign comment has now been added to the
Registry Failover Plan forum. Staff submits this revised summary and
analysis of comments to incorporate the contributions submitted by VeriSign.

The public comment period on ICANN's gTLD Registry Failover Plan ran from 15
July to 14 August 2008. 3 comments were received (one from VeriSign, one
from ICANN's Security and Stability Advisory Committee, and one from Karl
Auerbach). The public comments on this forum are archived at
http://forum.icann.org/lists/registry-failover-plan/.

VeriSign Comment

VeriSign complemented ICANN staff for the work done to date with registries
to develop the Plan, and raised a number of general comments about the Plan
to be considered as ICANN works on implementation.

VeriSign notes that the Plan should not be viewed as a replacement or
augmentation of existing registry agreements. The Plan may be considered as
a crisis management plan for ICANN and best practice document for registry
operators. VeriSign suggests that the terms of the Plan should be consistent
with the terms of the registry agreements and with registry-registrar
agreements (RRAs). VeriSign cites some examples of terms that should be
checked, such as times specified in the service level agreements, the
inclusion of a force majeure paragragh, and definitions.

VeriSign questions how ICANN will ensure that registry sensitive information
will be protected, and raises implementation questions on situation handling
and event management.

VeriSign notes that release of data from escrow should be consistent with
the terms of the registry agreement, and that ICANN should have a procedure
for this in place before an event occurs. VeriSign also suggests that ICANN
develop a base agreement with a backup registry operations provider as a
proactive step to ³minimize the time needed to implement backup operations
if needed. Even if an agreement is in place with a back-up operator it is
naïve to believe that a smooth quick transition will take place in a crisis
situation as more than escrowed data is required to reconstitute a
registry.²

VeriSign asked for clarification in the Business Continuity section of the
Plan on the references to the ³backup registry operations provider², such as
who is responsible for paying the backup provider to maintain backup
capability. VeriSign notes that Section 5.9 may require a new IANA ³process
to authenticate/validate requests if the technical and admin contact are no
longer available² and that such a process may also involve consultation with
the US Department of Commerce.

SSAC Comment

Steve Crocker provided a comment on behalf of ICANN¹s SSAC. SSAC believes
that ³the plan is implementable and that testing will help confirm whether
the plan is comprehensive (complete).²

SSAC asked if there were efforts to define ³continuity metrics² or
³accountability metrics², such as what service levels a registrant can
expect or how long name service will persist following the different types
of failure.

SSAC noted the considerable time and energy invested in the current gTLD
Registry Failover Plan, and wished to remain informed of plans for live
testing with registries. See
http://forum.icann.org/lists/registry-failover-plan/msg00004.html.

Auerbach Comment

Karl Auerbach raised a number of critical points about the gTLD Registry
Failover Plan. He believes the plan presumes that all registries now or in
the future provide reliability of services on par with the .COM registry,
and questions whether this must remain the case. He suggests the key matter
is ³that consumers know in advance of their purchase so that they may know
the nature and quality of support of the name that they are acquiring² and
that consumers ³ought to have the ability to make informed choices whether
to buy a name from a high-preservation registry/TLD or from one that offers
a less expensive but less protected alternative.²

Auerbach believes the Plan imposes complex, rigid and expensive procedures
on new gTLDs and consumers who do not need names ³encumbered with the costs
of this preservation system.²

He suggests an alternative requirement that registries publish a yearly
statement signed by an independent expert auditor attesting that the
registry has, performs, and periodically tests systems and procedures of
business asset preservation, and that those procedures are adequate to allow
speedy resurrection of the registry.

Auerbach believes that the plan does not provide flexibility to gTLD
registries to ³restructure a non-performing product². He questions how the
Plan fits under laws covering bankruptcy, bulk transfer of assets,
e-discovery or privacy of registrants.

Auerbach also raises issues that are outside the scope of the gTLD Registry
Failover Plan, such as providing third party beneficiary rights for domain
name registrants to contracts between ICANN and registries, a formal
structure for registrants within ICANN and ICANN¹s growth. See
http://forum.icann.org/lists/registry-failover-plan/msg00000.html.

Next Steps

ICANN is developing the implementation of the gTLD Registry Failover Plan
and is planning a test exercise with experienced registries in Fiscal Year
09. Further information about the implementation and test exercise will be
made available in the near future.
-- 
Patrick L. Jones
Registry Liaison Manager &
Coordinator, ICANN Nominating Committee
Internet Corporation for Assigned Names & Numbers
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
Tel: +1 310 301 3861
Fax: +1 310 823 8649
patrick.jones@xxxxxxxxx   





<<< Chronological Index >>>    <<< Thread Index