Trojan TLDs to get more scrutiny

ICANN has proposed a new policy for its new top-level domain program that would make it harder for community-based TLDs to liberalize their registration policies after they launch.
The idea is to prevent a replay of the recent .jobs controversy, in which registry Employ Media substantially altered its business model after failing to sell enough .jobs domains.
Because the Applicant Guidebook gives “community” TLD applications an opportunity to avoid a potentially costly auction if their TLD is contested by multiple applicants, there’s a risk of gaming.
Under the current rules, a company could win a contested TLD without paying big bucks, by promising to restrict it to a narrowly defined community of registrants.
It could later attempt to change its rules via ICANN’s Registry Services Evaluation Process to broaden or limit its potential customer base, potentially harming others in the community.
I call these Trojan TLDs.
Employ Media, for example, restricted .jobs domains to the names of companies, but now has licensed thousands of geographical and vocational generic names to a partner, over the objections of major jobs search engines such as Monster.com.
Under ICANN’s proposed policies (pdf), community TLDs would still have to pass through the RSEP, but they’d also be subject to a review under the Community Priority Evaluation.
The CPE is already in the Guidebook. It will be used to score applications based on the strength of community support. To avoid an auction, you need to score 14 out of 16 points.
ICANN now suggests that the CPE criteria could also be used to evaluate what it calls a “Community gTLD Change proposal” made by a TLD registry post-launch.
The new score would be used to determine whether to accept or reject the change:

If the sum of all identified score changes for the first three CPE criteria is zero or positive, the recommendation would be to accept the proposal, regardless of any relevant opposition identified. If the sum is minus one, the recommendation would be to accept the proposal, unless there is relevant opposition from a group of non-negligible size, in which case the recommendation would be to reject the proposal. If the sum is minus two or lower, the recommendation would be to reject the proposal.

The ICANN board would be able to deviate from the CPE recommendation, as long as it stated its reasons for doing so, and the registry would have the right to appeal that decision under the existing Reconsideration Request process.
These rules would apply to all new TLDs that designate themselves as community-based, apparently regardless of whether they successfully passed the CPE during the application process.
The rules are presented as a “discussion draft”, but I don’t think they’re going to be opened to official public comment.

ICANN to tackle Trojan TLDs

When failing community-based top-level domain registries attempt to change their business models, ICANN may in future have a new way of dealing with them.
That seems to be a possible result of Employ Media’s controversial .jobs liberalization plans and the subsequent Reconsideration Request, which I blogged about last week.
The .jobs reconsideration revealed that not only are Reconsideration Requests a rubbish way to appeal ICANN’s decisions, but also that the Registry Services Evaluation Process is often a rubbish way to handle major contract changes.
The RSEP was introduced back in 2005 in belated response to a couple of controversial “services” that VeriSign, testing boundaries, had planned to unilaterally introduce in the .com registry, notably Site Finder and the Waiting List Service.
But since then the process has been used as a general-purpose tool for requesting changes to registry contracts, even when it’s debatable whether the changes fit the definition of “registry services”.
For example, when .jobs launched five years ago, it was put into Employ Media’s contract that the TLD was designed for companies to register their brands and list their jobs, and that’s all.
But that model didn’t work. It’s one of the least successful TLDs out there.
So the registry decided it could make more money with general purpose jobs boards, using generic .jobs domains. But it did not necessarily want to let existing independent jobs sites take part.
For want of a better term, I’ll call this an example of a “Trojan” TLD – a registry that gets its attractive TLD string approved by ICANN after making a certain set of promises, then later decides to move the goal posts to broaden its market, potentially disenfranchising others.
I’ve no reason to believe it was a premeditated strategy in Employ Media’s case, but precedent has now been set for future TLD applicants to use “community” as a foot in the door for broader aspirations.
To take a stupid, extreme, unrealistic example, imagine that ICM Registry’s .xxx flops badly. Should the company be allowed to start selling all the good .xxx domains to churches and other anti-porn campaigners? That would be a pretty big departure from its promises.
There were similar concerns, although not nearly as loudly expressed, with regards to Telnic’s recent contract changes, which will allow it to start registering phone number domain names in .tel, despite years of promises that it would not.
Go Daddy’s policy chief Tim Ruiz objected to the proposal on the grounds that it would be “unfair to other [.tel] applicants and potential applicants to allow an sTLD to change its purpose after the fact.”
The ICANN Board Governance Committee, which handles Reconsideration Requests, acknowledged these problems in its decision on .jobs in Cartagena (pdf), concluding that it:

thinks that the Board should address the need for a process to evaluate amendments that may have the effect of changing, or seeking to change, an sTLD Charter or Stated Purpose of a sponsored, restricted or community-based TLD.

The BGC seems to be saying that the RSEP is not up to the task of dealing with community-based TLDs that later decide their business plans are not the money-spinners they had hoped and want to loosen up their agreed community restrictions.
The committee went on to say that:

Because such a process may impact gTLDs greatly and is a policy issue, the GNSO is the natural starting point for evaluating such a process. We therefore further recommend that the Board direct the CEO to create a briefing paper for the GNSO to consider on this matter, and for the GNSO to determine whether a policy development process should be commenced.

So the GNSO will soon have to decide whether new policies are needed to deal with broad contract changes at failing community TLDs.
Any new policies would, I believe, be binding on community TLDs approved under the new gTLD program as well as older sTLDs, so it will be an interesting policy track to follow.