New ccTLDs may have to block name collisions

ICANN is thinking about expanding its controversial policy on name collisions from new gTLDs to new ccTLDs.
The country code Names Supporting Organization has been put on notice (pdf) that ICANN’s board of directors plans to pass a resolution on the matter shortly.
The resolution would call on the ccNSO to “undertake a study to understand the implications of name collisions associated with the launch of new ccTLDs” including internationalized domain name ccTLDs, and would “recommend” that ccTLD managers implement the same risk mitigation plan as new gTLDs.
Because ICANN does not contract with ccTLDs, a recommendation and polite pressure is about as far as it can go.
Name collisions are domains in currently undelegated TLDs that nevertheless receive DNS root traffic. In some cases, that may be because the TLDs are in use on internal networks, raising the potential of data leakage or breakages if the TLDs are then delegated.
ICANN contracts require new gTLDs to block such names or wildcard their zones for 90 days after launch.
Some new gTLD registry executives have mockingly pointed to the name collisions issue whenever a new ccTLD has been delegated over the last year or so, asking why, if collisions are so important, the mitigation plan does not apply to ccTLDs.
If the intent was to persuade ICANN that the collisions management framework was unnecessary, the opposite result has been achieved.

EU IDN not banned after all

The European Union request for the Greek-script ccTLD .ευ has not been thrown out, according to ICANN.
Last week DI reported that .ευ was the only one of three IDN ccTLD requests — the other two being Bulgaria’s .бг and Greece’s .ελ — to fail a test for confusing similarity on appeal.
.ευ was found to be confusingly similar to .EY and .EU, but only when in upper case.
The similarity panel’s decision would mean, I reported, that .бг and .ελ would be delegated but .ευ would not, under ICANN rules.
I wondered aloud what the Governmental Advisory Committee would think about that, given that it had lobbied for the creation of the appeals process in order to get an earlier rejection of .ευ overturned.
Shortly after publishing the article, ICANN reached out to say I was wrong and ask for a correction.
“We (ICANN) have not rejected the .ευ application,” a spokesperson said.
“Due to the unprecedented nature of the split results, the issue needs to be discussed at the senior management and Board level before a final decision is made,” he said.
The “split results” refers to the fact that there was found to be no confusing similarity with .ευ in lower case.
However, the ICANN rule I referred to says (which my emphasis):

The rule is that if the appearance of the selected string, in upper or lower case, in common fonts in small sizes at typical screen resolutions, is sufficiently close to one or more other strings, it is probable that a reasonable Internet user who is unfamiliar with the script perceives the strings to be the same or confuses one for the other.

That’s adapted almost verbatim from the original recommendations of the ccNSO. The only addition ICANN made was to add the clearly important clause “in upper or lower case” to the text.
It seemed pretty straightforward to me — confusing similarity exists regardless of case.
I pointed this out to ICANN last Wednesday and asked where I could find the rule that said the ICANN board or staff get to review a “split results” finding but have yet to receive a reply.

Bulgaria and Greece win IDN ccTLDs on appeal

Campaigns in Bulgaria and Greece to get ICANN to un-reject their Cyrillic and Greek-script ccTLD requests have proven successful.
The first decisions handed down by ICANN’s new Extended Process Similarity Review Panel this week said Bulgaria’s .бг and Greece’s .ελ are not “confusingly similar” to other ccTLDs after all.
However, a third appeal by the European Union over the Greek .ευ was rejected on the grounds that the string is too confusingly similar to .EV and .EY when in upper case.
Confusing strings should not be delegated, under ICANN rules, due to the risk of exacerbating the prevalence of security risks such as phishing attacks.
Bulgaria’s initial request for .бг was turned down in 2010 after a panel found it looks too similar to Brazil’s existing ccTLD, .br.
Greece’s bid for .ελ had been blocked for looking too much like .EA, a non-existent ccTLD that could be delegated to a new country in future.
While the initial panel’s process was pretty opaque, the newly published “extended” reviews appear to have employed a fairly scientific methodology to determine similarity.
Twenty American undergraduate student volunteers were shown pairs of strings briefly on screens designed to simulate web browsing. They then had to pick out which one they’d seen.
The volunteers were also shown pairs of similar-looking Latin-script ccTLDs that already exist, in order to establish a baseline for what should be considered an acceptable level of confusability.
The Greek and Bulgarian strings were both found to be less confusing than existing pairs of Latin-script ccTLDs and were therefore given the thumbs-up. The EU string flunked in upper case.
Under ICANN’s rules, it appears that .бг and .ελ can now proceed to delegation, while .ευ has been forever rejected.
The three reports can be downloaded here.
It will be interesting to see how the ICANN Governmental Advisory Committee will react to this.
It was pressure from the GAC — driven by the European Commission and Greece — back in 2012 that forced ICANN into creating the appeals process.
At ICANN’s meeting in Prague that year, the GAC said:

The GAC is of the view that decisions may have erred on the too-conservative side, in effect applying a more stringent test of confusability between Latin and non-Latin scripts than when undertaking a side by side comparison of Latin strings.

Now the EU seems to have been told that it still can’t have its requested ccTLD, and the standard applied was exactly the same standard as applies to Latin ccTLDs.
Will the GAC accept this determination, or stomp its feet?

Iraq to get IDN ccTLD

Iraq was this week granted the right to use a new Arabic-script country-code top-level domain.
ICANN said the war-torn nation’s request for عراق., which is Arabic for “Iraq”, has passed the String Evaluation phase of the IDN ccTLD Fast Track program.
Like .iq, the registry will be the government’s Communications and Media Commission.
Once delegated, the Punycode inserted into the root will be .xn--mgbtx2b.
ICANN said Iraq is the 33rd nation to have an IDN ccTLD request approved. There are currently 26 IDN ccTLDs in the root. Most of them aren’t doing very well.

Malaysia to get new Arabic ccTLD

ICANN’s board of directors is set to approve مليسيا., the Arabic name for Malaysia, at a meeting next week.
Delegation of the internationalized country-code top-level domain is listed on the board’s consent agenda for next week’s meeting, meaning it’s likely to be a case of simply rubber-stamping the decision.
It will be the 40th IDN ccTLD to enter the root, not including test zones, under ICANN’s Fast Track program.
With the notable exception of Russia’s .РФ, IDN ccTLDs have been commercially underwhelming.
The redelegation of Rwanda’s .rw, currently delegated to NIC Congo/Interpoint SARL, is also on ICANN’s board consent agenda for the August 28 meeting.
There are no issues related to the new gTLD program on the agenda.