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.
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 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.
Three new gTLD applications passed Initial Evaluation this week, including one of the two applications for .sex.
The approved .sex bid belongs to Internet Marketing Solutions, which is competing with .xxx operator ICM Registry.
The other applications passing IE this week are .leclerc, a French dot-brand, and .aquitaine, a French geographic region.
There are only 20 applications left without results, almost all of which — apart from a generic bid for .bar and Google’s controversial “dotless” .search — appear to be dot-brands.
ICANN has brought up its number of contracted new gTLDs to 32 with the signing of eight new Registry Agreements yesterday.
Six belong to Donuts:: .graphics, .technology, .reviews, .gallery, .guide and .construction.
Two IDN registries have also signed contracts: .我爱你 (Tycoon Treasure), which means “I love you” in Chinese, and .集团 (Eagle Horizon), which means “group” or “conglomerate” in Chinese.
The prioritization numbers for the 32 newly contracted application ranges from eight to 496. Almost all of the non-ASCII strings with contracts to date belong to Donuts.
ICANN signed four more new gTLD contracts with four different registries yesterday.
The lucky recipients of Registry Agreements are:
- .uno (Dot Latin LLC) — a general-purpose, open gTLD aimed primarily at Spanish and Italian speakers.
- .menu (Wedding TLD2, LLC) — also open, though the registry plans to run second-level portals corresponding to types of food (italian.menu, etc).
- .sexy (Uniregistry Corp) — signing a Registry Agreement with boring old ICANN doesn’t strike me as particularly sexy, but Uniregistry went ahead and did it anyway.
- .世界 (Stable Tone Ltd) — this Chinese string means “.world”. It will also be open and obviously targeted primarily at Chinese-speaking registrants.
The deals mean ICANN has now signed contracts covering 26 new gTLD applications. It’s slow going so far, but the pace is definitely picking up.
As of last week, DI PRO Application Tracker allows you to search for only gTLDs that have signed contracts, along with 23 other search criteria.