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

←2008→ Months Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 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 posted at: 10:06 :: permanent link to this entry :: 0 comments comments...        (Jump to the end to add your own comment) Add your comment... Note: all comments require an email address to send a confirmation to verify that it was posted by a person and not a spambot. The comment won't be visible until you click the link in the confirmation. Unless you check the box below, which almost nobody does, your email won't be displayed, and I won't use it for other purposes.   Name: Email: you@wherever (required, for confirmation) Title: (optional) Comments: Show my Email address Save my Name and Email for next time

Topics Copyright Law - 29 Email - 228 ICANN - 127 Internet - 73 Money - 31 Security - 3 My other sites Who is this guy? Airline ticket info Taughannock Networks Other blogs CAUCE It turns out you don’t need a license to hunt for spam. 26 days ago A keen grasp of the obvious Italian Apple Cake 584 days ago Related sites Coalition Against Unsolicited Commercial E-mail Network Abuse Clearinghouse

© 2005-2020 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.