Latest news of the domain name industry

Recent Posts

ICANN content policing power grab may be dead

Kevin Murphy, April 3, 2024, Domain Policy

A move by ICANN to grant itself more formal “content policing” powers may be dead, after the community was split on the issue and governments failed to back the move.

The Governmental Advisory Committee yesterday sent comments essentially opposing, for now at least, the idea of ICANN reforming its bylaws to give it more powers over internet content, making it very unlikely that ICANN would be able to get such amendments approved by its community overseers.

The comments came a few days after ICANN extended the deadline for responses to a December 2023 consultation on whether applicants in the next new gTLD round should be able to sign up to so-called Registry Voluntary Commitments that regulate content in their zones.

RVCs would be an appendix to ICANN Registry Agreements which would commit a registry to, for example, ban certain types of registrant or certain types of content from domains in their gTLDs.

They’re basically a rebadged version of the Public Interest Commitments found in RAs from the 2012 round, in which the likes of .sucks agreed to ban cyberbullying and .music agreed to ban piracy.

But they’ve got ICANN’s board and lawyers worried, because the Org’s bylaws specifically ban it from restricting or regulating internet content. They’re worried that the RVCs might not be enforceable and that ICANN may wind up in litigation as a result.

ICANN has therefore proposed a framework (pdf) in which RVCs would be enforced by ICANN only after an agreed-upon third-party auditor or monitor found that a registry was out of compliance.

The board sent out several pages of questions to all of its Supporting Organizations and Advisory Committees in December, asking among other things whether the bylaws needed to be amended to clarify ICANN’s role, but the responses were split along traditional lines.

Registries and registrars were aligned: there’s no need for a bylaws change, because ICANN should not allow RVCs that regulate content into its contracts at all.

“ICANN should maintain its existing bylaws which exclude content from its mission, and allowing any changes to this could be a slippery slope opening ICANN to becoming a broader ‘content police’,” the Registrars Stakeholder Group said in its response, giving this amusing example:

An example of a content restriction is provided in the proposed implementation framework for .backyardchickens (e.g. no rooster-related content). Restricting rooster-related content would require a significant amount of policing, and could even prohibit valuable content that would benefit such a TLD. For example, a backyard hen farmer might want to promote the pedigree lineage of the roosters that helped sire the hens, show pictures of the roosters that were the fathers, etc. All of this could in theory be prohibited,but would also require review and subjective analysis. This would be a very slippery slope for ICANN, and a substantial departure from its mission. Restricting rooster content would then put ICANN in the place of enforcing laws that prohibit backyard roosters, rather than relying upon the competent government authorities charged with overseeing residential animal husbandry.

The Non-Commercial Stakeholders Group was more strident in its tone, even raising the possibility of legal action if ICANN went down the content policing route, saying “the best way for the Board to address content-related PICs and RVCs is to make it clear that it will reject them categorically.” It added:

The prohibition on content regulation in ICANN’s mission is extremely important and very clear. Mission limitations were a critical part of the accountability reforms that were required before ICANN would be released from US government control in 2016… NCSG will mount a legal challenge to any attempt to dilute this part of the mission.

The opposing view was held by the Business Constituency, the Intellectual Property Constituency, and the At-Large Advisory Committee, which is tasked with representing the interests of ordinary internet users.

They all said that ICANN should be able to allow content-related RVCs in registry contracts, but the IPC and BC said that no bylaws amendment is needed because the bylaws already have a carve-out that enables the Org to enforce PICs in its agreements. The ALAC said a bylaws amendment is needed.

“There is a distinction between ICANN regulating, i.e imposing ‘rules and restrictions on’ services and content, versus the registry operator voluntarily proposing and submitting to such rules and restrictions,” the IPC wrote.

“There is also a distinction between ICANN directly enforcing such rules and restrictions on third parties, i.e. registrants, versus ICANN holding a registry operator to compliance with the specifics of a contractual commitment,” it added.

The last community group to submit a response, fashionably late, was the GAC, which filed its response yesterday having reviewed all the other responses submitted so far. The GAC arguably has the loudest voice at ICANN, but its comments were probably the least committed.

The GAC said that ICANN should only go ahead with a bylaws amendment if it has community backing, but that the community currently lacks consensus. It said, “at this stage there are not sufficient elements to justify commencing a fundamental bylaws amendment to explicitly enable the enforcement of content-related restrictions”.

However, the GAC still thinks that RVCs “will continue to serve as tools for addressing GAC concerns pertaining to new gTLD applications during the next round” and that it wants them to be enforceable by ICANN, with consequences for registries found in breach.

The GAC said that it “will continue to explore options to address this important question”.

This all means that ICANN is a long way from getting the community support it would need to push through a bylaws amendment related to content policing. That’s considered one of the “Fundamental Bylaws” and can only be changed with substantial community support.

Such amendments require the backing of the Empowered Community. That’s the entity created in 2016 to oversee ICANN after it severed ties with the US government. It comprises individuals from five groups — the GAC, the GNSO, the ccNSO, the ALAC and the Address Supporting Organization.

For a fundamental bylaws amendment to get over the line, at least three of these groups must approve it and no more than one must object.

With the GNSO, given its divisions, almost certainly unable to gather enough affirmative votes, the GAC seemingly on the fence, and the ASO and ccNSO recusing themselves so far, only the ALAC looks like a clear-cut yes vote on a possible future bylaws amendment.

Perhaps that’s why ICANN chair Tripti Sinha has written to the ASO and ccNSO in the last few days to ask them whether they’d like to think again about ducking out of the consultation, giving them an extra two weeks to submit comments after the original March 31 deadline.

The ccNSO handles policy for country-code domains and the ASO for IP addresses. Both have previously told ICANN that gTLD policy is none of their business, but Sinha has urged them both to chip in anyway, because “the ICANN Bylaws govern us all”.

ICANN approves ccTLD-killer policy

Kevin Murphy, September 28, 2022, Domain Policy

ICANN has formally adopted a policy that would enable it to remove ccTLDs from the DNS root when their associated countries cease to exist, raising the possibility of the Soviet Union’s .su being deleted.

Last Thursday at ICANN 75 in Kuala Lumpur, the board of directors rubber-stamped the ccNSO Retirement of ccTLDs Policy, which sets out how ccTLDs can be deleted in an orderly fashion over the course of several years.

The policy calls for ICANN and the ccTLD registry to form a “Retirement Plan” when the ccTLD’s string is removed from the ISO 3166-1 Alpha-2 standard, which defines which two-letter strings are reserved for which countries.

Strings are typically removed from this list when a country changes its name (such as Timor-Leste) or breaks up into smaller countries (such as the Netherlands Antilles).

The Retirement Plan would see the ccTLD removed from the root five years after ISO made the change, though this could be extended if the registry asks and ICANN agrees.

In February, I set out the case for why the policy may allow ICANN to retire .su, the thriving ccTLD for the Soviet Union, three decades after that nation was dismantled.

Soviet Union “no longer considered eligible for a ccTLD”, ICANN chair confirms

Kevin Murphy, March 11, 2022, Domain Policy

The former Soviet Union’s .su domain could soon embark along the years-long path to getting kicked off the internet, ICANN’s chair has indicated.

The .su ccTLD, which survived the death of the USSR thirty years ago “is no longer considered eligible for a ccTLD”, Martin Botterman said in response to a question by yours truly at the ICANN 73 Public Forum yesterday.

It seems ICANN will no longer turn a blind eye to .su’s continued existence, and that the policy enabling ccTLDs to be “retired” could be invoked in this case, after it is finalized.

The question I asked, per the transcript, was:

While it is generally accepted that ICANN is not in the business of deciding what is or is not a country, do you agree that the Soviet Union does not meet the objective criteria for ccTLD eligibility? And would you support dot SU entering the ccTLD retirement process as and when that process is approved?

I went into a lot of the background of .su in a post a couple weeks ago, and I’m not going to rehash it all here.

I wasn’t expecting much of a response from ICANN yesterday. Arguments over contested ccTLDs, which usually involve governments, are one of the things ICANN is almost always pretty secretive about.

So I was pleasantly surprised that Botterman, while he may have dodged a direct answer to the second part of the question, answered the first part with pretty much no equivocation. He said, per the recording:

It is correct that the Soviet Union is no longer assigned in the ISO 3166-1 standard and therefore is no longer considered eligible for a ccTLD.

ICANN Org has actually held discussions with the managers of the .su domain in the past to arrange an orderly retirement of the domain, and the ccNSO asked ICANN Org starting in 2010 and reiterated in 2017 to pause its efforts to retire the domain so that the Policy Development Process could be conducted. And that is a request we have honored.

So we’re glad to report that the ccNSO recently concluded that Policy Development Process and sent its policy recommendations to the ICANN board.

We will soon evaluate the ccNSO policy recommendations, and we will do so in line with the bylaws process.

It looked and sounded very much like he was reading these words from his screen, rather than riffing off-the-cuff, suggesting the answer had been prepared in advance.

I wasn’t able to attend the forum live, and I’d submitted the question via email to the ICANN session moderator a few hours in advance, giving plenty of time for Botterman or somebody else at ICANN to prepare a response.

The ccNSO policy referred to (pdf), which has yet to be approved by the ICANN board, creates a process for the removal of a ccTLD from the DNS root in scenarios such as the associated country ceasing to exist.

It’s creatively ambiguous — deliberately so, in my view — when it comes to .su’s unique circumstances, presenting at least two hurdles to its retirement.

First, the Soviet Union stopped being an officially recognized country in the early 1990s, long before this policy, and even ICANN itself, existed.

Second, the .su manager, ROSNIIROS, is not a member of the ccNSO and its debatable whether ICANN policies even apply to it.

In both of these policy stress tests, the ccNSO deferred to ICANN, arguably giving it substantial leeway on whether and how to apply the policy to .su.

I think it would be a damn shame if the Org didn’t at least try.

While it’s widely accepted that ICANN made the correct call by declining to remove Russia’s .ru from the root, allowing .su to continue to exist when it is acknowledged to no longer be eligible for ccTLD status, and the policy tools exist to remove it, could increasingly look like an embarrassing endorsement in light of Russian hostilities in former Soviet states.

Maybe now’s the time for ICANN to start dismantling the Soviet Union

Kevin Murphy, February 25, 2022, Domain Policy

Like I’m sure a great many of you, I spent much of yesterday listening to the news and doom-scrolling social media in despair, anger and helplessness.

War has returned to Europe, with Vladimir Putin’s Russia yesterday invading Ukraine on a flimsy pretext, in an apparent effort to begin to recreate the former Soviet Union.

I watched r/ukraine on Reddit, as its number of subscribers increased by tens of thousands in a matter of hours, with people from all over the world wondering what they could do to help, from volunteering to literally take up arms to hollow if well-meaning virtue-signalling.

Can I volunteer for the Ukrainian army? I live in Japan and can’t speak the language, does that matter?

If any Ukrainians can make it to Ottawa, I have a spare couch for as long as you need it!

Here’s a guide to how I survived the snipers in Sarajevo!

Here’s a yellow-and-blue banner I made that you can use on your Twitter!

Slava Ukraini!

It got me thinking: is there anything the domain industry or ICANN community can do? Is there anything I can do?

The only thing I could think of was to run this idea up the flagpole and see if anyone sets fire to it:

Maybe now’s the time for ICANN to start dismantling the Soviet Union.

It may sound ludicrous. The Soviet Union hasn’t existed outside Putin’s fantasies since 1991.

But it’s alive and well in the DNS, where the top-level domain .su has somehow managed to survive the death of its nation, evade any efforts to have it removed, and stick around in the root for over 30 years.

It currently has over 100,000 registered domains.

I’m not suggesting for a second that all of these domains were registered by people who support the return of the USSR, or are even aware of the connection, but it is the ccTLD of choice for sites like this gung-ho propaganda rag, and the Donetsk People’s Republic, the breakaway Ukrainian region.

Whenever I’ve asked people with better in-depth knowledge of ccTLD policy than me for an explanation of why .su continues to exist, despite not having a nation to represent, I generally get a lot of hand-waving and mumbling about a “lack of political will”.

Maybe there’s a political will now, if not at ICANN Org then perhaps in the ICANN community.

My understanding, based on a deep-dive through the public record, is that it might be possible to have .su deleted — the word ICANN uses is “retired” — but the rules are arguably open to interpretation.

A bit of background first

ICANN’s rules concerning ccTLDs are a bit like the UK constitution — they’re not written down in any one document, but have rather evolved over the years through a combination of habit, convention, case law and pure making-it-up-on-the-spot.

ICANN, and IANA before it, “is not in the business of deciding what is and what is not a country”. It has always deferred to the International Organization for Standardization, which maintains a list of names and corresponding country-codes called ISO 3166-1.

If a country or territory appears on the 3166-1 list, its corresponding “alpha-2” code is eligible to become a ccTLD.

SU was listed on 3166-1, the same as any other country, until September 1992, when it was broken up into 15 names and codes corresponding to the 15 former Soviet nations. Russia got RU and Ukraine got UA, for examples, and their ccTLDs are .ru and .ua.

SU was then given a “transitionally reserved” status by the ISO, which basically means it’s due to be phased off the list altogether (albeit not for 50 years) and organizations are discouraged from using it.

In corresponding ccTLDs, every string on the “transitionally reserved” list has either transitioned to a new ccTLD (such as East Timor’s .tp becoming Timor-Leste’s .tl) or split into a collection of new ccTLDs (such as the break-up of the Netherlands Antilles).

Since ICANN took over the root, these and other transitions typically happen with the consent of the local government and the local registry. But the Soviet Union dissolved long before ICANN existed, it doesn’t have a government, and the registry is in no hurry to give up its asset, which is a bit of a money maker.

ICANN stated its intention to retire .su as early as 2003, and the earliest archived IANA record, from 2006, said it was “being phased out”.

It launched a brief consultation on the retirement of ccTLDs in 2006, which prompted a flood of comments from outraged .su supporters.

The following year, there were face-to-face talks between ICANN and the two Moscow companies running .su at the time — the Foundation for Internet Development (FID) and Russian Institute for Public Networks (RIPN).

IANA’s Kim Davies, who now heads the division as an ICANN VP, blogged in 2007, partly in response to these comments, that .su had a chance to remain delegated:

To retain .SU, under current policy they would need to successfully apply for the code to be re-instated into the ISO 3166-1 standard, either as a regular two-letter country code, or as an “exceptionally reserved” code like UK and EU.

The “exceptionally reserved” list is another subdivision of ISO 3166-1. It currently includes four codes that are also ccTLDs — .ac for Ascension Island, a UK territory, .uk itself, and the European Union’s .eu.

The fourth is .su, because FID somehow managed to persuade the ISO 3166 Maintenance Agency to get SU on the list, reversing its 50-year sentence on the transitional list, in 2008. It appears to be the only example of a private, non-governmental, non-UN entity requesting and obtaining a special listing.

There’s been very little public discussion about .su’s fate since then. My suspicion is that it fell off the radar when ICANN CEO Paul Twomey, who made ccTLD relations a cornerstone of his administration, left the Org in 2009.

Or it could be that that the “exceptionally reserved” status was enough to satisfy IANA’s eligibility criteria. But there are several reasons why that might not be the case.

In Davies’ 2007 blog, post he said: “There are other issues that will need to be addressed for .SU to be a viable ccTLD designation, but recognition by the appropriate standard is a prerequisite.”

IANA currently has a web page in which it lays out seven ways a TLD can get into the root. This is what it says about exceptionally reserved strings:

Eligible under ICANN Board Resolution 00.74. This resolution provides for eligibility for domains that are not on the ISO 3166-1 standard, but that the Maintenance Agency deems exceptionally reserved, and requires that the Agency “has issued a reservation of the code that covers any application of ISO 3166-1 that needs a coded representation in the name of the country, territory, or area involved”. There is currently (as of June 2013) only one code eligible under these requirements, “EU” for the European Union.

The cited ICANN board resolution, now incorporated into IANA precedential law, dates from September 2000. It’s the resolution that hacked historical IANA practice in order to set the groundwork for eventually levering .eu into the root.

But the relevant part here is where IANA explicitly rules out any exceptionally reserved string other than EU meeting the requirements to be a ccTLD as of 2013. SU’s ISO 3166-1 status has not changed since 2008.

RIPN and FID explicitly acknowledged this in a joint letter (pdf) to ICANN then-CEO Paul Twomey in 2007. In it, they wrote:

we understand that should ISO-3166/MA add the two letter code “SU” to the exceptionally reserved or indeterminately reserved ISO3166-1 list will not be sufficient to clarify the status of .SU as current ICANN/IANA policies require a venue in which legality of actions can be determined.

To paraphrase: being on the list ain’t no good if you got no country.

They said that if ICANN went ahead and retired .su anyway, they would like 10 to 15 years to transition their registrants to alternative TLDs.

Which handily brings me to now

There has never been a formal community-agreed ICANN policy on retiring ccTLDs, until now.

By happy coincidence, the ccTLD Name Supporting Organization recently finished work on such a policy. It came out of public comment a few weeks ago and will next (I was going to write “soon”, but you know?) come before the ICANN board of directors for consideration.

The proposed policy (pdf) conspicuously avoids mentioning .su by name and seems to go out of its way to kick the can on .su’s potential retirement.

The silence is deafening, and the ambiguity is claustrophobic.

It defines ccTLDs as:

  • 2-letter ccTLDs corresponding to an ISO 3166-1 Alpha-2 Code Element (the majority of ccTLDs).
  • 2-letter Latin ccTLDs not corresponding to an ISO 3166-1 Alpha-2 Code Element
  • IDN ccTLDs as approved by ICANN

The second bullet point is accompanied by a footnote that explains it’s referring to the “exceptionally reserved” codes UK, AC and EU, three of the four ccTLDs on the ISO’s exceptional list.

The ccTLDs .uk and .ac which refer to exceptionally reserved codes UK and AC are grandfathered as ccTLDs and .eu, which corresponds to the exceptionally reserved code EU, was delegated under the relevant ICANN Board resolution from September 2000

There’s no mention of SU, the fourth.

Under the proposed policy, the ball would start rolling on a possible retirement whenever a “triggering event” happens. The relevant trigger for .su (and .uk, .eu and .ac) is the ISO making a change — seemingly any change — to its 3166-1 listing.

IANA, referred to in the policy as the IANA Functions Operator or IFO, would then have to decide whether the change warranted initiating the retirement process, which would take at least five years.

As is so often the case in ICANN policy-making, the difficult decisions seem to have been punted.

Only one ccTLD operator filed a public comment on this proposed policy — it was RIPN, operator of .su. While generally supportive, it worried aloud that triggering events prior to the approval of the policy should not count. Its triggering events were in 2008 and the 1990s, after all.

The policy’s creators again ambiguously kicked the can:

The [Working Group] believes the applicability of the Policy to existing situations or those emerging before the proposed Policy becomes effective is out of scope of its mandate. For situations prior to this Policy coming into force, responsibility lies with the IFO to create a suitable procedure. The WG suggests that such a procedure could be based on and anticipates the proposed Policy.

So… does ICANN get to apply the policy retroactively or not?

My overall sense is that the .su situation, which the record shows was certainly on the minds of the ccNSO during the early stages of the policy-development process, was considered too difficult to address, so they took the ostrich approach of pretending it doesn’t exist.

The .su registry seems to think it’s safe from enforced retirement, but it doesn’t seem to be absolutely sure.

In conclusion

I think the record shows that .su doesn’t really deserve to exist in the DNS, and that there’s an opportunity to get rid of it. ccTLDs are for countries and territories that exist and the Soviet Union hasn’t existed for three decades.

IANA rules don’t seem to support its existence, and upcoming policy changes seem to give enough wiggle room for the retirement process to be kicked off, if the will is there to do so.

It would take years, sure.

Would it help stop innocent Ukrainians getting gunned down in the street this week? No.

Would it be more than simple virtue signalling? I think so.

And if not, why not just do it anyway?

In a world where an organization like UEFA considers Russia too toxic for poxy football match, what would it say about an organization that allows the actual Soviet Union’s domain to continue to exist online?

Emoji domains get a 😟 after broad study

Kevin Murphy, October 28, 2019, Domain Tech

Domain names containing emojis are a security risk and not recommended, according to a pretty comprehensive review by an ICANN study group.
The Country-Code Names Supporting Organization has delivered the results of its 12-person, 18-month Emoji Study Group, which was tasked with looking into the problems emoji domains can cause, review current policy, and talk to ccTLD registries that currently permit emoji domains.
The ESG didn’t have a lot of power, and its recommendations are basically an exercise in can-kicking, but it’s easily the most comprehensive overview of the issues surrounding emoji domains that I’ve ever come across.
It’s 30 pages long, and you can read it here (pdf).
Emojis are currently banned in gTLDs, where ICANN has to approve new Unicode tables before they can be used by registries at the second level, under its internationalized domain name policy, IDNA 2008.
But ccTLDs, which are not contracted with ICANN, have a lot more flexibility. There are 15 ccTLDs — almost all representing small islands or low-penetration African nations — that currently permit emoji domains, the ESG found.
That’s about 6% of Latin-script ccTLDs out there today. These TLDs are .az, .cf, .fm, .je, .ga, .ge, .gg, .gq, .ml, .st, .to, .tk, .uz, .vu, and .ws.
Five of them, including .tk, are run by notorious freebie registry Freenom, but perhaps the best-known is .ws, where major brands such as Budweiser and Coca-Cola have run marketing campaigns in the past.
The main problem with emojis is the potential for confusing similarity, and the ESG report does a pretty good job of enumerating the ways confusability can arise. Take its comparison of multiple applications’ version of the exact same “grinning face” emoji, for example:
Emoji comparison
If you saw a domain containing one of those in marketing on one platform, would you be able to confidently navigate to the site on another? I doubt I would.
There’s also variations in how registrars handle emojis on their storefronts, the report found. On some you can search with an emoji, on others you’ll need to type out the xn-- prefixed Punycode translation longhand.
In terms of recommendations, the ESG basically just asked ICANN to keep an eye on the situation, to come to a better definition of what an emoji actually is, and to reach out for information to the ccTLDs accepting emojis, which apparently haven’t been keen on opening up so far.
Despite the lack of closure, it’s a pretty good read if you’re interested in this kind of thing.

Kafka turns in grave as ICANN crowbars “useless” Greek TLD into the root

Kevin Murphy, September 9, 2019, Domain Policy

ICANN has finally approved a version of .eu in Greek script, but it’s already been criticized as “useless”.
Yesterday, ICANN’s board of directors rubber-stamped .ευ, the second internationalized domain name version of the European Union’s .eu, which will be represented in the DNS as .xn--qxa6a.
There’s a lot of history behind .ευ, much of it maddeningly illustrative of ICANN’s Kafkaesque obsession with procedure.
The first amusing thing to point out is that .ευ is technically being approved under ICANN’s IDN ccTLD Fast Track Process, a mere NINE YEARS after EURid first submitted its application.
The “Fast Track” has been used so far to approve 61 IDN ccTLDs. Often, the requested string is merely the name of the country in question, written in one of the local scripts, and the TLD is approved fairly quickly.
But in some cases, especially where the desired string is a two-character code, a string review will find the possibility of confusion with another TLD. This runs the risk of broadening the scope of domain homograph attacks sometimes used in phishing.
That’s what happened to .ευ, along with Bulgaria’s Cyrillic .бг and Greece’s own .ελ, which were rejected on string confusion grounds back in 2010 and 2011.
Under pressure from the Governmental Advisory Committee, ICANN then implemented an Extended Process Similarity Review Panel, essentially an appeals process designed to give unsuccessful Fast Track applicants a second bite at the apple.
That process led to Bulgaria being told that .бг was not too similar to Brazil’s .br, and Greece being told that .ελ did not look too much like .EA, a non-existent ccTLD that may or may not be delegated in future, after all.
But the EU’s .ευ failed at the same time, in 2014. The appeals review panel found that the string was confusable with upper-case .EY and .EV.
Again, these are not ccTLDs, just strings of two characters that have the potential to become ccTLDs in future should a new country or territory emerge and be assigned those codes by the International Standards Organization, a low-probability event.
I reported at the time that .ευ was probably as good as dead. It seemed pretty clear based on the rules at the time that if a string was confusable in uppercase OR lowercase, it would be rejected.
But I was quickly informed by ICANN that I was incorrect, and that ICANN top brass needed to discuss the results.
That seems to have led to ICANN tweaking the rules yet again in order to crowbar .ευ into the root.
In 2015, the board of directors reached out to the GAC, the ccNSO and the Security and Stability Advisory Committee for advice.
They dutifully returned two years later with proposed changes (pdf) that seemed tailor-made for the European Union’s predicament.
A requested IDN ccTLD that caused confusion with other strings in only uppercase, but not lowercase (just like .ευ!!!) could still get delegated, provided it had a comprehensive risk mitigation strategy in place, they recommended.
The recommendation was quickly approved by ICANN, which then sent its implementation guidelines (again, tailor-made for EURid (pdf)) back to the ccNSO/SSAC.
It was not until February this year that the ccNSO/SSAC group got back to ICANN (pdf) to approve of its implementation plan and to say that it has already tested it against EURid’s proposed risk-mitigation plan (pdf).
Basically, the process in 2009 didn’t produce the desired result, so ICANN changed the process. It didn’t produced the desired result again in 2014, so the process was changed again.
But at least Greek-speaking EU citizens are finally going to get a meaningful ccTLD that allows them to express their EUishness in their native script, right?
WRONG!
I recently read with interest and surprise a blog post by domainer-blogger Konstantinos Zournas, in which he referred to .ευ as the “worst domain extension ever”.
Zournas, who is Greek, opened my eyes to the fact that “.ευ” is meaningless in his native tongue. It’s just two Greek letters that visually resemble “EU” in Latin script. It’s confusing by design, but with .eu, a ccTLD that EURid already manages.
While not for a moment doubting Zournas’ familiarity with his own language, I had to confirm this on the EU’s Greek-language web site.
He’s right, the Greek for “European Union” is “Ευρωπαϊκής Ένωσης”, so the sensible two-letter IDN ccTLD would be .ΕΈ (those are Greek characters that look a bit like Latin E).
That would have almost certainly failed the ICANN string similarity process, however, as .ee/EE is the current, extant ccTLD for Estonia.
In short (too late), it seems to have taken ICANN the best part of a decade, and Jesus H Christ knows how many person-hours, to hack its own procedures multiple times in order to force through an application for a TLD that doesn’t mean anything, can’t be confused with anything that currently exists on the internet, and probably won’t be widely used anyway.
Gratz to all involved!

UN ruling may put .io domains at risk

Kevin Murphy, February 25, 2019, Domain Policy

The future of .io domains may have been cast into doubt, following a ruling from the UN’s highest court.
The International Court of Justice this afternoon ruled (pdf) by a 13-1 majority that “the United Kingdom is under an obligation to bring to an end its administration of the Chagos Archipelago as rapidly as possible”.
The Chagos Archipelago is a cluster of islands that the UK calls the British Indian Ocean Territory.
It was originally part of Mauritius, but was retained by the UK shortly before Mauritius gained independence in 1968, so a strategic US military base could be built on Diego Garcia, one of the islands.
The native Chagossians were all forcibly relocated to Mauritius and the Seychelles over the next several years. Today, most everyone who lives there are British or American military.
But the ICJ ruled today, after decades of Mauritian outrage, that “the process of decolonization of Mauritius was not lawfully completed when that country acceded to independence in 1968, following the separation of the Chagos Archipelago”.
So BIOT, if the UK government follows the ruling, may cease to exist in the not-too-distant future.
BIOT’s ccTLD is .io, which has become popular with tech startups over the last few years and has over 270,000 domains.
It’s run by London-based Internet Computer Bureau Ltd, which Afilias bought for $70 million almost two years ago.
Could it soon become a ccTLD without a territory, leaving it open to retirement and removal from the DNS root?
It’s not impossible, but I’ll freely admit that I’m getting into heavy, early speculation here.
There are a lot of moving parts to consider, and at time of writing the UK government has not even stated how it will respond to the non-binding ICJ ruling.
Should the UK abide by the ruling and wind down BIOT, its IO reservation on the ISO 3166-1 alpha-2 list could then be removed by the International Standards Organisation.
That would mean .io no longer fits the ICANN criteria for being a ccTLD, leaving it subject to forced retirement.
Retired TLDs are removed from the DNS root, meaning all the second-level domains under them stop working, obviously.
It’s not entirely clear how this would happen. ICANN’s Country Code Names Supporting Organization has not finished work on its policy for the retirement of ccTLDs.
TLDs are certainly not retired overnight, without the chance of an orderly winding-down.
Judging by the current state of ccNSO discussions, it appears that ccTLDs could in future be retired with or without the consent of their registry, with a five-to-10-year clock starting from the string’s removal from the ISO 3166-1 list.
Under existing ICANN procedures, I’m aware of at least two ccTLDs that have been retired in recent years.
Timor-Leste was given .tl a few years after it rebranded from Portuguese Timor, and .tp was removed from the DNS a decade later. It took five years for .an to be retired after the Netherlands Antilles’ split into several distinct territories in 2010.
But there are also weird hangers-on, such as the Soviet Union’s .su, which has an “exceptional reservation” on the ISO list and is still active (and inexplicably popular) as a ccTLD.
As I say, I’m in heavy speculative territory when it comes to .io, but it strikes me that not many registrants will consider when buying their names that the territory their TLD represents may one day simple poof out of existence at the stroke of a pen.
Afilias declined to comment for this article.

Roberts elected to ICANN board

Kevin Murphy, December 4, 2017, Domain Policy

Channel Islands ccTLD operator Nigel Roberts has been elected to ICANN’s board of directors.
He gathered an impressive 67% of the votes in an anonymous poll of ccNSO members conducted last week.
He received 60 votes versus the 29 cast for his only opponent, Pierre Ouedraogo, an internet pioneer from Burkina Faso.
Roberts, a Brit, runs ChannelIsles.net, registry manager for .gg (for the islands Guernsey, Alderney and Sark) and .je (for Jersey). These are the independent UK dependencies found floating between England and France.
He’s been in the ICANN community since pretty much day one.
His election still has to be formally confirmed by the ccNSO Council and then the ICANN Empowered Community.
Roberts will not take his seat on the ICANN board until October next year, at the end of public meeting in Barcelona.
He will replace Mike Silber, the South African who’s currently serving his ninth and therefore final year as a director.
The other ccNSO seat is held by Australian ICANN vice chair Chris Disspain, who is also term-limited and will leave at the end of 2019.

Election season at ICANN

Kevin Murphy, October 4, 2017, Domain Policy

Two significant votes are coming up soon in the ICANN community, with the GNSO Council looking for a new chair and the ccNSO ready to select a new appointee for the ICANN board of directors.
The ccNSO election will see an actual contest for what is believed to be the first time, with at least two candidates fighting it out.
The GNSO vote is rather less exciting, with only one candidate running unopposed.
It seems Heather Forrest, an intellectual property lawyer, occasional new gTLD consultant, and professor at the University of Tasmania, will replace GoDaddy VP of policy James Bladel as Council chair a month from now.
Forrest, currently a vice-chair, was nominated by the Non-Contracted Parties House.
The Contracted Parties House (registries and registrars), evidently fine with Forrest taking over, decided not to field a candidate, so the November 1 vote will be a formality.
In the ccNSO world, the country-codes are electing somebody to take over from Mike Silber on the ICANN board, a rather more powerful position, when his term ends a year from now.
Nominations don’t close until a week from now, but so far there are two candidates: Nigel Roberts and Pierre Ouedraogo.
Roberts, nominated for the job by Puerto Rico, runs a collection of ccTLDs for the British Channel Islands.
Ouedraogo is from Burkina Faso but does not work for its ccTLD. He is a director of the Francophone Institute for Information and New Technologies. He was nominated by Kenya.
Both men are long-time participants in ICANN and the ccNSO.
Roberts, who currently sits on the ccNSO Council, tells me he believes it’s the first time there’s been a contested election for a ccNSO-appointed ICANN board seat since the current system of elections started in 2003.
Silber has been in the job for eight years and is term-limited so cannot stand again. The other ccNSO appointee, Chris Disspain, will occupy the other seat for another two years.

In harsh tones, ccNSO rejects NomCom appointee

Kevin Murphy, October 2, 2017, Domain Registries

ICANN’s Country Code Names Supporting Organization has rejected the appointment to its Council of a Canadian registry director.
Saying NomCom ignored long-standing guidance to avoid appointing registry employees, the ccNSO Council has said the recent naming of Marita Moll to the role is “unacceptable”.
Moll will have to choose between sitting on the Council and being a director of .ca registry CIRA, the Council said in a letter to NomCom and the ICANN board.
Three of the Council’s 18 voting members are selected by NomCom. The rest are elected from ccTLD registries, three from each of ICANN’s five geographic regions.
To maintain balance, and promote independent views, the Council told NomCom most recently back in 2012 that it should refrain from appointing people connected to ccTLD registries.
The new Council letter (pdf) reads:

Council’s view (none dissenting) is that your Committee’s proposed selection directly contravenes this requirement, notwithstanding the clear and explicit assurance we received in 2012 from the then Chair of Nominating Committee that the Committee would be “avoiding any member already belonging to the ccTLD management participating in the ccNSO”.

The situation is exacerbated by the fact that CIRA already has representation on the Council in the form of CEO Byron Holland.
The letter concludes that the conflict is “irreconcilable” and the appointment “unacceptable”.
As the ccNSO does not appear to have refusal powers on NomCom appointees, it will presumably be up to Moll to decline the appointment.