ICANN’s Brain-Dead Plan to Punish New gTLD Registries for No Good Reason

The COI + the EBERO: A Recipe to Create Failed Registries

ICANN’s current plan for a Continued Operations Instrument (COI) is a self-insurance scheme that asks registries to tie up a massive amount of cash, when much cheaper and more sensible options are available. The COI is a massive barrier to entry for all applicants, and one that hits smaller registries and those from developing countries with disproportionate weight. The COI requires massive amounts of cash to be set aside in case of business failure. It is so punitive that it will certainly encourage falsely conservative sales volume estimates by applicants, and likely to lead to higher prices for registrants. Combined with the Emergency Backend Registry Operator (EBERO) RFI, it will rob developing registries of much-needed funding during their critical first few years, and use the funds from the resulting failures to reward large incumbent registries. This is not a conspiracy theory — several incumbent registries, notably Afilias, also recognize this plan as dumb and have been working actively to make it more sensible: all boats float on a rising tide, and sink together too.

While registrants do need to be protected against registry failure, the ICANN formula for the COI seems much better calculated to cause registry failures than to prevent them.

The requirements for the COI are given in Question 50 of the Application Guidebook. Basically, the applicant has to set aside funds (or get a letter of credit) to assure “core registry functions” for 3 years. Core registry functions are: access to the shared registry system; Whois, DNS resolution; data escrow; and DNSSEC. That sounds reasonable enough until you start to get into the details — and the difference between what this would actually cost and what ICANN wants set aside.

At a recent session at the ICANN Dakar meeting dedicated to the COI, no-one spoke in favor of the current COI requirement. A registry stakeholder group proposal that would pool the risk was shot down by intellectual property interests, who predictably were not in favor of a mandatory payment to protect others (large companies will have no problem coming up with the COI). Others insisted that the pool was a form of insurance, and ICANN should not be in the insurance business. But some preliminary ideas toward the solution proposed in this post did receive some support. The way forward is provide estimates of actual likely costs, instead of the “sky is falling” scenario that the current plan envisages. Several groups are working to gather such data to present to ICANN. This post critiques the current system and provides an outline for a way forward.

Delay Is Not an Option

A short but important point: changing the amount of the COI does not mean a delay: it is not a change in policy, it is only a method for more reasonably estimating cost. The EBERO RFI, as the name implies, is a request for information. This too can be modified within the parameters of existing policy. Everyone involved in trying to reform this crazy mechanism has spoken out against any delays.

The Amount of the COI Is Directly Tied to the EBERO

Quoth the Guidebook:

The Continuing Operations Instrument (COI) is invoked by ICANN if necessary to pay for an Emergency Back End Registry Operator (EBERO) to maintain the five critical registry functions for a period of three to five years. Thus, the cost estimates are tied to the cost for a third party to provide the functions, not to the applicant’s actual in-house or subcontracting costs for provision of these functions.

Note that ICANN is building a model for these costs in conjunction with potential EBERO service providers. Thus, guidelines for determining the appropriate amount for the COI will be available to the applicant. However, the applicant will still be required to provide its own estimates and explanation in response to this question.

That’s what the Guidebook says, but that’s not what the EBERO RFI says. The EBERO is filled with extraneous requirements that have nothing to do with core registry functions, with the result that only large incumbent registries can qualify.

What Are the Real Costs of Transitioning a Failed Registry?

A registry stakeholder group presentation estimates that the current system would require a registry with 100,000 names in Year 3 to set aside $450,000, and a registry with 1,000,000 names in Year 3 to set aside $4,500,000. Will this kill any growing business? Is this more than most registries’ estimated profit margin? Is this completely crazy? Yes, yes, and yes.

You would think that ICANN would have done some research into the real costs of providing these five core functions to a failed registry. Maybe they did, but it doesn’t show. Let’s look at what it will actually cost. There are a few answers:

• The first and most likely answer is “almost nothing,” because the registry service provider of a failing registry can easily be persuaded to continue these operations (M+M guarantees it for their clients). That’s because in their assessment the risk is low (or they wouldn’t work with the registry in the first place) and because their incremental cost to do so is in fact near zero.
• A second answer is also “almost nothing,” because even supposing the registry operator *in addition to the registry* were to fail (a very low likelihood), in most cases any other registry service provider would be happy to pick up the names, since their incremental costs to run additional names are also near zero (there are transition costs, but these are not great — M+M transitioned a sizable zone over a weekend).
• A third answer is the ICANN way: multiply the estimated volume registrations by a dollar amount to be determined by the results of the EBERO RFI — which is only open to the most expensive incumbent registries, who charge orders of magnitude more than smaller, perhaps more efficient registries. (As one example among many, VeriSign charges $7 per name per year for .com names; Minds + Machines and many of its competitors charge less than $2 at a fraction of the volume of .com — and per-unit costs generally fall with increased scale).

Fortunately, there are plenty of examples of transition costs drawn from both the ccTLD and gTLD world that provide actual costs, and there is an effort to gather up these examples and provide them to ICANN, to give them cover (sigh) to do something sensible.

Accrediting Registry Service Providers

ICANN doesn’t like Answers 1 and 2, because (they say) “How do we know that the new registry service provider can do the job?”

Actually, the question should be reframed, “Why don’t you know?” because frankly they should know already. ICANN’s reluctance to accredit registry service providers is the greatest source of unnecessary cost and delay in the post-application period.

Without a doubt the biggest inefficiency of ICANN’s new gTLD process is the silly requirement of answering the entire tech section for each and every application. There are only a few registry service providers — Minds + Machines is one of perhaps ten — and nearly every application will use one of them. Although it’s theoretically possible to file an application for a system that’s not yet built, the level of detail required by the application effectively requires an existing, working registry. And yet for each new gTLD application, the tech section, the bulk of the application, will be reviewed anew in its entirety. So if there are 1000 applications, the evaluation of the tech section will be duplicated effort for 990 of them. I defy anyone to defend this as sensible.

Why did ICANN not simply accredit registry service providers, so that applications using accredited providers would not need to be tested and retested. Given that the application fee is based on cost recovery, an accreditation process would surely have reduced the $185,000 to something more manageable. Now that this opportunity has passed, accrediting registry providers for the five core registry functions is surely possible.

Happily, the fix is within reach and will not require further policy development or delay, if only ICANN comes to its senses. One obvious solution lies in amending the current EBERO RFI. In fact, amending the EBERO RFI could result in huge cost and time savings across the board.

The EBERO: Gold Mine for Incumbent Registries, Paid for by Applicants

The EBERO as written could be retitled the “Incumbent Registry Free Money RFI.” It is in fact a registry service provider accreditation program, but only for the chosen few. It is written to exclude any provider who is not a high-volume incumbent, assumes a .com-like one-size-fits-all model, and includes pages of requirements that have nothing to do with providing “core registry services,” even though Question 50 of the Guidebook links the two explicitly. In fact, the EBERO is filled with requirements that aren’t required of applicants in the Guidebook. Why are they required here?

Here are some examples of overreaching EBERO requirements (picked from among many such entries):

• High Capacity traffic service capability
• Ability to handle up to 20,000 concurrent client connections and a daily minimum peak volume of 2 million transactions with a read/write ratio of 10/1 (based on an estimated 1 million aggregate domains in the EBERO).
• Provide examples of thought leadership, industry participation, and publications that highlight your experience ["Thought leadership" as a technical requirement? - puh-leeze!]
• Ability to support and maintain IDN registrations
• Multiple DNS service locations that are geographically diverse and can be demonstrated to fully serve global resolutions
• Ability to accept live call volumes from an estimated user base of 300 and an expected contact rate of 15-20% during emergency migration periods without queuing times exceeding 10 minutes

The list goes on, one gold-plated requirement after another. The problems with this approach are manifold, but they all stem from the idea that one registry service provider should be able to handle *any and all* failing registries. That’s just plain silly — why not accredit a diversity of registry service providers as EBERO candidates and then assign failing registries to them according to the requirements of the registry?

Why the EBERO Doesn’t Make Sense As Written

The EBERO doesn’t pass the sniff test:

• Even though the most likely scenario for registry failure is an inability to sell as many names as estimated, resulting in a registry with few names, the EBERO calls for high-volume experience only. If anything, they should be looking for low-volume experience.
• If the failing registry doesn’t sell IDNs, why should the EBERO support them?
• If the failing registry only has 3 registrars, why should the EBERO support 300 concurrently?
• Data escrow, one of the five core registry services, is by definition outsourced. DNS is not outsourced necessarily, but in many cases it makes good sense both financially and technically (for redundancy) to do so. Why does the EBERO need to provide DNS services? ICANN could easily ask for EDNS (Emergency DNS) providers — they would line up to provide reasonably priced services.
• The EBERO as drafted assumes (unreasonably) that it will take 3 years to find a new home for the registry. Instead of providing a gold mine to large incumbent registries with little obligation, why not ask EBERO’s to provide a permanent home? In that case the funding wouldn’t need to cover three years — more like three weeks at the outside.
• Why should billing be suspended during the emergency period? If functions are being provided as normal, why not accept renewals at least, if not new registrations? This would substantially reduce the amount needed in the COI.

The EBERO as written is perfect for the fool who gives away millions of .BLAH registrations and then finds that no-one wants to renew them for money. For everything else, it’s overkill, and tying the COI for all registries to the cost of rescuing .BLAH is unreasoningly punitive. ICANN is asking all applicants to tie up precious cash reserves to cover for ICANN’s poor planning in this regard, and the result will be that new registries will find it hard to market their new TLDs in the critical first years of their registries — leading, inevitably, to registry failures.

Fix the EBERO, and the COI Suddenly Becomes Reasonable

ICANN should ditch the one-size-fits-all EBERO specification, and change it to accept a diversity of models, and rate registry service providers for volume of names, IDN capabilities, and some other criteria. Most of all, they should be rated on their ability to provide the required core registry services, and not on the number of gold-plated toilet seats they have. Once rated, these providers would be accredited for the capabilities they provide. Will this take a while? Maybe, but no new registry will be online for over a year. ICANN should also ask for Emergency DNS providers, since DNS can be easily provided independently of the Shared Registration System. DNS prices in the open market range from free to expensive — again, one size does not fit all. Overall, the prices for emergency services would drop drastically, and the effect would be to re-price the COI at a reasonable amount.

In a free market, registry service providers would be lining up to provide transition services for free if they were allowed to collect renewal fees for a certain period of time. Why is this not allowed in the EBERO? Only in extreme cases would there be no takers, and only then should a larger payment be invoked. The EBERO as written is a gift to large incumbent registries to pick up distressed registries (probably permanently, because why should they move again?), leaving aspiring applicants to pay for their gain via the COI.

There is a better way, and if ICANN (and, ahem, the GAC) actually gave a thought about the real-world issues faced by small registries or those from developing countries, they would insist on tying the COI to a real-world cost, and they would resist give-aways to incumbents through a guaranteed-income scheme paid for by struggling newbies. The COI and EBERO severely reduce choice and competition, and the security they promise is illusory and unsupported by experience or fact. They need to be changed, and the way to do it is to widen the field of emergency providers and thereby reduce the cost of the COI.