Plurals ban policy handed to ICANN board

The GNSO Council has approved a blanket ban on singular and plural versions of the same word being delegated as gTLDs in future and passed it to the ICANN board of directors for final consideration.

The proposed policy would prevent anyone applying for the singular/plural equivalent of an existing gTLD, and would put future applications for single/plural clashes into contention sets where only one would survive.

The ban would prevent a future .kitchens, for example, because there’s already a .kitchen, and there could be no .motorcycle gTLD because there’s already a .motorcycles.

It would also mean that if there are future applications in the same round for .podcast and .podcasts, for example, they would be placed in the same contention set, likely go to auction, and only one would be delegated.

Applicants would also be banned from applying for singular/plural variants of the few dozen strings found on a “limited blocked name list” that comprises mainly the names of internet policy organizations including ICANN, the IETF and the GNSO.

That list also includes dictionary words such as “onion”, “invalid”, “test”, “internal” and “local”, so there could never be a .onions or .locals gTLD under the policy.

ICANN would decide whether two strings are “the singular or plural version of the same word in the same language” by reference to a dictionary.

The idea behind the ban is mitigating abusive registrations that could be used in, for example, phishing attacks, as well as lazy gTLD applicants that might hope to piggyback on the success of their single/plural rival.

The policy recommendation was written by a “Small Team Plus” of 15 community volunteers after the ICANN board last year rejected the GNSO’s original singular/plural policy, which would have made exceptions to the ban based on the applicant’s “intended use” of the gTLD.

An example given was that if one applicant applied for .spring to represent the meteorological season and another applied for .springs to represent flexible coils of metal, the latter would not be judged a plural of the former.

But the board was worried that if ICANN had to make a call on “intended use”, ICANN would also have to monitor and enforce the use of the gTLD in future, breaking its bylaws promise not to regulate internet content.

Under the revised policy recommendation, .spring and .springs would be ruled as singular/plural equivalents of each other, regardless of how they were going to be marketed.

While the Small Team was not unanimous in its consensus recommendation, the GNSO Council was unanimous in approving it at its monthly meeting last week. The language will now be sent to the ICANN board for approval or rejection.

Wanted: a gTLD to ban

ICANN may have failed so far to deliver a way for the world to create any more gTLDs, but it’s about to pick a string that it will resolve to never, ever delegate.

It’s going to designate an official “private use” string, designed for organizations to use behind their own firewalls, and promise that the chosen string will never make it to the DNS root.

IP lawyers and new gTLD consultants might want to keep an eye on this one.

The move comes at the prompting of the Security and Stability Advisory Committee, which called for ICANN to pick a private-use TLD in a September 2020 document (pdf).

ICANN hasn’t picked a string yet, but it has published its criteria for public comment:

1. It is a valid DNS label.
2. It is not already delegated in the root zone.
3. It is not confusingly similar to another TLD in existence.
4. It is relatively short, memorable, and meaningful.

The obvious thing to do would be to pick one of the 42 strings ICANN banned in the 2012 new gTLD round, which includes .example, .test and .invalid, or one of the three strings it subsequently decided were too risky to go in the root due to their extensive use on private networks — .corp, .mail and .home.

The SSAC notes in its document that ICANN’s two root server constellations receive about 854 million requests a day for .home — the most-used invalid TLD — presumably due to leaks from corporate networks and home routers.

But .homes (plural) is currently in use — XYZ.com manages the registry — so would .home fail the “confusingly similar” test? Given that it’s already established ICANN policy that plurals should be banned in the next round, .home could be ruled out.

ICANN’s consultation doesn’t make mention of whether gTLDs applied for in subsequent rounds would be tested for confusing similarity against this currently theoretical private-use string, but it seems likely.

Anyone considering applying for a gTLD in future will want to make sure the string ICANN picks isn’t too close to their brands or gTLD string ideas. Its eventual choice of string will also be open for public comment.

There don’t seem to be a massive amount of real-world benefits to designating a single private-use TLD string.

Nobody would be obliged to use it in their kit or on their networks, even if they know it exists, and ICANN’s track record of reaching out to the broader tech sector isn’t exactly stellar (see: universal acceptance). And even if everyone currently using a different TLD in their products were to switch to ICANN’s choice, it would presumably take many years for currently deployed gear to cycle out of usage.

English beats Portuguese in $2.2m .hotels auction

Booking.com has won the right to operate .hotels after an auction concluded a protracted fight over the gTLD.
In an ICANN-run auction yesterday, Booking.com prevailed with a winning bid of $2.2 million.
Its sole competitors was Travel Reservations (formerly Despegar Online), which had applied for the Portuguese word .hoteis.
In 2012, a String Similarity Review panel concluded that .hotels and .hoteis look too similar to coexist, due to the likelihood of confusion between I and l in sans-serif fonts.
Neither applicant agreed with that decision, knowing that it would result in a expensive auction, and Booking.com filed a Request for Reconsideration and then, in March 2013, an Independent Review Process complaint.
After two years, it lost the IRP. But the panel said it had “legitimate concerns” about the fairness of the SSR process and ordered ICANN to pay half of its costs.
Now, Booking.com has had to fork out another $2.2 million for the string.
That’s not particularly expensive as ICANN-auctioned gTLDs go. Eight of the 13 other strings ICANN has auctioned have sold for more.
ICANN’s auction proceeds to date now stands at $63,489,127, which is being held in a separate bank account for purposes yet to be determined.

ICANN wins .hotels/.hoteis confusion appeal but has to pay up anyway

The proposed new gTLDs .hotels and .hoteis are too confusingly similar to coexist on the internet.
That’s the result of an Independent Review Process decision this week, which denied .hotels applicant Booking.com’s demand to have ICANN’s string confusion decision overturned.
But the IRP panel, while handing ICANN a decisive victory, characterized the string confusion and IRP processes as flawed and said ICANN should have to pay half of the panel’s $163,000 costs.
Booking.com filed the IRP a year ago, after the new gTLD program’s String Similarity Panel said in February 2013 that .hotels was too similar to rival Despegar Online’s proposed .hoteis.
.hoteis is the Portuguese translation of .hotels. Neither string was contested, so both would have been delegated to the DNS root had it not been for the confusion decision.
In my view, the String Similarity Panel’s decision was pretty sound.
With an upper-case i, .hoteIs is virtually indistinguishable from .hotels in browsers’ default sans-serif fonts, potentially increasing the ease of phishing attacks.
But Booking.com, eager to avoid a potentially costly auction, disagrees with me and, after spending a year exhausting its other avenues of appeal, filed an IRP in March 2013.
The IRP decision was handed down on Tuesday, denying Booking.com’s appeal.
The company had appealed based not on the merits of the SSP decision, but on whether the ICANN board of directors had acted outside of its bylaws in establishing an “arbitrary” and opaque SSP process.
That’s because the IRP process as established in the ICANN bylaws does not allow appellants to changed a decision on the merits. IRP panels are limited to:

comparing contested actions of the Board to the Articles of Incorporation and Bylaws, and with declaring whether the Board has acted consistently with the provisions of those Articles of Incorporation and Bylaws.

The IRP panel agreed that the SSP process could have been fairer and more transparent, by perhaps allowing applicants to submit evidence to the panel and appeal its decisions, saying:

There is no question but that that process lacks certain elements of transparency and certain practices that are widely associated with requirements of fairness.

But the IRP panel said Booking.com was unable to show that the ICANN board acted outside of its bylaws, highlighting the limits of the IRP as an appeals process:

In launching this IRP, Booking.com no doubt realized that it faced an uphill battle. The very limited nature of the IRP proceedings is such that any IRP applicant will face significant obstacles in establishing that the ICANN Board acted inconsistently with ICANN’s Articles of Incorporation or Bylaws. In fact, Booking.com acknowledges those obstacles, albeit inconsistently and at times indirectly.
…
Booking.com has failed to overcome the very obstacles it recognizes exist.

The IRP panel quoted members of ICANN’s New gTLD Program Committee extensively, highlighting comments which questioned the fairness of the SSP process.
In contrast to usual practice, where the losing party in an IRP bears the costs of the case, this panel said the $163,000 costs and $4,600 filing fee should be split equally between ICANN and Booking.com:

we can — and we do — acknowledge certain legitimate concerns regarding the string similarity review process raised by Booking.com, discussed above, which are evidently shared by a number of prominent and experienced ICANN NGPC members.
…
In view of the circumstances, each party shall bear one-half of the costs of the IRP provider

Booking.com and Despegar will now have to fight it out for their chosen strings at auction.
The full decision can be read in PDF format here. Other documents in the case can be found here.
The TL;DR version: ICANN wins because it has stacked the appeals deck in its favor and the IRP process is pretty much useless, so we’re going to make them pay up for being dicks.

Is ICANN ready to start rejecting some new gTLDs?

Is ICANN getting ready to give marching orders to new gTLD applicants? It seems likely given recent hints out of LA.
Currently, of the original 1,930 new gTLD applications, 125 have been withdrawn but only two or three have been rejected.
GCC’s .gcc and DotConnectAfrica’s .africa are both “Not Approved” while Nameshop’s .idn failed to pass its applicant support program tests and seems to have been put aside for this round.
But there are at least 22 active applications that are due to be hit with the ban hammer, by my reckoning. That’s not including those that may be killed off by Governmental Advisory Committee advice.
First, there are seven bids (so far) that have failed Community Objections or Legal Rights Objections filed against them, or have lost String Confusion Objections filed by existing TLD operators.
Applications such as Ralph Lauren’s .polo, Dish DBS’ .direct and Demand Media’s .cam have fallen foul of these three objection types, respectively.
Under the Applicant Guidebook rules, these applications are not allowed to proceed.
There are also 10 active applications for .home and five for .corp, two gTLD strings ICANN has said it will not approve due to their substantially higher risk of causing name collisions.
(Personally, I think these applicants should get full refunds — ICANN screwed up by not doing its homework on name collisions before opening the application window last year).
So far, ICANN seems to have been waiting for applicants to withdraw, rather than initiating a formal rejection.
But none of them actually have withdrawn.
The International Union of Architects, which won a Community Objection against Donuts over .architect in September, has noticed this too, and recently wrote to ICANN to find out what was going on.
Responding October 31, Generic Domains Division president Akram Atallah wrote (with my emphasis):

as a result of the objection determination, we have updated the status of the objection on the .ARCHITECT application to “Objector Prevailed” on the Objection Determinations page (http://newgtlds.icann.org/en/program-­‐status/odr/determination) of the New gTLD microsite. Additionally, we will be updating the overall status of this application on the New gTLD microsite (https://gtldresult.icann.org/application-­‐result/applicationstatus) pursuant to Section 1.1.2.9 of the Applicant Guidebook in the near future.

This suggests either a “Not Approved” status for .architect, or a new status we haven’t seen before, such as “Lost Objection”.
So could, for example, Demand Media’s .cam application be rejected? Demand lost a SCO filed by Verisign, but its two competitors for the string prevailed in virtually identical cases.
Would it be fair to reject one but not the others, without any kind of ICANN review or oversight?
Last week at the newdomains.org conference in Munich, I asked Atallah a question during a panel discussion about consistency in the new gTLD program, with reference to objections.
I was on stage and not taking notes, but my recollection is that he offered a not at all reluctant defense of subjectivity in panelists’ decision-making.
It was certainly my impression that ICANN is less troubled by inconsistent rulings than the applicants are.
In the .architect case, Atallah told the UIA that ICANN intends to implement objection rulings, writing:

ICANN will, of course, honor all panel decisions regarding objection determinations, unless directed to do otherwise by some action, for example, by virtue of Reconsideration Requests or other accountability mechanisms or action of the ICANN Board of Directors. To our knowledge, Spring Frostbite [Donuts] has not filed a Reconsideration Request or invoked an Independent Review Process with respect to this objection determination regarding the .ARCHITECT string.