ICANN’s Registry Transition Document: A Look Into the Future of Running a Registry

I’m guessing that few people have bothered to read the gTLD Registry Transition Processes document, which came out earlier this week, along with the Draft Applicant Guidebook (DAG) Version 4. Its name promises a very boring recitation of things to do when a registry needs to make a transition, which is of interest to no-one just yet because ICANN hasn’t even started the process to create any of the new registries that might one day be transitioned.

And yet there are in it some eye-opening clues about how ICANN is going to try to regulate the new gTLDs.

The document opens with a portentous recounting of ICANN’s core values, specifically “Core Value #1,” which is “preserving and enhancing the operational stability, reliability, security, and global interoperability of the Internet.” The idea is that if a registry changes hands, the transition must be undertaken in a way that Core Value #1 is preserved.

So far so good. But once we move past this catechism, we find that the document is just as concerned with preserving and extending the political levers that have been gradually inserted into the DAG over the last year. We find that “transition” means not just changing ownership, or wholesale replacement of the back-end registry, but also very minor things like name changes or small parts of outsourced technical services, and that any changes might need approval of third parties, including governments. It introduces dangerous consequences for any breach (even minor) of the Registry Agreement, including an entire re-evaluation of the registry similar to the initial application process. New “Emergency Operators” will be contracted to take over a registry in the case where ICANN determines that there’s a problem. And all of this will mean new fees and new bureaucracy.

Here is ICANN’s matrix for the kind of evaluation will be required.

In more detail, this is what registries of new gTLDs can look forward to:

Name Change

If the registry wants to change its name, it will be re-evaluated to “ensur[e] it is legitimate to guarantee there is no opportunity for hijacking the TLD.” The language is symptomatic of ICANN’s attitude to applicants, which is to treat them as potential scoundrels. This is in marked contrast to its attitude toward some government players, who are actual, verifiable, proven scoundrels (see “IDN ccTLDs for corrupt states, fast-track process for”). I am not sure what “hijacking the TLD” might mean, and the document does not explain. Suffice it to say that changing your name from “123 Inc.” to “1234 Inc.” will bring ICANN’s suspecting scrutiny upon you.

Sale of Registry

Selling your registry will now be more like selling your co-op in New York City. It’s not enough to find a buyer; you have to convince the Board of the buyer’s worthiness. The Board will put the buyer through the same wringer that you went through as an original applicant, with the same level of fees, and they can turn down the buyer for any number of reasons. There will be an evaluation of fitness from a technical, financial, and “due diligence” perspective. This last category is not defined but presumably refers to the new extensive background check. There is as yet no objection process for governments or the IP lobby to air their fears, but I would be surprised to not see this coming in further iterations of this document. One effect of this policy will be to make a sale to an existing player much easier than to a new entrant, thus concentrating commercial power and discouraging competition.

Fees

Each new owner (even if it’s the same one, with a new name) will have to go through some evaluation process. Every 3rd-party evaluator has to be paid. ICANN does not specify the dollar amounts, but I wouldn’t look for a bargain here. A full-on evaluation could easily run into the hundreds of thousands of dollars.

Geographical TLDs

In a sale (or even, apparently, for a simple name change) the new owner will have to gather the same governmental support or non-objection letters that the original applicant did. Effectively, the relevant government(s) will have veto power. In addition, despite language that creates a presumption of renewal of registry contracts at the end of the contract term, governments are now given the power to withdraw their support of the current registry in favor of another. Normally I would congratulate government officials on their sudden access to season tickets, expensive lunches, and access to no-show jobs should they ever leave the employ of the people, but in fact the model that ICANN supposes is unlikely to exist: I believe that in just about every case it will be the government who holds the delegation to geographical TLDs, and they will hire out the technical functions, preserving their power to do whatever they want, whenever they want.

Community TLDs

Running the registry for a community TLD just got much worse. ICANN’s new rules insert the nebulous concept of “community” directly into the operational life of the registry, instead of just the policy aspects. So, if you are the registry for a community TLD and want to change your name or move to a new back-end provider, your community must be “consulted.” No mechanism is specified about how to consult a community, so chaos is invited. I wonder what consulting the community of Harley Davidson enthusiasts looks like…

Registries in Breach of Contract

A registry may find that ICANN decides that it is in breach of its registry agreement with ICANN. This breach could be because of non-payment of fees, excessive downtime of the WhoIs server, or whatever. If it is uncured, a re-evaluation will follow before the registry is allowed to resume operations. The re-evaluation may include recertification by a government, approval by a relevant community, and other “due diligence” items. It’s just like applying for the first time.

Emergency Back-End Registry Operators

Here is a new beast, the Emergency Operator. Aspirants for this position will fill out an RFP and if they are chosen will be paid to be on stand-by until there’s an emergency, at which point they will be paid to be emergency responders, which ICANN “expects” will be on a cost-recovery basis. They are for the case where a registry can’t perform its functions properly. It’s a good idea in theory, but I wonder what exactly a third party can do in an emergency. A registry has two essential functions: the register (the list of names and associated data) and the resolution (DNS). There are other functions such as a WhoIs server. In this era of hyper-redundant anycast DNS I don’t see resolution being much of an issue. As to the register function, if it’s screwed up, it’s likely to be because of bad processes and bad record keeping, which lead to bad data, and this is not really fixable in an emergency; the whole thing needs to be checked and rebuilt. These new Emergency Operators will have to enter into contracts (“lightweight contracts,” ICANN suggests) with the registrars of the existing registries for which they are backups, creating a whole new layer of bureaucracy. I understand the idea, but wonder if the cure might be worse than the disease.

Summary

The Registry Transition Processes document is a clue to what it’s going to be like to run (or sell) a registry under the new ICANN regulatory regime. For the first time there is a semi-official recognition of the back-end registry operator; there are new colo-rectal exams whenever there is acquisition or other change in corporate structure; there are new fees; and there is an expanded role for governments, whose mission-creep is seen in all areas of ICANN these days.

One effect of this new regime will be to create heavy incentives for registries to stick with whatever back-end registry provider they happen to have. It’s not quite lock-in, but it’s close, because choosing a new one will carry significant costs and risks. The big winners here are the providers of back-end registry services.

If you’re thinking of applying for a new gTLD, you should familiarize yourself with the full document, and comment on it, because it’s going to be important for the life of your registry after delegation.