Blog: Applicant Guidebook

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.

ICANN has been quiet lately, very quiet. It has been making everyone nervous and leaving the field open to ICANN’s enemies, which has in turn encouraged domain industry hacks to resort to long “think pieces” in the absence of news — always a cause for concern.

Today, though, ICANN released a number of results and initiatives that are quite newsworthy. There’s a lot to digest and report on, which should keep the journalists a safe distance away from Wondering What It All Means.

Among the releases from ICANN:

• A new updated Applicant Guidebook. It is missing the important word “final,” but does nail down some dates and clarifies some GAC issues. Still unanswered, in the guidebook or elsewhere, are questions about the Continuing Operations Instrument (a ham-fisted business-killer that has raised many concerns). Nonetheless, for those thinking of applying, a must-read. ICANN unfortunately did not publish a red-lined version to quickly see the changes from the last version, though there is a Summary of Changes to the Applicant Guidebook.
• A new web site devoted to the gTLD program. Until today, looking at the main ICANN homepage, you’d never guess that the major undertaking of ICANN’s history was about to get underway. Now, however, the photo of CEO Beckstrom and the guys from .BR, which looked like it was lifted from the annual report of a Minsk tractor factory, has been pushed down to make way for the headline “New gTLD Program In High Gear,” accompanied by some stock photography of a woman looking determined and competent. On the gTLD mini-site, there’s a section with videos of “experts” (some are, some aren’t) as well as an FAQ, knowledgebase, latest materials, and so on. It’s still in development, and that’s ok. Let’s hope it keeps developing.
• The final report of the contentious and dysfunctional JAS Working Group concerning support for disadvantaged applicants. You can’t read the report yet (at least I can’t) but it should be made public soon. This has been listed as one of the major issues left unsolved from the Singapore meeting in June. If you’re a serious ICANN geek, you can listen to the working group session (thanks to Joly MacFee of ISOC NY)

It’s good to see ICANN breaking their radio silence and providing a useful resource to applicants.

Some TLD applicants have been saying that they’re “community” applications, which means that would avoid an auction and prevail over even deep-pocketed competitors. But according to ICANN’s Applicant Guidebook, very few if any applications will qualify as a community. If you’re an applicant who’s been telling your supporters or investors that you’re going to win because you’re a community, you might want to take a step back.

This post will look at the reality of who will gain community status under ICANN rules. A few already-announced TLD applications that are commonly thought to be communities — but none of them are even close to qualifying.

One announced applicant for .ECO keeps putting out notices about the “.ECO community.” A .GAY applicant makes lots of references to the gay community. And a well known .MUSIC applicant wrote a blog post just a few months ago that he would file a community application. (Note: Minds + Machines has announced support for bids for .ECO and .GAY — so we’ve looked at this question closely.)

Most people would say there is such a thing as the gay community, maybe music and eco communities not so much. But it doesn’t matter: from the ICANN point of view none of them will qualify for “community status” in their gTLD application. Under ICANN rules, even the “ICANN community” wouldn’t qualify as a community.

Scoring the Apps

Let’s score .ECO, .GAY, and .MUSIC. Turn to section 4.2.3 of the Guidebook, called “Community Priority Evaluation Criteria” and read through how they will score each criterion. Remember, you have to get 14 out of 16 points to beat out your non-community competitor. If you don’t get 14 points, you can still proceed to an auction, but you’re stuck with all the rules you put in place to try to qualify as a community.

Here is a table showing how I would score each of these TLDs would score in a “community priority evaluation.” If you go through the guidebook and score them yourself, you might disagree by a point or maybe two, but if you did, they would get a lower score. The scoring I used is very generous. Explanations follow the table:

Let’s go through it. There are four criteria groupings, and subparts below each one.

Criterion 1: Community Establishment

Part A is “delineation,” which means a “clear and straightforward membership definition.” Members of .ECO are…? People who believe in ecological causes? Not terribly clear. Score of 1. .MUSIC? People who like music? Even worse but there is some connection, a charitable score of 1. .GAY? People who say they are gay? Leaving aside how they’re going to check (that comes later), it’s not super clear, especially as the gay community itself typically embraces bisexual and transgendered people. Generously, we will give .ECO 1, .GAY 1, .MUSIC 0.

Part B is “extension,” which means a community of “considerable size and longevity.” If you accept that these are communities, everyone here scores 2 out of 2.

Criterion 2: Nexus of the Proposed String and Community

Part A is “Nexus,” which looks at how closely the TLD name describes the supposed community. ECO doesn’t really match the name of the movement (it is also called the green movement, or the conservation movement), MUSIC isn’t really about people, but OK, and GAY pretty much means gay people. Out of a possible 3, I score .ECO 1, .GAY 3, .MUSIC 2.

Part B is “Uniqueness,” which asks if there is any other meaning of the word. ECO could easily mean “economics,” GAY doesn’t really mean anything else these days, and MUSIC means lots of things, as big generic words do. Out of 1, .ECO gets 0, .GAY 1, and .MUSIC 0.

Criterion 3: Registration Policies.

The stricter you are, the higher you score. Because you can set your own registration policies, everyone gets the maximum score on this one, though on an application they might not, since super-tight registration rules are suicidal for most TLDs. Also, if you don’t pass the community test, you still have to enforce your registration policies (more on that below). So, as a very generous “gimme”: out of 4 possible points: .ECO 4, .GAY 4, .MUSIC 4.

Criterion 4: Community Endorsement

This is where community applications go to die. If there is any significant objection to your application carrying the banner for the community, you will lose two points, which means that you have to be perfect on every other point — highly unlikely.

Part A is “Support.” If everyone supports you, 2 pts; if you have some support, 1 pt.; no support, a zero. Out of 2 pts., .ECO gets 1, .GAY gets 1, .MUSIC gets 1

Part B is “Opposition,” which can easily come from your competitors. The standard is “relevant opposition from one [or more] group of non-negligible size.” They don’t have to prevail in their opposition for you to lose points — they just have to file. I think all of these applications will have some opposition from more than one quarter. Out of a possible 2 pts., I have .ECO with 0, .GAY 0, .MUSIC 0.

.GAY is clearly the strongest case for community of these three applications, but still falls far short at 12 pts out of 16. .ECO and .MUSIC don’t even come close.

So Who Is a Community?

The only way to make sure you qualify as a community is to *be* the community. The American Association of Retired Persons (AARP) could get .AARP as a community TLD, because they own the entire name: there is no-one who could object. In this sense a community in the ICANN sense is just like a brand, complete with intellectual property rights, except that it may not have a corporate structure or a profit motive. Otherwise I can see very little difference.

The key factor in the way ICANN has set this up is that although it’s very hard to qualify as a community, it’s very easy to object to one, and that’s where community applications will falter even if they are strong in other areas. Any institution of “non-negligible size” that claims to represent a community (loosely defined) can object to a community (very tightly defined) application. If one such institution objects, you lose a point. If two or more do, you lose two points. (They can object even if you’re not a community, but in that case they have to prevail — a community application loses points even if the objection is not upheld.)

Bottom Line: Think Very Hard Before Applying As a Community

If you have a competitor with some support, or if you haven’t made sure that every organization in your community is on board, you are highly unlikely to pass the community priority evaluation. And since that evaluation only happens if you do have a competitor or a community objection, in most cases it makes no sense to apply as a community. If you have credible competition, you almost certainly will not pass the community priority evaluation, and you will be stuck with restrictive policies that will be very hard to change later.