Internet and e-mail policy and practice
including Notes on Internet E-mail


Click the comments link on any story to see comments or add your own.

Subscribe to this blog

RSS feed

Home :: ICANN

07 Dec 2008

Comments on ICANN's registry failure plans ICANN

On June 1st, ICANN publised a short report on what they plan to do about registry failure. (It's not a failure plan, it's a plan to develop a plan.) They invited me to comment on it, so here's what I said. You can see all the comments on ICANN's web site; the only other substantial one is the one from Chuck Gomes, although Ed Hasbrouck's questions about the secret amendments to the .AERO registry are interesting, too.

Most of the report is pretty good. The first three sections give a good overview of the software and data involved in running a registry. I agree with the taxonomy of failure scenarios in section 5.

Section 4 tells us that voluntary transitions have consistently worked well, so there is little reason to spend much time and effort worrying about them or setting rules for them.

Sections 6 and 7 are less good. I realize that they're just guidelines for future work, but they have some problematic implicit assumptions, and do not, in my opinion, set out an adequate task list to prepare for many likely failure scenarios.

First, technical failures and business failures present fundamentally different issues. With a technical failure, there's unlikely to be big policy concerns; the job is to get the registry back online. In this regard a registry is not very different from other businesses that run a data-intensive 24/7 network presence such as airlines and stock brokers. A variety of business continuity and disaster recovery providers already address this market, and it would be a poor use of ICANN's limited staff and managerial resources to recreate what they've already done. Indeed, it might be a good idea to hire one or more of them to perform the registry data escrow function, in view of ICANN's inability so far to do it itself.

The main policy question for technical failures is how deeply ICANN should get involved, both in terms of money and management involvement. Personally, my recommendation would be that ICANN should set guidelines, require registries to publish the key facts about their recovery plans, e.g., who the providers are, and how long a failure their insurance will pay for, then stand clear and let registrants make their own decisions. It is quite likely that there are markets both for high quality service at the current high prices, and lower quality service at lower prices, and there's no reason to discourage that so long as registries are clear about what they're offering. To this end, I am surprised at the suggestion in the plan that parts of registries' failure plans would be secret. That would make it much harder for users to compare different regstries' offerings.

On the other hand, business failures present a wide range of policy concerns, and the list in section 7 barely scratches the surface. Sponsored TLDs are smaller and have higher per-registrant overhead than unsponsored, so they're more likely to fail. If one did fail, locating a successor would have the dual issues of finding someone willing and able to do it, and what (if anything) to do to maintain the sponsored nature of the domain. Issues that ICANN should be prepared to address include:

  • If a situation similar to the Registerfly mess occurs, in which the registry claims that it is still operating, despite external evidence to the contrary, how should ICANN decide when a registry has failed?
  • Once it's dead, what criteria would a successor have to meet? For example, would they have to agree to the same prices and other terms as the failed registry?
  • If there's no successor, how long should the domain's DNS continue and who's going to pay for it? If the answer is "the old registry", what happens when the old registry neglected to set aside the wind-down money they said they would?

ICANN is unlikely to have the luxury of delaying for a year before dealing with a registry failure as it did with Registerfly's failure, so it's important to consider the policy questions now and come up with answers, or at least a process to reach answers now, rather than when the clock is ticking.

  posted at: 10:06 :: permanent link to this entry :: 0 comments
Stable link is


My other sites

Who is this guy?

Airline ticket info

Taughannock Networks

Other blogs

It turns out you don’t need a license to hunt for spam.
112 days ago

A keen grasp of the obvious
Italian Apple Cake
670 days ago

Related sites

Coalition Against Unsolicited Commercial E-mail

Network Abuse Clearinghouse

My Mastodon feed

© 2005-2024 John R. Levine.
CAN SPAM address harvesting notice: the operator of this website will not give, sell, or otherwise transfer addresses maintained by this website to any other party for the purposes of initiating, or enabling others to initiate, electronic mail messages.