Facebook thinks ICANN is a bit rubbish

Facebook owner Meta came away from the recent ICANN 82 public meeting unimpressed and wondering why the community doesn’t actually seem to be doing much, according to the company’s representative.

Writing to ICANN’s CEO and chair last week, head of IP and DNS Mia Brickhouse praised ICANN’s organizational skills but said she was “concerned regarding the lack of tangible outcomes relative to the significant community investment of nearly one week in Seattle.”

“While there were pockets of progress, it was challenging to identify concrete policy-oriented outcomes that I would use to mark participation in the Seattle meeting as a productive success,” she said.

“Many participants I spoke with felt the experience was more focused on policy status updates and remaining entrenched in legacy positions, rather than making measurable progress,” she said.

Welcome to ICANN, Mia!

She goes on to criticize the amount of navel-gazing at the meeting and said the current review into ICANN’s meetings strategy should not only focus on cutting ICANN’s costs but also on making meetings produce results.

Meta’s pet issues are Whois and DNS abuse. Its social media sites get a tonne of phishing attacks using maliciously registered domains and the company is not above taking registrars to court if they fail to play along with its enforcement efforts.

The company is fairly influential in policy-making circles, and arguably may become increasingly so over the next few years, depending on how deeply Donald Trump can reach into Mark Zuckerberg’s trousers.

But the Brickhouse letter is just the latest critique of what I and other time-haggard ICANN observers have been banging on about for years — the “Do Nothing” ICANN. I first pointed out in January 2022 that ICANN hadn’t actually done anything in about five years, something ICANN acknowledged a few months later.

To be fair, the Org has actually started producing tangible output since then. The Registration Data Request System is, whatever its flaws, a thing that the ICANN community came up with and the ICANN Org delivered.

But RDRS, ICANN’s response to the General Data Protection Regulation, took longer to create and deploy than the GDRP itself. ICANN’s multistakeholder model was slower than the notoriously lumbering EU legislative process.

The next round of the new gTLD program is another deliverable that also seems to be hitting its deadlines ahead of a Q2 2026 launch. But it has still taken longer than NASA’s Apollo Program to get off the ground.

One of the most on-point things I’ve read this year came from GoDaddy policy veep James Bladel, who wrote in his board election candidacy statement that “ICANN must stop telling the world why its role is important and start showing clear examples of multistakeholder successes.”

While Bladel did not get elected, Brickhouse’s letter points to an exchange in Seattle between one current and one former ICANN director, in which both parties agreed that “the current process is not working”.

Michael Palage, a freelance consultant who served a term on the board two decades ago, took to the Public Forum mic to complain that ICANN and its contracted parties are increasingly turning to bilateral contract amendments to address issues of concern, rather that having the whole community come up with formal consensus policies.

Becky Burr, approaching the end of her nine-year directorship, concurred that the “policy development process is not efficient and it’s not working as it should”, but disagreed that bilateral deals were not appropriate for addressing pressing issues.

You’re got two people, both who’ve served on the ICANN board and have over half a century of ICANN experience between them, agreeing that the current multistakeholder policy-making model isn’t working.

I’m certain there are other recent examples of long-serving community members criticising the process that are not readily springing to mind.

Sadly, ICANN’s usual response to broad community concerns is to launch a consultation or working group or comment period or somesuch, which often adds to the bloat and drains already jaded volunteers’ available work hours.

I can’t see anything changing any time soon, but there is a public comment period on the meetings strategy still open here.

ICANN to kill off 60-day domain transfer lock

ICANN is set to kill off its unpopular 60-day transfer lock policy, following a vote at ICANN 82 in Seattle this week.

The GNSO Council yesterday voted to accept the final report of its Transfer Policy working group, a mammoth 163-page document that contains 47 recommendations affecting all areas of domain transfers.

The removal of the transfer lock is perhaps the biggest change to the 20-year-old policy for domain registrants.

Under the current policy, when you buy a domain name from another registrant or change your name, organization or email address, you trigger a lock that prevents you transferring your domain to another registrar for 60 days.

It was designed as an anti-fraud measure, stopping domain thieves bouncing their stolen names to sleazy registrars to avoid them being recovered by their victims.

But is has proved unpopular over the years with registrants that want to consolidate their portfolios under their preferred registrar and the new policy would remove the lock entirely.

It would also remove the requirement for both gaining and losing registrants (ie buyer and seller) to be notified when a change of registrant occurs, on the basis that notifications don’t provide much protection when the losing registrant’s email has already been compromised.

The whole process governing changes to registrant data is going to be spun out into a separate Change of Registrant Data Policy, because maybe it didn’t belong in the Transfer Policy in the first place.

The newly approved changes will also introduce two new locks that registrars currently may, but are not required to, impose — there’s going to be mandatory 720-hour (30-day) locks on domains that have just been created or just transferred in.

Any registrars that currently impose a longer lock will have to reduce it to 720 hours and any registrar that does not have such a lock will be required to implement one.

The GNSO says these month-long locks will help reduce credit card fraud and help comply with trademark complaints such as UDRP.

There are dozens of other changes coming that do not relate to locks.

For example, the list of reasons a registrar may deny a transfer has been updated to include a reference to DNS abuse, as currently defined in the ICANN registry and registrar contracts.

There are numerous changes of terminology, required notifications, and instructions for handling Transfer Authorization Codes, all of which registrars and registrars will have to implement if they want to stay compliant with their ICANN contracts.

There are also changes to bulk portfolio transfers, limiting registries to a charge of $50,000 for portfolios over 50,000 domains.

The changes would also incorporate an updated Bulk Transfer After Partial Portfolio Acquisition (BTAPPA) directly into the Transfer Policy, meaning registries no longer have to request it from ICANN via the Registry Services Evaluation Process.

The recommendations, unanimously approved by the GNSO Council yesterday, will now go to ICANN’s board of directors for final approval. The final updated Transfer Policy will then be written by an ICANN/GNSO team.

Registries and registrars will then presumably be given time to implement the policy before it becomes law and Compliance comes sniffing around for infractions. We’re talking about at least 18 months before the changes go live, I reckon.

If you have a high tolerance for boredom, the full list of recommendations can be read in this PDF.