Nine more new gTLD contracts signed

ICANN signed nine more new gTLD Registry Agreements yesterday.
The contracts cover .kiwi, .futbol, .kitchen, .directory, .diamonds, .tips, .today, .enterprises, and .photography.
All but .kiwi, which will be run by Dot Kiwi Ltd, were Donuts’ applications.
ICANN now has Registry Agreements with registries to manage 45 new gTLDs.

One IE pass, one fail this week

ICANN is down to 18 new gTLD applications in Initial Evaluation now, after one pass and one failure this week.
The pass is the dot-brand .lplfinancial, applied for by LPL Financial, a US-based broker. The company already owns the arguably better domain lpl.com.
The failure, which is eligible for Extended Evaluation, is Top Level Domain Holdings’ geographic bid for .roma, a city TLD for Rome, Italy.
The application failed on geographic grounds, meaning TLDH seems to have failed to provide sufficient evidence of government support or non-objection.
It’s TLDH’s final IE result and the only one of its 70 applications to fail to achieve a passing score.

New gTLD plans November 30 sunrise

I-Registry, which signed an ICANN Registry Agreement for the new gTLD .onl this week, plans to launch its Sunrise period on November 30, according to the company.
It’s the first date for a new gTLD Sunrise period I’ve come across to date, though it is of course an informal target rather than a firm commitment.
ICANN has signed contracts covering a few dozen gTLDs but as yet none have been delegated. As anyone who has been following dotShabaka’s diary on DI will know, there’s still a lot of uncertainty
.onl, which is short for “online”, is expected to be an open gTLD with no registration restrictions.
I-Registry plans to donate a portion of its profits to charity.

Google signs first new gTLD contract

Google has signed its first Registry Agreement with ICANN, covering the new gTLD .みんな.
The string means “everyone” in Japanese. It had priority number 34.
Google proposes to use it as an open TLD, available for anyone to register names in.
Signed by Google subsidiary Charleston Road Registry, it’s the 34th new gTLD contract ICANN has executed.
Google has 96 new gTLD applications remaining. One of them, for .search, is still Initial Evaluation.

ICANN looking into string confusion confusion

ICANN is looking at “consistency issues” in new gTLD String Confusion Objections, program manager Christine Willett said in an ICANN interview published last night.
The nature of the probe is not clear, but ICANN does appear to be working with the dispute resolution provider, the International Centre For Dispute Resolution, on the issue.
In the interview, Willett said:

Staff is working diligently with dispute resolution service providers to ensure that all procedures have been followed and to look at the expert determinations — we’re looking at these consistency issues.

The SCO has come in for tonnes of criticism due to the conflicting and downright ludicrous decisions made by panelists.
I would hope that ICANN is looking beyond just whether “all procedures have been followed”, given that the root cause of the consistency problems appears to be the lack of guidance for panelists in the policy itself.
Also in the interview, Willett said that she expects the first new gTLDs to be “in production” before the end of the year, and guessed that the second round of applications “is a couple of years down the road”.
Watch it here:

.CLUB offers solution to name collision risks

.CLUB Domains has come up with a simple workaround for its applied-for .club gTLD being categorized as risky by ICANN.
The company wants to reserve the top 50 .club domains that currently see DNS root traffic, so that if and when .club goes live the impact on organizations that use .club internally will be greatly reduced.
It’s not a wholly original idea, but .CLUB seems to be unique at the moment in that it actually knows what those 50 strings are, having commissioned an Interisle Consulting report of its proposed gTLD.
You’ll recall that Interisle is the company that ICANN commissioned to quantify the name collisions problem in the first place.
Its report is what ICANN used to categorize all applied-for gTLD strings into low, high and “uncalculated” risks, putting .club into the uncalculated category, delaying it by months.
(Interisle was at pains to point out in its report for .CLUB that it is not making any recommendations, interpreting the data, or advocating any solutions. Still, nice work if you can get it.)
By reserving the top 50 clashes — presumably in such a way that they will continue to return error responses after .club is delegated — .CLUB says .club would slip into ICANN’s definition of a low-risk string.
In a letter to ICANN (pdf) sent today, .CLUB chief technology officer Dirk Bhagat wrote:

blocking the 50 SLD strings from registration would prevent 52,647 out of the 89,533 queries from a potential collision (58.88%). After blocking the top 50 strings as SLD strings, only 36,886 (41.12%) queries remain, which is 12,114 fewer invalid queries at the root than .engineering, which ICANN classified as a low risk gTLD.

He adds that a further chunk of remaining SLDs are random strings that appear to have been created by Google’s Chrome browser and, many say, pose no risk of name collisions, reducing the risk further.
It’s hard to argue with the logic there, other than to say that ICANN’s categorization system itself has already come in for heavy criticism for drawing unjustified, arbitrary lines.
The list of domains .CLUB proposes to block is pretty interesting, including some strings that appear to be trademarks, the names of likely .club registrants, or potentially premium names.

ICANN smacks Cheapies with the ban hammer

ICANN for only the second time has suspended an accredited registrar’s ability to sell domain names.
Cheapies.com, which has roughly 12,000 gTLD domain names under management, will not be able to create new domains or accept inbound transfers until January 2, 2014, according to ICANN.
The 90-day suspension of its accreditation, longer by two months than the 30 days Alantron received last year, comes because it’s the third time this year Cheapies has been sent an ICANN breach notice.
The latest breach concerns the domain ebookvortex.com. Apparently Cheapies did not provide the registrant with the required authorization information when he initiated a transfer request.
In January, the company received breach notices related to its records-keeping and another instance of failing to abide by ICANN’s inter-registrar transfers policy.
It’s also being spanked for consistently ignoring or stonewalling ICANN’s attempts to resolve the situation.
Cheapies has the opportunity to rectify its problems to avoid losing its accreditation entirely. In the meantime, it also has to display the following notice “prominently” on its web site:

No new registrations or inbound transfers will be accepted from 4 October 2013 through 2 January 2014.

There’s a clear takeaway for fly-by-night registrars here: ignore ICANN Compliance at your peril.

Europe continues to object to .wine gTLD

The European Union is continuing to fight the proposed .wine and .vin gTLDs, even after ICANN’s Governmental Advisory Committee formally withdrew its advice on the applications.
Neelie Kroes, vice president of the European Commission, wrote to ICANN on Thursday to say that its “firm position” is:

under no circumstance can we agree having .wine and .vin and on the internet, without sufficient safeguards which efficiently protect the rights and interest of both GI [Geographic Indicator] right holders and consumers and wine and wine products

The EC believes that .wine and .vin should have special second-level protections for wine GIs — geographic indicators such as Champagne, named after the region in which it is produced.
It’s a view that has been put forward by many associations of wine producers in the EU and US for over a year. ICANN is also in receipt of letters disagreeing with the GAC from other wine producers.
The law internationally, and even in the EU, appears to be patchy on whether and how GIs are protected. They don’t generally enjoy the same uniformity of protection as trademarks.
The GAC considered the two strings in April at the Beijing meeting but failed to come to a consensus.
It wound up asking ICANN for more time and, after failing to reach agreement again in Durban this July, finally concluded last week that it was unable to find a consensus on advice.
That potentially laid the path clear for the four applications for the two strings to continue to contention resolution, contracting and eventual delegation.
However, the GAC’s all-clear arrived too late for the ICANN New gTLD Program Committee to formally consider it at its meeting last week.
According to the Kroes letter, the European Commission’s view is:

there has not been any consensus decision overruling the advice given in Beijing. We are therefore of the firm opinion that the advice provided at the GAC April meeting stands as long as there is no new consensus on the matter.

The Beijing advice, which was explicitly intended to give the GAC more time to deliberate, said that ICANN should not proceed beyond Initial Evaluation with .wine or .vin.
Kroes’ logic may or may not be consistent with the letter of the Beijing communique, but certainly not its spirit. That’s becoming an increasingly common problem with GAC advice.
It seems unlikely, however, that ICANN would put the views of one single government ahead of what the GAC as a whole has submitted as formal advice.
Her letter does not seem to have been published by ICANN yet, but you can read it in PDF format here.

Hundreds of new gTLD applicants still in GAC limbo

A little over five months after the Governmental Advisory Committee issued its controversial Beijing communique, demanding strict controls over hundreds of new gTLDs, ICANN has still not taken any action.
ICANN’s New gTLD Program Committee “accepted” a bunch of the GAC’s advice on new gTLDs during its meeting last week, but yet again punted the most crucial issue — how to handle the so-called “Category 1” strings.
In a resolution last Tuesday, published on Friday, the NGPC addressed 21 pieces of GAC advice from the July Durban meeting but took no action on the April Beijing advice.
One application was killed off as a result — Better Living Management’s bid for .thai — on geographic grounds.
Applications for .spa, .yun, .广州 (.guangzhou), and .深圳 (.shenzhen), which are all geographic strings, have been put on hold “until the agreements between the relevant parties are reached”.
Amazon’s applications for its brand in Latin and other scripts are also on hold again pending ICANN’s review of its lengthy response to the GAC’s decision to object to them in Durban.
Two applications — .date and .persiangulf — which had raised geographic concerns in Beijing have been given leave to proceed after the GAC decided not to object in Durban.
Applications for .wine, .vin, .ram and .indians appear to be safe, but it’s not 100% clear based on the NGPC’s resolution.
Category 1 strings
“Category 1” strings were those strings that the GAC deemed applicable to “Consumer Protection, Sensitive Strings, and Regulated Markets”.
The GAC wants these gTLDs, if approved, to be subject to oversight by regulatory or self-regulatory bodies and to implement strict security controls.
The Category 1 advice has been criticized by many, including members of the NGPC, for being too vague to implement and for unfairly moving the goalposts on applicants at the last minute.
In Durban, the NGPC had indicated that it was very unhappy with the Category 1 advice.
Last week, it chose to essentially ignore the Beijing communique in which the Category 1 advice was delivered, and instead “accept” the Category 1 advice from Durban, which simply stated:

The GAC will continue the dialogue with the NGPC on this issue.

The NGPC in response stated in an annex to its resolution:

The NGPC accepts this advice. The NGPC looks forward to continuing the dialogue with the GAC on this issue.

So the 500-odd applications captured by Category 1 are still in limbo, unable to sign registry contracts with ICANN, pending the outcome of these GAC-NGPC negotiations.
On the upside, it looks like ICANN is keen to get the issue resolved before ICANN’s next public meeting, which takes place in Buenos Aires in November. ICANN said:

The NGPC and staff are working with the GAC to identify a time and place for further dialogue on these items.

Community support
The NGPC also addressed the GAC’s demands relating to community support for applications. In doing so, it again deployed its tactic of “accepting” the letter of the GAC’s advice whilst plainly rejecting it in spirit.
The GAC had said in Durban:

the GAC advises the ICANN Board to consider to take better account of community views, and improve outcomes for communities, within the existing framework, independent of whether those communities have utilized ICANN’s formal community processes to date.

The GAC was basically worried about the new gTLD program not giving sufficient weight to informal objections from organizations that could be affected by applied-for strings.
The NGPC responded:

The NGPC accepts this advice. The NGPC will consider taking better account of community views and improving outcomes for communities, within the existing framework, independent of whether those communities have utilized ICANN’s formal community processes to date. The NGPC notes that in general it may not be possible to improve any outcomes for communities beyond what may result from the utilization of the AGB’s community processes while at the same time remaining within the existing framework.

In other words, due to the inclusion of the phrase “within the existing framework”, ICANN can do absolutely nothing else to address the GAC’s concerns and can still say it “accepted” the advice.
The NGPC had previously used the same tactic to avoid dealing with the GAC’s Beijing advice on giving “communities” the ability to kill off applications without going through the proper channels.

Verisign targets bank claims in name collisions fight

Verisign has rubbished the Commonwealth Bank of Australia’s claim that its dot-brand gTLD, .cba, is safe.
In a lengthy letter to ICANN today, Verisign senior vice president Pat Kane said that, contrary to CBA’s claims, the bank is only responsible for about 6% of the traffic .cba sees at the root.
It’s the latest volley in the ongoing fight about the security risks of name collisions — the scenario where an applied-for gTLD string is already in broad use on internal networks.
CBA’s application for .cba has been categorized as “uncalculated risk” by ICANN, meaning it faces more reviews and three to six months of delay while its risk profile is assessed.
But in a letter to ICANN last month, CBA said “the cause of the name collision is primarily from CBA internal systems” and “it is within the CBA realm of control to detect and remediate said systems”.
The bank was basically claiming that its own computers use DNS requests for .cba already, and that leakage of those requests onto the internet was responsible for its relatively high risk profile.
At the time we doubted that CBA had access to the data needed to draw this conclusion and Verisign said today that a new study of its own “shows without a doubt that CBA’s initial conclusions are incorrect”.
Since the publication of Interisle Consulting’s independent review into root server error traffic — which led to all applied-for strings being split into risk categories — Verisign has evidently been carrying out its own study.
While Interisle used data collected from almost all of the DNS root servers, Verisign’s seven-week study only looked at data gathered from the A-root and J-root, which it manages.
According to Verisign, .cba gets roughly 10,000 root server queries per day — 504,000 in total over the study window — and hardly any of them come from the bank itself.
Most appear to be from residential apartment complexes in Chiba, Japan, where network admins seem to have borrowed the local airport code — also CBA — to address local devices.
About 80% of the requests seen come from devices using DNS Service Discovery services such as Bonjour, Verisign said.
Bonjour is an Apple-created technology that allows computers to use DNS to automatically discover other LAN-connected devices such as printers and cameras, making home networking a bit simpler.
Another source of the .cba traffic is McAfee’s antivirus software, made by Intel, which Verisign said uses DNS to check whether code is virus-free before executing it.
While error traffic for .cba was seen from 170 countries, Verisign said that Japan — notable for not being Australia — was the biggest source, with almost 400,000 queries (79% of the total). It said:

Our measurement study reveals evidence of a substantial Internet-connected infrastructure in Japan that lies beneath the surface of the public-facing internet, which appears to rely on the non-resolution of the string .CBA.
This infrastructure appear hierarchical and seems to include municipal and private administrative and service networks associated with electronic resource management for office and residential building facilities, as well as consumer devices.

One apartment block in Chiba is is responsible for almost 5% of the daily .cba queries — about 500 per day on average — according to Verisign’s letter, though there were 63 notable sources in total.
ICANN’s proposal for reducing the risk of these name collisions causing problems would require CBA, as the registry, to hunt down and warn organizations of .cba’s impending delegation.
Verisign reiterates the point made by RIPE NCC last month: this would be quite difficult to carry out.
But it does seem that Verisign has done a pretty good job tracking down the organizations that would be affected by .cba being delegated.
The question that Verisign’s letter and presentation does not address is: what would happen to these networks if .cba was delegated?
If .cba is delegated, what will McAfee’s antivirus software do? Will it crash the user’s computer? Will it allow unsafe code to run? Will it cause false positives, blocking users from legitimate content?
Or will it simply fail gracefully, causing no security problems whatsoever?
Likewise, what happens when Bonjour expects .cba to not exist and it suddenly does? Do Apple computers start leaking data about the devices on their local network to unintended third parties?
Or does it, again, cause no security problems whatsoever?
Without satisfactory answers to those questions, maybe name collisions could be introduced by ICANN with little to no effect, meaning the “risk” isn’t really a risk at all.
Answering those questions will of course take time, which means delay, which is not something most applicants want to hear right now.
Verisign’s study targeted CBA because CBA singled itself out by claiming to be responsible for the .cba error traffic, not because CBA is a client of rival registry Afilias.
The bank can probably thank Verisign for its study, which may turn out to be quite handy.
Still, it would be interesting to see Verisign conduct a similar study on, say, .windows (Microsoft), .cloud (Symantec) or .bank (Financial Services Roundtable), which are among the 35 gTLDs with “uncalculated” risk profiles that Verisign promised to provide back-end registry services for before it decided that new gTLDs were dangerous.
You can read Verisign’s letter and presentation here. I’ve rotated the PDF to make the presentation more readable here.