|
|
|
Click the comments link on any story to see comments or add your own. Subscribe to this blog |
07 Dec 2008
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:
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.
|
TopicsMy other sitesOther blogsCAUCE A keen grasp of the obvious Related sitesCoalition Against Unsolicited Commercial E-mail |
||||||||||||||||||
© 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.
