German geo .ruhr enters the root

Verisign today delegated the new gTLD .ruhr to the DNS root zone, making it the 35th new gTLD to go live.
It’s a geographic string, meant for residents of the north-west German region of Ruhr, operated by Regiodot.
nic.ruhr is already resolving.
Regiodot is already taking pre-registrations via approximately 10 signed-up registrars, which all appear to operate in German-speaking countries.
The Ruhr (in German, it’s short for Ruhrgebiet) has over eight million inhabitants, according to Wikipedia, making the potential market for .ruhr larger than many European ccTLDs.

Win free tickets to NamesCon Las Vegas (even if you’ve already paid)

We’ve got five (FIVE!) free tickets to NamesCon to give away to lucky DI readers.
NamesCon is “a pro-new TLDs conference” happening at the Tropicana hotel in Las Vegas from January 13 to 15, 2014.
It’s being organized by domain investor Richard Lau, Jothan Frakes (Domain Roundtable, DomainFest), and Jodi Chamberlain of 32Events (TRAFFIC, Domaining Europe)
NamesCon seems to be planning something a bit different when compared to new gTLD conferences held to date, judging by the speaker line-up, in that there’s more of a crossover between the ICANNer-heavy new gTLD industry and the traditional domainer community.
There’s a whole bunch of confirmed speakers and panelists (including yours truly) and the organizers tell us that over 300 people have so far registered to attend.
Tickets currently cost $399 (it’s $749 on the door) but we have five passes to give away to DI readers.
The organizers tell me that if any of the winners have already purchased a ticket, they’ll get a full refund.
To enter the draw, just leave an answer to the following question (set by NamesCon) in the comments section of this post.

What’s the best way to explain the benefits of new gTLDs to somebody from outside the domain industry?

Winners will be selected from comments using a random number generator at the weekend.
The prizes are 100% discount codes for full conference passes. You’ll still have to arrange and pay for your own travel and accommodation.
If you cannot or do not intend to attend, but still feel compelled to leave a comment, please say so, so I can be sure to exclude you from the draw.

ICANN will have to make a call on .islam

ICANN is going to have to decide whether to approve the new gTLDs .islam and .halal, after the Governmental Advisory Committee punted the issue.
GAC chair Heather Dryden told ICANN chair Steve Crocker last week (pdf) that the GAC will not provide ICANN with the clarity it so wanted on the two controversial gTLDs.
“[T]he GAC concluded its discussions on these applications with the advice provided in the Beijing Communiqué,” Dryden said. “Accordingly, no further GAC input on this matter can be expected.”
ICANN is therefore left with the following advice:

The GAC recognizes that Religious terms are sensitive issues. Some GAC members have raised sensitivities on the applications that relate to Islamic terms, specifically .islam and .halal. The GAC members concerned have noted that the applications for .islam and .halal lack community involvement and support. It is the view of these GAC members that these applications should not proceed.

My take on this is that the GAC has provided what is often called a “non-consensus” objection, which I believe triggers one of the vaguest parts of the Applicant Guidebook.
One of the three types of GAC Advice on New gTLDs reads:

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.

It seems pretty obvious now that ICANN’s board — nowadays its New gTLD Program Committee — is expected to make a decision whether to accept or reject .islam and .halal.
It would be the first time that ICANN has had to decide whether to reject a gTLD for public policy reasons without the full backing of the GAC in this application round.
It faced a similar conundrum in the 2003 round — albeit using different rules of engagement — when it had to decide the fate of .xxx (which it obviously chose to approve).
The applicant for .islam and .halal is Turkey-based Asia Green IT System.
The Organization for Islamic Cooperation, which claims to represent 1.6 billion Muslims, does not support the bids. It backed two formal Community Objections to the applications, which both failed.
The OIC’s Council of Ministers is meeting this week in Conakry, Guinea, and is expected to come out with some kind of formal statement opposing Islamic-oriented gTLDs that lack support.
The strength of that statement may prove decisive when ICANN comes to consider the issue.

Oh no! Cement company withdraws dot-brand bid

FLSmidth, a Danish cement company, has withdrawn its application for the new gTLD .fls.
It’s the first dot-brand to be withdrawn from the program in months.
FLSmidth had passed Initial Evaluation and was not facing any objections or Governmental Advisory Committee advice, so it’s not immediately clear why the company decided to pull out.
The company recently reported a fall in profitability, so perhaps it’s just trying to cut costs by eliminating superfluous expenses.

TLDH ditches .roma bid after GAC trouble

Top Level Domain Holdings has withdrawn its bid for the .roma gTLD, after apparently running afoul of the Italian government.
The gTLD was to represent the city of Rome, but Italy issued the company with an Early Warning (pdf) a year ago saying the company had “No involvement or support from the local authorities” and should withdraw.
TLDH disputed this, saying in November 2012:

In fact the Company had engaged extensively with the relevant local authority and will provide supporting documentation to the Italian GAC member. Once this evidence has been submitted, the Directors believe that the objection will be withdrawn.

The warning did not escalate to full-blown Governmental Advisory Committee advice, but .roma nevertheless failed Initial Evaluation (pdf) due to the lack of documented government support with its application.
The bid was eligible for Extended Evaluation, but it seems that TLDH was unable to get the required level of support or non-objection from Italy to allow the bid to pass.
It’s the second of TLDH’s applications to get killed off by a GAC member. It withdrew its non-geo application for .spa as soon as Belgium started making noises about its own city of Spa.
The company also ditched plans to apply for .mumbai in 2011 due to confusion about whether the city’s government actually supported it or not.

Donuts’ portfolio swells as ICANN signs 31 new gTLD contracts

ICANN signed 31 new gTLD Registry Agreements yesterday, 24 of which were with Donuts subsidiaries.
Back-end registry provider Neustar was among a handful of companies signing RAs for their dot-brands too.
Donuts signed contracts for: .haus, .properties, .maison, .productions, .parts, .cruises, .foundation, .industries, .vacations, .consulting, .report, .villas, .condos, .cards, .vision, .dating, .catering, .cleaning, .community, .rentals, .partners, .events, .flights and .exposed.
Top Level Design signed for .ink, which is expected to compete with Uniregistry’s already-delegated .tattoo.
XYZ.com signed for its uber-generic budget offering .xyz.
BusinessRalliart is now contracted for its Japanese geo .okinawa.
IRI Domain Management, affiliated with the Mormon church, got its .mormon RA, for what is expected to be a “highly restricted” religious namespace.
KRG Department of Information Technology got .krd, which it wants to use to serve the Kurdish people and Kurdistan region of Iraq.
Finally, Italian management consultancy Praxi got its dot-brand .praxi.

IPO warns about premium loopholes in new gTLD trademark protection

It seems like it’s been an age since we last heard the intellectual property lobby pushing for stronger rights protection mechanisms in new gTLDs, but they’re back just in time for the first launches.
The Intellectual Property Owners Association has written to ICANN this week to warn about loopholes in the standard new gTLD Registry Agreement related to premium name reservations that the IPO said “will adversely affect trademark rights holders”.
The letter (pdf) makes reference to two specific parts of the contract.
Specification 5 enables registries to reserve up to 100 names “necessary for the operation or promotion of the TLD” in section 3.2 and an unlimited number of names in section 3.3.
Section 3.3 is vague enough that I’m aware of new gTLD applicants that still don’t know whether it allows them to reserve an unlimited number of “premium” names or not.
However, most new gTLD registries I’ve talked to appear to be convinced that it does. DotKiwi’s recently announced premium plan seems to be taking advantage of 3.3.
The IPO is worried that massive lists of premium names will wind up containing lots of strings matching trademarks, which will prevent mark holders from defensively registering during Sunrise.
Worse, the IPO said it could lead to registries milking trademark owners for huge fees to register their “premium” marks. It said:

such reservations would invite the abuse of protected marks. For instance, Registry Operators may reserve the marks of protected brands to leverage premium sales. Further, Registry Operators may use this ability to release names to market competitors of the brand owners.

The counter argument, of course, is that owners of spurious trademarks on generic terms could game Sunrise periods to get their hands of potentially valuable domain names (cf. the .eu sunrise)
The IPO wants ICANN to expand the Trademark Clearinghouse to send Trademark Claims notices to new gTLD registries when they reserve a name matching a listed trademark.
It also wants a new dispute procedure that mark owners could use to get names released from reserved status. It would be like UDRP, but modified to allow for registries to reserve dictionary words related to their gTLD strings, the IPO said.
If my sense of the mood of ICANN’s leadership during last month’s Buenos Aires meeting is anything to go by, I can’t see these last-minute requests for changes to RPMs getting much traction, but you never know.

DotKiwi puts $7 million of premium names on sale

DotKiwi has put NZD 8.5 milion ($7 million) of “premium” domain names on the market in advance of the delegation of .kiwi, which it expects to happen this week.
There are 4,668 names on sale right now, ranging in price from NZD 501.50 ($410) to NZD 124,626.71 ($102,000).
The highest price belongs to hotels.kiwi.
The average asking price is NZD 1,832.39 ($1,500).
The registry said:

All premium names have been valued in collaboration with third parties that specialise in valuing domain names around the globe. The value of a .kiwi premium name is determined using historical sales data, search engine popularity and traffic.

There are 32 domains priced at over $10,000. These are the top 10 highest-priced names:
[table id=23 /]
Unlike other new gTLD registries that have introduced tiered renewal pricing for premium names, DotKiwi plans to charge a standard NZD 40 ($33) annual fee for premiums.
DotKiwi tells us that the names have all been reserved, so they’re ineligible for the mandatory Sunrise period (expected to start later this month).
But the names won’t actually be activated until after Sunrise is over. Then, they’ll still be subject to the Trademark Claims service, which alerts trademark owners when their mark has been registered.

Two more new gTLDs delegated

The new gTLDs .menu and .uno have gone live on the internet.
Both appear to have been delegated to the DNS root zone at some point over the last few days — nic.menu and nic.uno are both resolving right now, though nic.uno takes you to an Apache status page.
The Latino-focused .uno is the first gTLD of the 10 applications linked to Kanasas-based DotRegistry to become active; .menu is the first for What Box?, which now has three remaining applications.
What Box has already partnered with Go Daddy to offer .menu domains, priced at $49.99 a year or $199.99 a year if you buy a “priority pre-registration”.
I believe the current total of new gTLDs in the root is 34, 26 of which belong to Donuts.

DNS Namespace Collisions: Detection and Response [Guest Post]

Those tracking the namespace collision issue in Buenos Aries heard a lot regarding the potential response scenarios and capabilities. Because this is an important, deep, and potentially controversial topic, we wanted to get some ideas out early on potential solutions to start the conversation.
Since risk can almost never be driven to zero, a comprehensive approach to risk management contains some level of a priori risk mitigation combined with investment in detection and response capabilities.
In my city of Chicago, we tend to be particularly sensitive about fires. In Chicago, like in most cities, we have a priori protection in the form of building codes, detection in the form of smoke/fire alarms, and response in the form of 9-1-1, sprinklers, and the very capable Chicago Fire Department.
Let’s think a little about what the detection and response capabilities might look like for DNS namespace collisions.
Detection: How do we know there is a problem?
Rapid detection and diagnosis of problems helps to both reduce damage and reduce the time to recovery. Physical security practitioners invest considerably in detection, typically in the form of guards and sensors.
Most meteorological events are detected (with some advance warning) through the use of radars and predictive modeling. Information security practitioners are notoriously light with respect to systematic detection, but we’re getting better!
If there are problematic DNS namespace collisions, the initial symptoms will almost certainly appear through various IT support mechanisms, namely corporate IT departments and the support channels offered by hardware/software/service vendors and Internet Service Providers.
When presented with a new and non-obvious problem, professional and non-professional IT practitioners alike will turn to Internet search engines for answers. This suggests that a good detection/response investment would be to “seed” support vendors/fora with information/documentation about this issue in advance and in a way that will surface when IT folks begin troubleshooting.
We collectively refer to such documentation as “self-help” information. ICANN has already begun developing documentation designed to assist IT support professionals with namespace-related issues.
In the same way that radar gives us some idea where a meteorological storm might hit, we can make reasonable predictions about where issues related to DNS namespace collisions are most likely to first appear.
While problems could appear anywhere, we believe it is most likely that scenarios involving remote (“road warrior”) use cases, branch offices/locations, and Virtual Private Networks are the best places to focus advance preparation.
This educated guess is based on the observation that DNS configurations in these use cases are often brittle due to complexities associated with dynamic and/or location-dependent parameters. Issues may also appear in Small and Medium-sized Enterprises (SMEs) with limited IT sophistication.
This suggests that proactively reaching out to vendors and support mechanisms with a footprint in those areas would also be a wise investment.
Response: Options, Roles, and Responsibilities
In the vast majority of expected cases, the IT professional “detectors” will also be the “responders” and the issue will be resolved without involving other parties. However, let’s consider the situations where other parties may be expected to have a role in response.
For the sake of this discussion, let’s assume that an Internet user is experiencing a problem related to a DNS namespace collision. I use the term “Internet user” broadly as any “consumer” of the global Internet DNS.
At this point in the thought experiment, let’s disregard the severity of the problem. The affected party (or parties) will likely exercise the full range of typical IT support options available to them – vendors, professional support, IT savvy friends and family, and Internet search.
If any of these support vectors are aware of ICANN, they may choose to contact ICANN at any point. Let’s further assume the affected party is unable and/or unwilling to correct the technical problem themselves and ICANN is contacted – directly or indirectly.
There is a critical fork in the road here: Is the expectation that ICANN provide technical “self-help” information or that ICANN will go further and “do something” to technically remedy the issue for the user? The scope of both paths needs substantial consideration.
For the rest of this blog, I want to focus on the various “do something” options. I see a few options; they aren’t mutually exclusive (one could imagine an escalation through these and potentially other options). The options are enumerated for discussion only and order is not meaningful.

• Option 1: ICANN provides technical support above and beyond “self-help” information to the impacted parties directly, including the provision of services/experts. Stated differently, ICANN becomes an extension of the impacted party’s IT support structure and provides customized/specific troubleshooting and assistance.
• Option 2: The Registry provides technical support above and beyond “self-help” information to the impacted parties directly, including the provision of services/experts. Stated differently, the Registry becomes an extension of the impacted party’s IT support structure and provides customized/specific troubleshooting and assistance.
• Option 3: ICANN forwards the issue to the Registry with a specific request to remedy. In this option, assuming all attempts to provide “self-help” are not successful, ICANN would request that the Registry make changes to their zone to technically remedy the issue. This could include temporary or permanent removal of second level names and/or other technical measures that constitute a “registry-level rollback” to a “last known good” configuration.
• Option 4: ICANN initiates a “root-level rollback” procedure to revert the state of the root zone to a “last known good” configuration, thus (presumably) de-delegating the impacted TLD. In this case, ICANN would attempt – on an emergency basis – to revert the root zone to a state that is not causing harm to the impacted party/parties. Root-level rollback is an impactful and potentially controversial topic and will be the subject of a follow-up blog.

One could imagine all sorts of variations on these options, but I think these are the basic high-level degrees of freedom. We note that ICANN’s New gTLD Collision Occurrence Management Plan and SAC062 contemplate some of these options in a broad sense.
Some key considerations:

• In the broader sense, what are the appropriate roles and responsibilities for all parties?
• What are the likely sources to receive complaints when a collision has a deleterious effect?
• What might the Service Level Agreements look like in the above options? How are they monitored and enforced?
• How do we avoid the “cure is worse than the disease” problem – limiting the harm without increasing risk of creating new harms and unintended consequences?
• How do we craft the triggering criteria for each of the above options?
• How are the “last known good” configurations determined quickly, deterministically, and with low risk?
• Do we give equal consideration to actors that are following the technical standards vs. those depending on technical happenstance for proper functionality?
• Are there other options we’re missing?

On Severity of the Harm
Obviously, the severity of the harm can’t be ignored. Short of situations where there is a clear and present danger of bodily harm, severity will almost certainly be measured economically and from multiple points of view. Any party expected to “do something” will be forced to choose between two or more economically motivated actors: users, Registrants, Registrars, and/or Registries experiencing harm.
We must also consider that just as there may be users negatively impacted by new DNS behavior, there may also be users that are depending on the new DNS behavior. A fair and deterministic way to factor severity into the response equation is needed, and the mechanism must be compatible with emergency invocation and the need for rapid action.
Request for Feedback
There is a lot here, which is why we’ve published this early in the process. We eagerly await your ideas, feedback, pushback, corrections, and augmentations.
This is a guest post written by Jeff Schmidt, CEO of JAS Global Advisors LLC. JAS is currently authoring a “Name Collision Occurrence Management Framework” for the new gTLD program under contract with ICANN.