CENTR kicks out Russia

CENTR, the association of European domain registries, has kicked out the Russian ccTLD operator due to the war in Ukraine.

In a brief statement today, the organization said:

The CENTR Board is following Russian military actions in Ukraine with concern and strongly condemns the violation of international law and Ukraine’s territorial integrity. Ukraine’s national TLD registry is a member of CENTR and we stand with Ukrainians in their efforts to resist Russia’s invasion. We hope for a swift and peaceful resolution of the conflict, and will continue to offer support and help to our Ukrainian colleagues.

Knowledge and information sharing are key to CENTR’s mission, and the CENTR Board needs to safeguard trust within the CENTR community. The Board has therefore decided to suspend the membership of the Coordination Center for TLD RU/РФ, effective immediately. The Board would like to underline that this is in no way targeted at our Russian colleagues. This suspension will be assessed by the CENTR General Assembly at their meeting in March.

I’m not sure the move will have much of an impact on the Coordination Center, but it’s a strong gesture of solidarity with the people of Ukraine, and the latest response from the domain industry to Russia’s insane war.

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?

Cybersquatting cases down in .uk

The number of cybersquatting complaints, and the number of successful cybersquatting complaints, were down in .uk last year, according to new data from local registry Nominet.

Nominet said that its Dispute Resolution Service, which has a monopoly on .uk disputes, handled just 548 cases in 2021, the lowest number in the 20-year history of the DRS.

Only 43% of the complaints resulted in the domain being transferred, Nominet said. That’s down from 46% in 2020, 47% in 2019 and 49% in 2018, it said.

The trends fly in contrast to the UDRP, as least in WIPO’s experience in 2021, where cases were soaring.

General counsel Nick Wenban-Smith said in a press release:

Despite the worldwide shift towards online activity during the pandemic, and WIPO disputes on the increase, we haven’t seen a parallel pick up in the number of .UK domain name disputes for the past two years, but instead are reporting a record low in Complaints filed since the DRS launched back in 2001. We hope this is a result of our continued efforts to make .UK a safe place to be online.

Nominet has some pretty strict takedown practices in place — it will suspend a domain if the police’s intellectual property crime unit tells it to, which could clearly have an impact on the need to employ the DRS.

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”.

UDRP cases soar at WIPO in 2021

The World Intellectual Property Organization has released statistics for cybersquatting cases in 2021, showing one of the biggest growth spurts in UDRP’s 22-year history.

Trademark owners filed 5,128 UDRP complaints last year, WIPO said, a 22% increase on 2020.

There have been almost 56,000 cases since 1999, covering over 100,000 domains names, it said.

The number of annual cases has been growing every year since 2013, its numbers show.

WIPO took a punt that the increase last year might be related to the ongoing coronavirus pandemic, but didn’t really attempt to back up that claim, saying in a release:

The accelerating growth in cybersquatting cases filed with the WIPO Center can be largely attributed to trademark owners reinforcing their online presence to offer authentic content and trusted sales outlets, with a greater number of people spending more time online, especially during the COVID-19 pandemic.

The number of domains hit by UDRP that include strings such as “covid” or “corona” or “vaccine” are pretty small, amounting to just a few dozen domains across all providers, searches show.

The growth does not necessarily mean the total number of UDRP cases has increased by a commensurate amount — some of it might be accounted for by WIPO winning market share from the five other ICANN-approved UDRP providers.

It also does not indicate an increase in cybersquatting. WIPO did not release stats on the number of cases that resulted in a domain name being transferred to the complaining trademark owner.

“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?

Verisign and PIR join new DNS abuse group

The domain name industry has just got its fourth (by my count) DNS abuse initiative, with plans for work on “trusted notifier” programs and Public Interest Registry and Verisign as members.

topDNS, which announced itself this week, is a project out of eco, the German internet industry association. It said its goals are:

the exchange of best practices, the standardisation of abuse reports, the development of a trusted notifier framework, and awareness campaigns towards policy makers, decision-makers and expert groups

eco’s Thomas Rickert told DI that members inside and outside the industry had asked for such an initiative to combat “the narrative that industry is not doing enough against an ever-increasing problem”.

He said there’s a “worrying trend” of the domain industry being increasingly seen as an easy bottleneck to get unwelcome content taken down, rather than going after the content or hosting provider.

“There is not an agreed-upon definition of what constitutes DNS abuse,” he said.

“There are groups interested in defining DNS abuse very broadly, because it’s more convenient for them I guess to go to a registrar or registry and ask for a domain takedown rather than trying to get content taken down with a hosting company,” he said.

topDNS has no plans to change the definition of “DNS abuse” that has already been broadly agreed upon by the legit end of the industry.

The DNS Abuse Framework, which was signed by 11 major registries and registrars (now, it’s up to 48 companies) in 2019 defines it as “malware, botnets, phishing, pharming, and spam (when it serves as a delivery mechanism for the other forms of DNS Abuse)”.

This is pretty much in line with their ICANN contractual obligations; ICANN itself shudders away from being seen as a content regulator.

The big asterisk next to “spam” perhaps delineates “domains” from “content”, but the Framework also recommends that registries and registrars should act against content when it comprises child sexual abuse material, illegal opioid sales, human trafficking, and “specific and credible” incitements to violence.

Rickert said the plan with topDNS is to help “operationalize” these definitions, providing the domain industry with things like best practice documents.

Of particular interest, and perhaps a point of friction with other parties in the ecosystem in future, is the plan to work on “the development of a trusted notifier framework”.

Trusted notifier systems are in place at a handful of gTLD and ccTLD registries already. They allow organizations — typically law enforcement or Big Content — a streamlined, structured path to get domains taken down when the content they lead to appears to be illegal.

The notifiers get a more reliable outcome, while the registries get some assurances that the notifiers won’t take the piss with overly broad or spammy takedown requests.

topDNS will work on templates for such arrangements, not on the arrangements themselves, Rickert said. Don’t expect the project to start endorsing certain notifiers.

Critics such as the Electronic Frontier Foundation find such programs bordering on censorship and therefore dangerous to free speech.

While the topDNS initiative only has six named members right now, it does have Verisign (.com and .net) and PIR (.org), which together look after about half of all extant domains across all TLDs. It also has CentralNic, a major registrar group and provider of back-end services for some of the largest new gTLDs.

“Verisign is pleased to support the new topDNS initiative, which will help bring together stakeholders with an interest in combating and mitigating DNS security threats,” a company spokesperson said.

Unlike CentralNic and PIR, Verisign is not currently one of the 48 signatories of the DNS Abuse Framework, but the spokesperson said topDNS is “largely consistent” with that effort.

Verisign has also expressed support for early-stage trusted notifier framework discussions being undertaken by ICANN’s registry and registrar stakeholder groups.

PIR also has its own separate project, the DNS Abuse Institute, which is working on similar stuff, along with some tools to support the paperwork.

DNSAI director Graeme Bunton said: “I see these efforts as complementary, not competing, and we are happy to support and participate in each of them.” He’s going to be on topDNS’s inaugural Advisory Council, he and Rickert said.

Rickert and Bunton both pointed out that topDNS is not going to be limited to DNS abuse issues alone — that’s simply the most pressing current matter.

Rickert said issues such as DNS over HTTP and blockchain naming systems could be of future interest.

ICANN hasn’t implemented a policy since 2016

It’s been over five years since ICANN last implemented a policy, and many of its ongoing projects are in limbo.

Beggars belief, doesn’t it?

The ongoing delays to new gTLD program policy and the push-back from ICANN on Whois policy recently got me thinking: when was the last time ICANN actually did anything in the policy arena apart from contemplate its own navel?

The Org’s raison d’être, or at least one of them, is to help the internet community build consensus policies about domain names and then implement them, but it turns out the last time it actually did that was in December 2016.

And the implementation projects that have come about since then are almost all frozen in states of uncertainty.

ICANN policies covering gTLD domains are usually initiated by the Generic Names Supporting Organizations. Sometimes, the ICANN board of directors asks the GNSO Council for a policy, but generally it’s a bottom-up, grass-roots process.

The GNSO Council kicks it off by starting a Policy Development Process, managed by working group stocked with volunteers from different and often divergent special interest groups.

After a few years of meetings and mailing list conversations, the working group produces a Final Report, which is submitted to the Council, and then the ICANN board, for approval. There may be one or more public comment periods along the way.

After the board gives the nod, the work is handed over to an Implementation Review Team, made up of ICANN staff and working group volunteers, which converts the policy into implementation, such as enforceable contract language.

The last time an IRT actually led to a GNSO policy coming into force, was on December 1, 2016. Two GNSO consensus policies became active that day, their IRTs having concluded earlier that year.

One was the Thick WHOIS Transition Policy, which was to force the .com, .net and .jobs registries to transition to a “thick” Whois model by February 2019.

This policy was never actually enforced, and may never be. The General Data Protection Regulation emerged, raising complex privacy questions, and the transition to thick Whois never happened. Verisign requested and obtain multiple deferrals and the board formally put the policy on hold in November 2019.

The other IRT to conclude that day was the Inter-Registrar Transfer Policy Part D, which tweaked the longstanding Transfer Dispute Resolution Policy and IRTP to streamline domain transfers.

That was the last time ICANN actually did anything in terms of enforceable, community-driven gTLD policy.

You may be thinking “So what? If the domain industry is ticking over nicely, who cares whether ICANN is making new policies or not?”, which would be a fair point.

But the ICANN community hasn’t stopped trying to make policy, its work just never seems to make the transition from recommendation to reality.

According to reports compiled by ICANN staff, there are 12 currently active PDP projects. Three are in the working group stage, five are awaiting board attention, one has just this month been approved by the board, and three are in the IRT phase.

Of the five PDPs awaiting board action, the average time these projects have been underway, counted since the start of the GNSO working group, is over 1,640 days (median: 2,191 days). That’s about four and a half years.

Counting since final policy approval by the GNSO Council, these five projects have been waiting an average of 825 days (median: 494 days) for final board action.

Of the five, two are considered “on hold”, meaning no board action is in sight. Two others are on a “revised schedule”. The one project considered “on schedule” was submitted to the board barely a month ago.

The three active projects that have made it past the board, as far as the IRT phase, have been there for an average of 1,770 days (median: 2,001 days), or almost five years, counted from the date of ICANN board approval.

So why the delays?

Five of the nine GNSO-completed PDPs, including all three at the IRT stage, relate to Whois policy, which was thrown into confusion by the introduction of the European Union’s introduction of the GDPR legislation in May 2018.

Two of them pre-date the introduction of GDPR in May 2018, and have been frozen by ICANN staff as a result of it, while three others came out of the Whois EPDP that was specifically designed to bring ICANN policy into line with GDPR.

All five appear to be intertwined and dependent on the outcome of the ICANN board’s consideration of the EPDP recommendations and the subsequent Operational Design Assessment.

As we’ve been reporting, these recommendations could take until 2028 to implement, by which time they’ll likely be obsolete, if indeed they get approved at all.

Unrelated to Whois, two PDPs relate to the protection of the names and acronyms of international governmental and non-governmental organizations (IGOs/INGOs).

Despite being almost 10 years old, these projects are on-hold because they ran into resistance from the Governmental Advisory Committee and ICANN board. A separate PDP has been created to try to untangle the problem that hopes to provide its final report to the board in June.

Finally, there’s the New gTLD Subsequent Procedures PDP, which is in its Operational Design Phase and is expected to come before the board early next year, some 2,500 days (almost seven years) after the PDP was initiated.

I’m not sure what conclusions to draw from all this, other than that ICANN has turned into a convoluted mess of bureaucracy and I thoroughly understand why some community volunteers believe their patience is being tested.

“GDPR is not my fault!” — ICANN fears reputational damage from Whois reform

Damned if we do, damned if we don’t.

That seems to an uncomfortable message emerging from ICANN’s ongoing discussions about SSAD, the proposed Standardized System for Access and Disclosure, which promises to bring some costly and potentially useless reform to the global Whois system.

ICANN’s board of directors and the GNSO Council met via Zoom last night to share their initial reactions to the ICANN staff’s SSAD Operational Design Assessment, which had been published just 48 hours earlier.

I think it’s fair to say that while there’s still some community enthusiasm for getting SSAD done in one form or another, there’s much more skepticism, accompanied by a fear that the whole sorry mess is going to make ICANN and its vaunted multistakeholder model look bad/worse.

Some say that implementing SSAD, which could take six more years and cost tens of millions of dollars, would harm ICANN’s reputation if, as seems quite possible, hardly anyone ends up using it. Others say the risk comes from pissing away years of building community consensus on a set of policy recommendations that ultimately don’t get implemented.

GNSO councillor Thomas Rickert said during yesterday’s conference call:

One risk at this stage that I think we need to discuss is the risk to the credibility of the functionality of the multi-stakeholder model. Because if we give up on the SSAD too soon, if we don’t come up with a way forward on how to operationalize it, then we will be seen as an organization that takes a few years to come up with policy recommendations that never get operationalized and that will certainly play into the hands of those who applaud the European Commission for coming up with ideas in NIS2, because obviously they see that the legislative process at the European and then at the national state level is still faster than ICANN coming up with policies.

NIS2 is a formative EU Directive that is likely to shake up the privacy-related legal landscape yet again, almost certainly before ICANN’s contractors even type the first line of SSAD code.

While agreeing with Rickert’s concerns, director Becky Burr put forward the opposing view:

The flip side of that is that we build it, we don’t have the volume to support it at a reasonable cost basis and it does not change the outcome of a request for access to the Whois data… We build it, with all its complexity and glory, no one uses it, no one’s happy with it and that puts pressure on the multi-stakeholder model. I’m not saying where I come out on this, but I feel very torn about both of those problems.

The ODA estimates the cost of building SSAD at up to $27 million, with the system not going live until 2027 or 2028. Ongoing annual operating costs, funded by fees collected from the people requesting private Whois data, could range from $14 million to $107 million, depending on how many people use it and how frequently.

These calculations are based on an estimated user base of 25,000 and three million, with annual queries of 100,000 and 12 million. The less use the system gets, the higher the per-query cost.

But some think the low end of these assumptions may still be too high, and that ultimately usage would be low enough to make the query fees so high that users will abandon the system.

Councillor Kurt Pritz said:

I think there’s a material risk that the costs are going to be substantially greater than what’s forecast and the payback and uptake is going to be substantially lower… I think there’s reputational risk to ICANN. We could build this very expensive tool and have little or no uptake, or we could build a tool that becomes obsolete before it becomes operational.

The low-end estimates of 25,000 users asking for 100,000 records may be “overly optimistic”, Pritz said, given that only 1,500 people are currently asking registrars for unredacted Whois records. Similarly, there are only 25,000 requests per year right now, some way off the 100,000 low-end ODA assumption, he said.

If SSAD doesn’t even hit its low-end usage targets, the fee for a single Whois query could be even larger than the $40 high-end ODA prediction, creating a vicious cycle in which usage drops further, further increasing fees.

SSAD doesn’t guarantee people requesting Whois data actually get it, and bypassing SSAD entirely and requesting private data directly from a registrar would still be an option.

There seems to be a consensus now that GDPR always requires registries and registrars to ultimately make the decision as to whether to release private data, and there’s nothing ICANN can do about it, whether with SSAD or anything else.

CEO Göran Marby jokingly said he’s thinking about getting a T-shirt printed that says “GDPR was not my fault”.

“The consequences of GDPR on the whole system is not something that ICANN can fix, that’s something for the legislative, European Commission and other ones to fix,” he said. “We can’t fix the law.”

One idea to rescue SSAD, which has been floated before and was raised again last night, is to cut away the accreditation component of the system, which Marby reckons accounts for about two thirds of the costs, and basically turn SSAD into a simplified, centralized “ticketing system” (ironically, that’s the term already used derisively to describe it) for handling data requests.

But the opposing view — that the accreditation component is actually the most important part of bringing Whois into GDPR compliance — was also put forward.

Last night’s Zoom call barely moved the conversation forward, perhaps not surprisingly given the limited amount of time both sides had to digest the ODA, but it seems there may be future conversations along the same lines.

ICANN’s board, which was in “listening mode” and therefore pretty quiet last night, is due to consider the SSAD recommendations, in light of the ODA, at some point in February.

I would be absolutely flabberghasted if they were approved in full. I think it’s far more likely that the policy will be thrown back to the GNSO for additional work to make it more palatable.