RE: Registry failure report
Thanks for the invitation to comment on the registry failure plan. Most of it 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. Regards, John Levine, johnl@xxxxxxxx, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor "More Wiener schnitzel, please", said Tom, revealingly. |