Latest news of the domain name industry

Recent Posts

New gTLD applicants get a way to avoid name collision delay

Kevin Murphy, October 9, 2013, 10:39:16 (UTC), Domain Tech

ICANN has given blessed relief to many new gTLD applicants by wiping potentially months off their path to delegation.
Its New gTLD Program Committee this week adopted a new “New gTLD Collision Occurrence Management Plan” which aims to tackle the problem of clashes between new gTLDs and names used on private networks.
The good news is that the previous categorization of strings according to risk, which would have delayed “uncalculated risk” gTLDs by months pending further study, has been scrapped.
The two “high risk” strings — .home and .corp — don’t catch a break, however. ICANN says it will continue to refuse to delegate them “indefinitely”.
For everyone else, ICANN said it will conduct additional studies into the risk of name collisions, above and beyond what Interisle Consulting already produced.
The study will take into account not only the frequency that new gTLDs currently generate NXDOMAIN traffic in the DNS root, but also the number of second-level domains queried, the diversity of requesting sources, and other factors.
Any new gTLD applicant that does not wish to wait for this study will be able to proceed to delegation without delay, but only if they block huge numbers of second-level domains at launch.
The registries will have to block every SLD that was queried in their gTLD according to the Day in the Life of the Internet data that Interisle used in its study.
This list will vary by TLD, but in the most severe cases is likely to extend to tens of thousands of names. In many cases, it’s likely to be a few thousand names.
Fortunately, studies conducted by the likes of Donuts and Neustar indicate that many of these SLDs — maybe even the majority — are likely to be invalid strings, such as those with an underscore or other non-DNS character, or randomly generated 10-character strings of gibberish generated by Google Chrome.
In other words, the actual number of potentially salable domains that registries will have to block may turn out to be much lower than it appears at first glance.
Each SLD will have to be blocked in such a way that it continues to return NXDOMAIN responses, as they all do today.
Because the DITL data represented a 48-hour snapshot in May 2013, and may not include every potentially affected string, ICANN is also proposing to give organizations a way to:

report and request the blocking of a domain name (SLD) that causes demonstrably severe harm as a consequence of name collision occurrences.

The process will allow the deactivation (SLD removal from the TLD zone) of the name for a period of up to two (2) years in order to allow the affected party to effect changes to its network to eliminate the DNS request leakage that causes collisions, or mitigate the harmful impact.

One has to wonder if any trademark lawyers reading this will think: “Ooh, free defensive registration!” It will be interesting to see if any of them give it a cheeky shot.
I’ve got a feeling that most new gTLD applicants will want to take ICANN up on its offer. It’s not an ideal solution for them, but it does give them a way to get into the root relatively quickly.
There’s no telling what ICANN’s additional studies will find, but there’s a chance it could be negative for their string(s) — getting delegated at least mitigates the risk of never getting delegated.
The new ICANN proposal may in some cases interfere with their plans to market and use their TLDs, however.
Take a dot-brand such as .cisco, which the networking company has applied for. Its block list is likely to have about 100,000 strings on it, increasing the chances that useful, brandable SLDs are going to be taken out of circulation for a while.
ICANN is also proposing to conduct an awareness-raising campaign, using the media, to let network operators know about the risks that new gTLDs may present to their networks.
Depending on how effective this is, new registries may be able to forget about getting positive column inches for their launch — if a journalist is handed a negative angle for a story on a plate, they’ll take it.



Tagged: , , ,

Comments (4)

  1. Adrian Kinderis says:

    I am not sure it is a rosy as you make out. Where is the master list that I require for option 2 (the snapshot). I’d like to see it before making any judgements.

  2. Michael Palage says:

    Adrian
    You hit the nail on the head. When will the Master List in the Alternate Path to Delegation (Option 2/Section 3.3/Fast-Track) be available. Can it be made available in the next couple of weeks, or will ICANN only produce this Master List after the commissioning of the study “to develop a name collision occurrence management framework.”
    Considering that those Registry Operators that want to take the Alternate Path to Delegation will need to “participate with ICANN in the process that enables affected party(ies) to report and request the blocking of a domain” seems to suggest that the management framework study would need to be completed first. How else could new Registry Operators work with ICANN if ICANN has no framework?
    Also important is the fact that this management framework study will be subject to public comment. I find it hard to see how those stakeholders that have raised substantial concerns regarding name collision issues, will not voice similar concerns.
    So while some in the community are touting Section 3.3 as a fast track, I struggle to see these most recent developments as being anything other than another delay. It is also important to note that the NGPC resolution calls for this matter being referred to the Board Risk Committee. I currently see no scheduled Risk Committee meetings scheduled on the ICANN website before Buenos Aires, see http://www.icann.org/en/groups/board/meetings
    Another unknown variable is whether the US Government decides to permit delegations where the Registry Operator has elected the Alternate Path to Delegation.
    Buenos Aires should prove to be a very interesting meeting.

  3. Rubens Kuhl says:

    Considering Google Chrome generates lots of 10-character random strings that will now appear in every complete DITL list, every list will be big for TLDs accepting ASCII SLDs, whether they are IDN or ASCII TLDs.
    IDNs that don’t accept ASCII strings will happily take the fast track as their list will be composed of 0 valid names…

  4. ICANN cuts the baby in half and thinks it’s Solomon.

Add Your Comment