Blog: Community TLD

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.

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.