ICANN’s Ukraine relief may extend to Russians too

Russian domain name registrants affected by sanctions could benefit from ICANN’s relaxation of its renewal rules.

ICANN on Monday announced that it was classifying the war in Ukraine as an “extenuating circumstance” under the terms of its standard Registrar Accreditation Agreement.

This means that Ukrainians cut off from the internet due to the invasion could be cut some slack, at their registrar’s discretion, when it comes to renewing their gTLD domains.

But ICANN’s executive team was asked, during a session at ICANN 73 later that day, whether the same benefits could be extended to Russian registrants, perhaps unable to pay due to Western sanctions on payment systems.

Visa, Mastercard, American Express and Paypal are among those to restrict Russian accounts in recent days.

ICANN mostly ducked the question.

Co-deputy CEO Theresa Swinehart responded by deferring to the original blog post, and general counsel John Jeffrey followed up by quoting some of the post’s language:

“I think we’re clear in that the events in Ukraine and the surrounding region are now considered by ICANN to be an extending circumstance under the Registrar Accreditation Agreement, under 3.7.5.1,” he said.

The words “surrounding region”, found in the original post alongside “affected region” and “affected area”, seem to be key here.

They could just as easily refer to Russia as they could to places such as Poland and Hungary, which are currently accepting hundreds of thousands of Ukrainian refugees.

It seems the registrars may have the discretion here; ICANN was apparently in no hurry to provide clarity.

The exchange came during a 90-minute session in which ICANN’s executive team were peppered with community questions, many related to the war and how ICANN might be affected by US-imposed sanctions.

Execs said that ICANN would comply with any US laws related to sanctions but that so far it had not seen anything that would affect its ability to contract with Russian companies.

A question apparently related to whether ICANN was reviewing its relationships with law firms and banks that may be involved with Russian oligarchs, much like Tucows is doing, was ducked.

They were also asked how the $1 million ICANN at the weekend earmarked to help keep Ukraine online might be spent, and while CEO Göran Marby alluded to a broad request from Ukraine for satellite terminals, he said it had been less than a day since the resolution was passed and it was too early to say.

“We obviously will focus on what we can do that makes the maximum impact as close to our mission as we possibly can,” added Sally Costerton, senior VP of stakeholder engagement.

ICANN offers $1 million to Ukraine projects, supports Ukrainian registrants

ICANN has allocated $1 million to help protect internet access in war-torn Ukraine.

Its board of directors at the weekend voted to set aside the “initial sum” of money “to provide financial assistance to support access to Internet infrastructure in emergency situations.”

There’s an expectation that the cash will be spent “on support for maintaining Internet access for users within Ukraine”, where the Russian invasion is described as “tragic and profoundly troubling”, over the next few months, the board said.

It’s not clear yet exactly how the money will be spent, though something related to the keeping the DNS up and running would seem to be the most probable. The resolution calls for the CEO to develop a process to figure it out.

Ukraine’s ccTLD manager, Hostmaster, moved its servers into other European countries shortly after the invasion, and signed up to Cloudlflare’s DDoS protection service. It’s not clear whether it had to spend money on these moves.

ICANN’s million will come from its regular operating budget, not the stash it has set aside from its new gTLD auctions. The auction money will probably be spent on similar things eventually, but the process for allocating that is still being worked out in a committee.

ICANN also said this week that it is, as I and others suggested, exercising section 3.7.5.1 of its Registrar Accreditation Agreement to declare the invasion an “extenuating circumstance”, meaning Ukrainians who are unable to renew their domain name registrations before they expire may not lose them.

Registrars now have the option to keep these domains registered after their usual expiration date and ICANN will not send its Compliance enforcers after them.

“We encourage registrars and registries to support this action and take these circumstances into consideration when reviewing impacted registrants’ renewal delinquencies in affected regions,” ICANN said.

It’s the first time ICANN has exercised this power in connection with a human-made disaster. It previously invoked 3.7.5.1 in response to Hurricane Maria in Puerto Rico and worldwide in response to the Covid-19 pandemic.

Hostmaster itself has extended the redemption period for .ua domains from 30 to 60 days.

ICANN says NO to Ukraine’s Big Ask

“ICANN has been built to ensure that the Internet works, not for its coordination role to be used to stop it from working.”

That’s ICANN’s response to Ukraine, which earlier this week asked for Russia to lose its top-level domains and IP addresses, to help prevent propaganda supporting its invasion of the country.

The request was arguably based on a misunderstanding of the extent of ICANN’s powers, and CEO Göran Marby says as much in his response last night (pdf) to Ukraine’s deputy prime minister Mykhailo Fedorov:

In our role as the technical coordinator of unique identifiers for the Internet, we take actions to ensure that the workings of the Internet are not politicized, and we have no sanction-levying authority

He goes on to warn about the “devastating and permanent effects” of ICANN suddenly deciding to take unilateral action against .ru, .рф and .su:

For country-code top-level domains, our work predominantly involves validating requests that come from authorized parties within the respective country or territory. The globally agreed policies do not provide for ICANN to take unilateral action to disconnect these domains as you request. You can understand why such a system cannot operate based on requests from one territory or country concerning internal operations within another territory or country. Such a change in the process would have devastating and permanent effects on the trust and utility of this global system.

He concludes:

Within our mission, we maintain neutrality and act in support of the global Internet. Our mission does not extend to taking punitive actions, issuing sanctions, or restricting access against segments of the Internet — regardless of the provocations. ICANN applies its policies consistently and in alignment with documented processes. To make unilateral changes would erode trust in the multistakeholder model and the policies designed to sustain global Internet interoperability.

The response is expected, and I believe broadly, if not unanimously, supported in the ICANN community.

In a line I wish I’d written, the Internet Society’s CEO Andrew Sullivan put it pretty succinctly in a blog post yesterday:

The idea of unplugging a country is as wrong when people want to do it to another country as it is when governments want to do it to their own.

And Sébastien Bachollet, chair of ICANN stakeholder group EURALO, insisted (pdf) that “the Internet must remain intact”.

RIPE NCC, which had been asked to revoke IP addresses supplied to Russian organizations, wrote that it “believes that the means to communicate should not be affected by domestic political disputes, international conflicts or war.”

ICANN may take a short-term PR hit in the wider world, which includes people who have a misunderstanding of how powerful ICANN is and how tenuous its grasp on the powers it does have.

While .ru appears to be safe, there’s nothing I read in Marby’s letter that would preclude it from initiating retirement proceedings against .su, when the proper policies have been approved.

Ukraine asks ICANN to turn off Russia’s internet, but it’s a bad idea

Ukraine has asked ICANN to take down Russia’s top-level domains.

Andrii Nabok, the Ukrainian official on ICANN’s Governmental Advisory Committee made the request, asking the Org to “Revoke, permanently or temporarily, the domains .ru, .рф and .su” in a widely circulated email last night.

He also asked for DNS root servers in Moscow and St Petersburg to be shut down, and said he’s written to RIPE NCC to request IP addresses issued to Russian organizations to be withdrawn.

The request came on the fifth day of the Russian invasion, amid widespread, swingeing international sanctions targeting the Russian economy and high net worth individuals.

Accusing Russia of “war crimes”, Nabok wrote:

These atrocious crimes have been made possible mainly due to the Russian propaganda machinery using websites continuously spreading disinformation, hate speech, promoting violence and hiding the truth regarding the war in Ukraine. Ukrainian IT infrastructure has undergone numerous attacks from the Russian side impeding citizens’ and government’s ability to communicate.

Moreover, it’s becoming clear that this aggression could spread much further around the globe as the Russian Federation puts the nuclear deterrent on “special alert” and threatens both Sweden and Finland with “military and political consequences” if these states join NATO. Such developments are unacceptable in the civilized, peaceful world, in the XXI century.

Reaction in the community has been more mixed than I would have expected, but I think on balance more people are saying that turning off .ru et al would be a terrible idea, and I’m basically with that majority.

While there’s no doubt that Russia is spreading a lot of misinformation, I’m not sure there’s a direct, clear, demonstrable causal link between propaganda published on .ru domains and the missiles currently raining down on Kyiv that could be remedied by deleting a few lines from a database.

I’ve no doubt ICANN now has a painful decision to make, but I don’t think ICANN is the place to achieve this kind of goal and I think ICANN agrees with me.

We don’t want those clowns deciding what can and can’t be published on the internet, trust me.

Not even in the extraordinary circumstances we find ourselves in today.

ICANN is not competent enough, smart enough, or ethical enough to have that kind of power.

It is smart enough to accept its own limitations, however, and it has a strong enough sense of self-preservation to know that to accept Ukraine’s demands would be to sign its own death warrant.

ICANN only has power, and its execs only pull in the big salaries, because it has the consensus support of the internet community.

For 20 years outsiders, such as the ITU and more lately blockchain projects, have sought to chip away at that consensus and replace the multistakeholder model with multilateralism or crypto-based wish-thinking.

Turning off a nation’s TLD would play exactly into the narrative that DNS oversight is dangerously centralized, dangerously Americanized, and ripe for replacement.

That could not only lead to the death of ICANN but also the death of the open, interoperable, international internet.

As much as I support sanctions against Russia, and have nothing but respect and admiration for the people of Ukraine, I fear this is an ask too far.

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

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?

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?

Registrar hit with second porn UDRP breach notice this year

A Chinese registrar group has been accused by ICANN of shirking its UDRP obligations for the second time this year.

ICANN has put Hong Kong-based DomainName Highway on notice that is in breach of its contract for failing to transfer the domain 1ockheedmartin.com to defense contractor Lockheed Martin.

The domain is a straightforward case of typosquatting, with the initial L replaced with a numeral 1. At time of writing, it still resolves to a page of pornographic thumbnail links, despite being lost in a UDRP case January 4.

Under UDRP rules, registrars have 10 days to transfer a UDRP-losing domain to the trademark owner, unless a lawsuit prevents it.

The circumstances are very similar to a breach notice ICANN issued against ThreadAgent.com over a case of BMW’s brand being cybersquatted with porn last month.

Both ThreadAgent and DomainName Highway appear to be part of the XZ.com, aka Xiamen DianMedia Network Technology Co, which is based in China but has about 20 accredited registrars based in Hong Kong.

DomainName Highway has about 30,000 gTLD domains under management.

Costa Rica’s only registrar gets terminated

Costa Rica no longer has any in-country accredited registrars, after ICANN terminated Toglodo for non-payment of fees.

ICANN told the company last week that its accreditation is terminated effective February 23.

It seems Toglodo owed ICANN thousands of dollars in past-due fees. The Org says had been chasing it for money since at least March last year, but had not managed to make contact.

The registrar once had a few thousand gTLD domains under management, mostly .coms, but that’s dwindled to almost nothing recently. Whatever domains remain, ICANN will attempt to transfer to another registrar.

ICANN stuck between Ukraine and Russia in time zone debate

As the world waits nervously to see whether Russia’s weeks-long troop build-up on the Ukrainian border will result in an invasion, ICANN is embroiled in an infinitely more trivial conflict between the two nations.

As well as overseeing domain names, IP addresses and protocol numbers, a decade ago ICANN took over the time zone database that most of the world’s computers rely on to figure out what the correct time is or was.

The Time Zone Database or tzdb has been hosted by ICANN’s IANA unit since 2011, when it stepped in to relieve the previous host, which was being badgered in court by astrologers.

It’s managed and regularly updated — such as when a country changes its time zone or modifies its daylight savings practices — by Paul Eggert of the University of California.

While it’s apolitical, governed by IETF best practice, it occasionally finds itself in the firing line due to political controversies.

In recent years, a recurrent controversy — which has raised its head again this month in light of the current border crisis — has been the spelling of the Ukrainian capital city.

It has long been rendered in English as “Kiev”, but that’s the Latin-script transliteration of the Russian-Cyrillic spelling Киев, rather than the Ukrainian-Cyrillic spelling, Київ, which is transliterated as “Kyiv”.

With tensions between Russia and Ukraine intensifying since the 2014 annexation of Crimea, Ukraine has for years appealed to the international community to change its “painful” spelling practices.

The Ukrainian Ministry of Foreign Affairs in 2019, part of its #CorrectUA and #KyivNotKiev campaigns, described the situation like this:

Under the Russian empire and later the Union of Soviet Socialist Republics (USSR), Russification was actively used as a tool to extinguish each constituent country’s national identity, culture and language. In light of Russia’s war of aggression against Ukraine, including its illegal occupation of Crimea, we are once again experiencing Russification as a tactic that attempts to destabilize and delegitimize our country. You will appreciate, we hope, how the use of Soviet-era placenames – rooted in the Russian language – is especially painful and unacceptable to the people of Ukraine.

Many English-language news outlets — including the Associated Press and Guardian style guides, the BBC, New York Times and Wall Street Journal — have since switched to the “Kyiv” spelling, though many are still using “Kiev”.

The US and UK governments both currently use “Kyiv”. Wikipedia switched to “Kyiv” in 2020. ICANN’s own new gTLD program rules, which draw on international standards, would treat both “Kiev” and “Kyiv” as protected geographic names.

My Windows computer used “Kyiv”, but the clock on my Android phone uses “Kiev”.

The tzdb currently lists Kyiv’s time zone as “Europe/Kiev”, because it follows the English-language consensus, with the comments providing this October 2018 explanation from Eggert:

As is usual in tzdb, Ukrainian zones use the most common English spellings. For example, tzdb uses Europe/Kiev, as “Kiev” is the most common spelling in English for Ukraine’s capital, even though it is certainly wrong as a transliteration of the Ukrainian “Київ”. This is similar to tzdb’s use of Europe/Prague, which is certainly wrong as a transliteration of the Czech “Praha”. (“Kiev” came from old Slavic via Russian to English, and “Prague” came from old Slavic via French to English, so the two cases have something in common.) Admittedly English-language spelling of Ukrainian names is controversial, and some day “Kyiv” may become substantially more popular in English; in the meantime, stick with the traditional English “Kiev” as that means less disruption for our users.

Because the tzdb is incorporated in billions of installations of operating systems, programming frameworks and applications worldwide, a conservative approach to changes has been used for compatibility reasons.

In addition, the spelling in the database is not supposed to be exposed to end users. Developers may use tzdb in their code, but they’re encouraged to draw on resources such as the Unicode Common Locale Data Repository to localize their user interfaces.

As Eggert put it on the tzdb mailing list recently “the choice of spelling should not be important to end users, as the tzdb spelling is not intended to be visible to them”.

Based on past changes, it seems that “Kyiv” could one day before too long supplant “Kiev” in the tzdb, if the current political status quo remains and English-speaking nations increasingly support Ukraine’s independent sovereignty.

But if Russia should invade and occupy, who knows how the language will change?

This article has been part of an irregular series entitled “Murphy Feels Guilty About Covering Incredibly Serious Current Events With A Trivial Domain Angle, But He Writes A Domain Blog So Cut Him Some Slack FFS”.

Greek .eu domains to be deleted

EURid has started warning registrants that their Greek-script .eu domains will be deleted this year.

The names will no longer work after November 14, the company said yesterday.

It’s part of the registry’s three-year plan to phase out mixed-script internationalized domain names, which are considered poor security practice.

The affected domains are Greek-script IDN.eu names, not IDN.IDN names using the Greek-script .ευ.

.ευ was introduced in 2019, after an amusingly Kafkaesque, yet typically ICANN, decade-long effort to crowbar the ccTLD through its IDN Fast Track rules.

Because EURid had been accepting Greek-script second-level names under its base Latin .eu domain for some time, it grandfathered existing registrants by “cloning” their .eu names into .ευ, albeit with only a three-year lifespan.

There were only 2,694 .ευ domains registered at the end of 2021, so one must assume that the number of domains on the deleting list must be smaller.

“It’s not our fault!” — ICANN blames community for widespread delays

ICANN may be years behind schedule when it comes to getting things done on multiple fronts, but it’s the community’s fault for making up rubbish policies, bickering endlessly, and attempting to hack the policy-making process.

That’s me paraphrasing a letter sent last week by chair Maarten Botterman to the Registries Stakeholder Group, in which he complained about the community providing “ambiguous, incomplete, or unclear policy recommendations”.

RySG chair Samantha Demetriou had written to Botterman (pdf) in December to lament the Org and board’s lack of timely progress on many initiatives, some of which have been in limbo for many years.

Policies and projects related to Whois, new gTLDs and the Independent Review Process have been held up for a long time, in the latter case since 2013, she wrote, leading to community volunteers feeling “disempowered or discouraged”.

As I recently reported, ICANN has not implemented a GNSO policy since 2016.

The lack of board action on community work also risks ICANN’s legitimacy and credibility, Demetriou wrote.

But Botterman’s response (pdf), sent Thursday, deflects blame back at the community, denying that the delays are “simply because of failure at the level of the organization and Board.”

He wrote:

we need to continue to find our way forward together to address the challenges that affect the efficiency of our current decision-making processes, including, for example, ambiguous, incomplete, or unclear policy recommendations, the relitigation of policy issues during implementation, and the use of the review process to create recommendations that should properly be addressed by policy development

In other words, the community is providing badly thought-out policy recommendations, continuing to argue about policy after the implementation stage is underway, and using community reviews, rather than the Policy Development Process, to create policy.

The RySG, along with their registrar counterparts, put their concerns to the board at ICANN 72 in October, warning of “volunteer burnout” and a “chilling effect” on community morale due to board and Org inaction.

At that meeting, director Avri Doria presented staff-compiled stats showing that across five recent bylaws-mandated community reviews (not PDPs), the board had received 241 recommendations.

She said that 69% had been approved, 7% had been rejected, 18% were placed in a pending status, and 6% were “still being worked on”.

CEO Göran Marby provided a laundry list of excuses for the delays, including: reconciling differing community viewpoints, the large number of recommendations being considered, the potential for some recommendations to break ICANN bylaws, sensitivity to the bottom-up nature of the multi-stakeholder process, lack of staff, and the extra time it takes to be transparent about decision-making.

Just this week, ICANN has posted eight job listings, mostly in policy support.

In his letter last week, Botterman pointed to a “Prioritization Framework”, which is currently being piloted, along with further community conversations at ICANN 73 next month and a “thought paper” on “evolving consensus policies”.

Because why fix something when you can instead create another layer of bureaucracy and indulge in more navel-gazing?