European Commission vice president Neelie Kroes wants “your ideas on how the Internet should be governed and what Europe’s role should be.”
In a survey launched last week, Kroes, who has special responsibility for the “digital agenda” in Europe, criticized ICANN’s “multi-stakeholder” process.
She solicited suggestions on how governments should be treated within ICANN, and asked “How can a move from unilateral to multilateral accountability be realised?”
Kroes said on her blog (link in original):
we also must have a clearer view of what we mean when we speak of “multi-stakeholder processes”. I worry that without a clear definition, everyone will claim that their decision processes are inclusive and transparent, when in practice they are not – as was shown recently, when the Governmental Advisory Committee of ICANN pressed on regardless – in spite of the EU’s legitimate concerns on new domain names.
Let’s parse this.
On the one hand, Kroes is stating that ICANN’s process is not “inclusive and transparent”.
On the other, she’s linking to her own demands for special privileges for the European Commission in the debate over whether wine producers need special protections in the new gTLDs .wine and .vin.
I reported on Kroes letter a month ago.
As the letter and the public record makes plain, the GAC had originally asked ICANN for more time in order to consider whether the .wine protections were warranted.
In the end, the GAC was unable to reach a consensus on the matter and advised ICANN accordingly.
With no GAC consensus, ICANN has no mandate to act.
But Kroes wants ICANN to delay the .wine and .vin applications anyway, based on little more than the European Commission’s unilateral demands.
Is her definition of a “multi-stakeholder” process one in which individual governments get to override the consensus of dozens of governments? It certainly looks that way.
And it wouldn’t be the first time Kroes has tried to usurp the multi-stakeholder process in order to get what she wants.
Back in June 2011, she called for ICANN to be reformed because she didn’t like the fact that ICANN did not accept all the GAC’s advice when it approved the new gTLD program.
A month earlier, she privately wrote to the US Department of Commerce — which controls the DNS root server — to ask that it refuse to delegate the recently approved .xxx gTLD.
That would have been an unprecedented and worrying move by Commerce, and naturally it declined.
But the fact that Kroes even asked makes me wonder how serious she is about “multistakeholderism”.
It’s a newish term, poorly defined, but reason dictates that it means you can’t always get what you want.
Amazon has lost its appeal of a ruling that says its applied-for new gTLD .通販 is “confusingly similar” to .shop, with ICANN ruling that its Reconsideration mechanism is not an appeals process.
The e-commerce giant lost a String Confusion Objection filed by .shop applicant Commercial Connect in August, with panelist Robert Nau ruling that the two strings were too confusing to co-exist.
That’s despite one of the strings being written in Latin script and the other Japanese. The ruling was based on the similarity of meaning: 通販 means “online shopping”.
Amazon immediately filed a Reconsideration Request with ICANN.
Days earlier, Akram Atallah, president of ICANN’s Generic Domains Division, had described this process as one of the “avenues for asking for reconsidering the decision”.
Atallah was less clear on whether Reconsideration was applicable to decisions made by third-party panels — the new gTLD program’s Applicant Guidebook contains conflicting guidance.
ICANN’s Board Governance Committee, which handles Reconsideration Requests, has now answered that question: you can ask for Reconsideration of a new gTLD objection ruling, but you’ll only win if you can prove that there was a process violation by the panel.
In its decision, the BGC stated:
Although Commercial Connect’s Objection was determined by a third-party DRSP, ICANN has determined that the Reconsideration process can properly be invoked for challenges of the third-party DRSP’s decisions where it can be stated that either the DRSP failed to follow the established policies or processes in reaching the decision, or that ICANN staff failed to follow its policies or processes in accepting that decision.
That’s moderately good news as a precedent for applicants wronged by objections, in theory. In practice, it’s likely to be of little use, and it was of no use to Amazon. The BGC said:
In the context of the New gTLD Program, the Reconsideration process does not call for the BGC to perform a substantive review of DRSP Panel decisions; Reconsideration is for the consideration of process- or policy-related complaints.
As there is no indication that either the ICDR or the Panel violated any policy or process in accepting and sustaining Commercial Connect’s Objection, this Request should not proceed. If Amazon thinks that it has somehow been treated unfairly in the process, and the Board (through the NGPC) adopts this Recommendation, Amazon is free to ask the Ombudsman to review this matter.
While the BGC declined to revisit the substance of the SCO, it did decide that it’s just fine for a panelist to focus purely on the meaning of the allegedly confusing strings, even if they’re wholly visually dissimilar.
The Panel’s focus on the meanings of the strings is consistent with the standard for evaluating string confusion objections. A likelihood of confusion can be established with any type of similarity, including similarity of meaning.
In other words, Nau’s over-cautious decision stands: .通販 and .shop will have to enter the same contention set.
That’s not great news for Amazon, which will probably have to pay Commercial Connect to go away at auction, but it’s also bad news for increasingly unhinged Commercial Connect, whose already slim chances of winning .shop are now even thinner.
Commercial Connect had also filed a Reconsideration Request around the same time as Amazon’s, using the .通販 precedent to challenge a much more sensible SCO decision, which ruled that .shop is not confusingly similar to .购物, Top Level Domain Holdings’ application for “.shopping” in Chinese.
The BGC ruled that the company had failed to adequately state a case for Reconsideration, meaning that this objection ruling also stands.
The big takeaway appears to be that the BGC reckons it’s okay for objection panels to deliver decisions that directly conflict with one another.
This raises, again, questions that have yet to be answered, such as: how do you form contention sets when one string has been ruled confusingly similar and also not confusingly similar to another?
The International Telecommunication Union has warned ICANN that numeric .tel domain names, due to be released by Telnic tomorrow, “may confuse customers or cause undue conflicts”.
In a letter to ICANN, Malcolm Johnson, director of the ITU’s Telecommunication Standardization Bureau, said that there’s a risk that numbers-only .tel name could be confused with the E.164 numbering plan.
Johnson asked ICANN to explain how these numbers will be allocated and used:
ITU must express its concern about TELNIC’s recent announcement launching an “all numeric .tel domains” service from 15 October 2013. This raises a number of policy, legal, and practical implications on the potential usage of all-digit strings, not only under .TEL domain, but also under any future telephony-related new gTLDs
We are seeking this clarification as the digit strings appear similar to telephone numbers and could be used in a manner similar to telephone numbers, which may confuse customers or cause undue conflicts arising from their use.
E.164 is the standard for phone numbers worldwide. The ITU has been angsty about the potential for clashes ever since .tel was first proposed back in 2000.
Indeed, Telnic promised when it applied in 2003 not to allow numbers in .tel, precisely in order to calm these fears.
But when it asked for this self-imposed ban to be lifted in 2010, the ITU didn’t have anything to say (at least, it did not respond to ICANN’s public comment period).
Read Johnson’s letter here (pdf).
The eighteenth installment of dotShabaka Registry’s journal, charting its progress towards becoming one of the first new gTLDs to go live, written by general manager Yasmin Omer.
Friday 11 October 2013
We are not sure if anyone else has noticed, but there are differences between the published documentation for Rights Protection Mechanisms, Trademark Clearinghouse and the transition to delegation process. This has created confusion.
To seek clarification, we sent the following questions to ICANN for a response:
IBM confirmed in an email on the 4th of October that شبكة. has passed TMDB testing. The message was:
“…confirm that all tests are ok and have asked to forward your certification request to ICANN.”
Based on this correspondence, it is our understanding that we are at the “Email ICANN CSC – Confirm Tests Completed” stage of the process as outlined in IBM’s TMCH swim lane diagram (pdf).
The next action in the process is ICANN’s – “CSC Sends Request to Registry Services for Actual Sunrise and Claims Start/End Dates”. Our understanding is that the reference to Registry Services is the Registry Services department of ICANN. The CSC will not be able to complete the next action “CSC Updates Existing Line in .csv File with Actual S&C Start/End Dates” until the Registry Operator submits its notice to ICANN (after it is delegated).
Can you please confirm there is no formal step where ICANN (or IBM) provides the Registry Operator with a “pass” certificate or other formal confirmation.
Section 2.1.1 of the RPM Requirements Document (pdf) states that the Registry Operator must provide TLD Startup Information to ICANN and the TMCH Sunrise and Claims Operator. However, section 2.1.2 states that such information must be submitted through the customer service portal.
Can you confirm that submission of the TLD Startup Information through the portal serves to satisfy the requirement to provide TLD Startup Information to ICANN and the TMCH Sunrise and Claims Operator as specified in Section 2.1.1?
Section 22.214.171.124 states that the TLD Startup Information needs to include confirmation that the registry operator has completed testing.
Does this confirmation need to be in a specific form?
Will an email from IBM suffice? If so, who must the email be from i.e. project manager and what must it state specifically?
Section 126.96.36.199 states that the TLD Startup Information needs to include confirmation that the TMCH Sunrise and Claims Operator has accepted the start and end dates prior to the Registry Operator providing the TLD Startup Information. This step of the process is not described in the Process Document.
Does this confirmation need to be in a specific form?
Does IBM have a SLA with ICANN to ensure such confirmation is provided within a specific timeframe to ensure that a Registry Operator’s ability to submit its TLD Startup Information is not compromised by delays?
For clarity can you incorporate the requirements of section 2.1 of the RPM Requirements Document into the TMDB Registration and Access to Production Platform Process swim lane diagram?
Please outline the process for our back-end registry services provider to gain access to the TMCH production environment.
If this process involves IBM or other external parties please also provide service level expectations so we can include allowance in scheduling of Sunrise and other launch periods
We will let you know when we get a response.
Read previous and future diary entries here.
DotGreen, the first public and easily most visible applicant for the new gTLD .green, has withdrawn its application, saying it has become “impossible” to continue.
In a statement sent to DI tonight, founder and CEO Annalisa Roger said:
While DotGreen supported the New gTLD program, we believe we exhausted all options within the framework of the New gTLD applicant guidebook and the multi-stakeholder model for procuring .green management. DotGreen remains locked in contention facing an auction among three registry competitors from the Internet industry. Unfortunately it is impossible for DotGreen to proceed within these circumstances.
Today we withdrew DotGreen Community, Inc.’s application for the .green TLD.
DotGreen was founded in 2007 and had built up a small following of supporting environmental organizations. A charitable organization, the plan was to use the proceeds from the registry to fund worthy projects.
A prominent applicant from well before the ICANN application window opened, it held regular eco-themed events during ICANN meetings and even recruited its CFO/COO, Tim Switzer, from its back-end provider, Neustar.
(Switzer is chair of the New gTLD Applicants Group, NTAG, but is expected to resign as a result of the withdrawal.)
But it’s facing competition for .green from portfolio applicants Demand Media, Afilias, and Top Level Domain Holdings.
“It is tough for a single-string applicant,” Roger said. “An auction, sorry, it’s not the appropriate scenario for the .green TLD for several reasons. It really the undermines the authenticity and the faith that the community has put in us and the multi-stakeholder model.”
There’s no way the company could win at auction against three big portfolio applicants, she said.
Despite the company name, DotGreen Community’s application was not a “Community” application under ICANN rules and the only way out of contention was going to be private settlement or auction.
It also faced the uncertainty of Governmental Advisory Committee advice, which had classified the string as requiring extra safeguards for “consumer protection” purposes, causing indefinite delays.
It seems the final decision was financial — the cost of delays and an auction too much for the start-up to bear. It’s a pity really — there was some genuine enthusiasm for the cause behind this bid.
The .green gTLD will now go to which one of the remaining three applicants stumps up the most cash at auction.