How the Governmental Advisory Committee handles its advice on new gTLD applications seems to be a big worry at the ICANN public meeting in Beijing this week.
During a session yesterday, new gTLD program vice president Christine Willett was peppered with questions about the approval process going forward, many of which related to the GAC.
There’s also a lot of gossiping about which applications the GAC is thinking about delivering the kiss of death to, and what its advice will mean to the overall program timetable.
DI is not attending the Beijing meeting in person, but here’s what I’ve learned from remote participation and talking to attendees:
Confusion over the GAC Advice standard
Judging by interactions during Willett’s session, there may be a little bit of confusion about whether GAC Advice needs to be “consensus” GAC Advice in order to halt a new gTLD application.
I think the confusion is mainly due to the way some people (Willett and myself included) use phrases such as “non-consensus GAC Advice” as shorthand for a particular paragraph of the Applicant Guidebook.
Here’s the way I understand it:
All GAC Advice — including Advice sent on issues completely unrelated to the new gTLD program — is consensus GAC Advice.
If the GAC sends written Advice to the ICANN board, it means the GAC has reached consensus to send that Advice, even if the Advice itself reflects a lack of consensus on the specifics.
Confusion in the community is arising now because the Applicant Guidebook also talks about three types of “GAC Advice on New gTLDs”, the first of which is:
The GAC advises ICANN that it is the consensus of the GAC that a particular application should not proceed. This will create a strong presumption for the ICANN Board that the application should not be approved.
That’s describing a situation where the GAC has reached a consensus that an application should be rejected. It’s going to sound the death knell for several applications, without doubt.
The second type of GAC Advice on New gTLDs in the Guidebook is:
The GAC advises ICANN that there are concerns about a particular application “dot-example.” The ICANN Board is expected to enter into dialogue with the GAC to understand the scope of concerns. The ICANN Board is also expected to provide a rationale for its decision.
The language was written by the GAC, using its consensus model, which is why it’s so badly worded.
What it means is that the GAC could not find consensus to kill off an application — some governments want it killed off, some don’t — but that the GAC as a whole reached consensus to tell ICANN that some governments do want it killed off.
So when people talk about “non-consensus” Advice, we’re referring to this second form of GAC Advice on New gTLDs, where the GAC could reached consensus to alert ICANN about “concerns” but could not reach consensus that the application should be taken outside and shot.
Which applications are going to get Advice?
The GAC stated last week that 20 applications had been put forward for specific review at the Beijing meeting.
From what I’ve been able to piece together from the GAC’s public hints, its Early Warnings, and sources in Beijing, I think I’ve identified many of these applications.
I’m pretty certain that DotConnectAfrica’s application for .africa is going to get killer Advice.
I’m not picking on DCA (disclosure: DCA accused me of being part of a racist conspiracy) but it is the only remaining applicant to comprehensively ignore ICANN’s rules on geographic names.
It’s also well-known that Amazon’s application for .amazon (and translations), and Patagonia Inc’s application for .patagonia, both of which were not captured by ICANN’s rules on geography, are unloved by Latin American governments.
The Montevideo Declaration, signed by government ministers from the continent last week, specifically condemns any new gTLDs related to Amazonia and Patagonia.
It’s difficult to see how the GAC could ignore the strength of this position, but it’s always possible that some members may have been lobbied into submission by applicants, therefore spoiling consensus.
Other geographic strings that ICANN’s rules did not identify as geographic may also face Advice.
It’s known that .persiangulf, for example, is racially/culturally divisive because the same body of water is also known as the Arabian Gulf by Arab states in the region.
The Japanese government’s Early Warning against .date (issued because there are two cities in Japan that, when translated into Latin characters, are called Date) is also believed to have been put forward for formal GAC Advice.
Outside of geographic names, I hear that .basketball and .rugby are also on the GAC’s shortlist.
These are interesting cases because the governments with the beef (Greece and the UK) are not concerned about the strings themselves. Rather, they want to make sure their preferred applicant wins.
Both gTLDs are contested, and each contention set has one applicant backed by the official world authority for the sport concerned.
If the GAC issues Advice on either, it’s putting itself in the position of picking winners and losers, which could make for some frenetic lobbying in future application rounds.
The application for .uno is believed to be under discussion in the GAC because it clashes with the acronym of an intergovernmental organization.
It also seems pretty certain that Demand Media’s applications for .navy, .army and .airforce are going to get Advice in one form or another. The US, I gather, is adamant that these bids should be rejected at all costs.
How GAC Advice affects the timetable
Willett said yesterday that ICANN expects to receive the GAC’s Advice this week, which should come as some relief to applicants given that the timing has always been a bit vague.
But it’s still not clear what form the Advice will take.
Sure, there’s bound to be some bits of Advice that call out specific applications for death-by-board, but there may also be Advice that addresses certain “categories” of application.
If that happens, and the GAC does not explicitly state which applications fall into which category, there’s the potential for mass confusion following the Beijing meeting.
I raised this specter last week, and it cropped up again during Willett’s session in Beijing yesterday.
What I forgot about last week, and what Willett was quizzed about yesterday, is that the Guidebook gives applicants with GAC Advice 21 days to respond to it before the ICANN board acts.
“I’m concerned that whereby the GAC Advice is such that it is all-encompassing and non-exhaustive that therefore all applicants must respond and all applicants are waiting another 21 days,” ARI Registry Services CEO Adrian Kinderis asked. “No applicant can proceed, because they’re all impacted.”
“If that hypothetical situation occurs, I think that’s possible,” Willett responded.
I other words, if the GAC delivers broad advice this week that does not name specific applications, it’s possible that every applicant would have 21 days to tell ICANN’s board why they’re not affected.
That would completely balls up ICANN’s plan to sign its first registry agreements on April 23.
Law enforcement agencies are not happy with the proposed 2013 Registrar Accreditation Agreement, saying it doesn’t go far enough to help them catch online bad guys.
Europol and the FBI told ICANN’s Governmental Advisory Committee yesterday that people need to have their full identities verified before they’re allowed to register domain names.
They added that new gTLDs shouldn’t be allowed to launch until a tougher RAA is agreed to and signed by registrars.
The draft 2013 RAA would force registrars to validate their customers’ email addresses or phone numbers after selling them a domain, but law enforcement thinks this is not enough.
“We need a bit more in this area,” Troels Oerting, head of Europol’s European Cybercrime Centre, told the GAC during a Sunday session. “We need a bit more to be verified in addition to the phone or email.”
“It’s very, very important that we are able to identify perpetrators able, to identify the originators, and it’s not enough that you just put in the email or phone,” he said.
He added that there should also be re-verification procedures and ongoing compliance monitoring from ICANN, and said that only registrars signing the 2013 RAA should be allowed to sell new gTLD domains.
Europol has sent a letter to ICANN (not yet published, it seems) outlining four areas it wants to see the RAA “improved”, Oerting said.
Given that many GAC members, including the US, seem to support this position, it’s yet another threat to ICANN’s new gTLD launch timetable, not to mention privacy and anonymous speech in general.
The law enforcement recommendations are not new, of course. They’ve been in play and GAC-endorsed for many years, but were watered down during ICANN’s RAA talks with registrars.
Potential security vulnerabilities recently disclosed by Verisign and PayPal are well in hand and not a reason to delay the launch of new gTLDs, according to the chair of ICANN’s security committee.
Patrick Falstrom, chair of the Security and Stability Advisory Committee, said today that the risk of disastrous clashes between new gTLDs and corporate security certificates has been taken care of.
Talking to the GNSO Council at the ICANN public meeting in Beijing, he gave a definitive “no” when asked directly if the SSAC would advise ICANN to delay the delegation of new gTLDs for security reasons.
Falstrom had given a presentation on “internal name certificates”, one of the security risks raised by Verisign in a paper last week.
These are the same kinds of digital certificates given out by Certificate Authorities for use in SSL transactions on the web, but to companies for their own internal network use instead.
The SSAC, judging by Falstrom’s presentation, had a bit of an ‘oh-shit’ moment late last year when a member raised the possibility of new gTLDs clashing with the domain names on these certificates.
Consider the scenario:
A company has a private namespace on its LAN called .corp, for example, where it stores all of its sensitive corporate data. It uses a digital certificate, issued by a reputable CA, to encrypt this data in transit.
But today we have more than a few applicants for .corp that would use it as a gTLD accessible to the whole internet.
Should .corp get delegated by ICANN — which of course is by no means assured — then there could be the risk of CAs issuing certificates for public domains that clash with private domains.
That might enable, for example, a hacker on a Starbucks wifi network to present his evil laptop as a secured, green-padlocked, corporate server to an unlucky road warrior sitting in the same cafe.
According to Falstrom, at least 157 CAs have issued certificates that clash with applied-for new gTLDs. The actual number is probably much higher.
This risk was outlined in Verisign’s controversial security report to ICANN, which recommended delay to the new gTLD program until security problems were resolved, two weeks ago.
But Falstrom told the GNSO Council today that recent secretive work by the SSAC, along with ICANN security staff and the CA/Browser Forum, a certificate industry authority, has mitigated this risk to the point that delay is not needed.
Falstrom said that after the SSAC realized that there was a potential vulnerability, it got it touch with the CA/Browser Forum to share its concerns. But as it turned out, the Forum was already on the case.
The Forum decided in February, a couple of weeks after an SSAC briefing, that member CAs should stop issuing internal name certificates that clash with new gTLDs within 30 days of ICANN signing a registry contract for that gTLD.
It has also decided to revoke any already-issued internal domain certificate that clashes with a new gTLD within 120 days of contract signing.
This means that the vulnerability window will be much shorter, should the vulnerability start getting exploited in wild.
But only if all CAs conform to the CA/Browser Forum’s guidelines.
Former ICANN chief strategy officer and new gTLDs head honcho Kurt Pritz is doing a spot of industry work, following the expiration of his post-resignation consulting gig with ICANN.
Pritz, we understand, has developed consulting relationships with new gTLD portfolio applicant Donuts and consulting firm Architelos while he looks for a more permanent position.
As you may recall, he quit ICANN last November after disclosing a personal conflict of interest.
While there are no rules preventing ICANN staff going into the domain industry, Pritz’s is prohibited from sharing confidential information he learned while at ICANN, we’re told.
Given his background, we understand he’ll be focusing mainly on policy-related work at both companies.
Three already-live TLDs are going to use the Trademark Clearinghouse to handle sunrise periods, possibly before the first new gTLDs launch.
BRS Media is set to use the TMCH, albeit indirectly, in its launch of third-level domains under .radio.am and .radio.fm, which it plans to launch soon as a budget alternative to .am and .fm.
The company has hired TM.Biz, the trademark validation firm affiliated with EnCirca, to handle its sunrise, and TM.biz says it will allow brand owners to leverage Clearinghouse records.
Trademark owners will be able to submit raw trademarks for validation as in previous sunrises, but TM.Biz will also allow them to submit Signed Mark Data (SMD) files, if they have them, instead.
Encrypted SMD files are created by the TMCH after validation, so the trademarks and the strings they represent are pre-validated.
There’ll presumably be some cost benefit of using SMD files, but pricing has not yet been disclosed.
Separately, Employ Media said today that it’s getting ready to enter the final stage of its .jobs liberalization, opening up the gTLD to essentially any string and essentially any registrant.
The company will also use the TMCH for its sunrise period, according to an ICANN press release, though the full details and timing have not yet been announced.
Unusually, .jobs is a gTLD that hasn’t already had a sunrise — its original business model only allowed vetted company-name registrations.
The TMCH is already accepting submissions from trademark owners, but it’s not yet integrated with registries and registrars.