Hamburg is beautiful this time of year: cold and rainy enough that ICANN78 attendees didn’t mind being cooped up inside for meetings, with clear warm stretches that allowed for a bit of sightseeing. If I’m being completely honest, my personal highlight was visiting the Miniature Wonderland, but I was also glad to take part in important, and very much full-sized, policy development work during another successful Annual General Meeting of the ICANN Community. 

ICANN’s Interim CEO Sally Costerton’s opening remarks focused on trust within the ICANN community as a foundational aspect of the multistakeholder model and the global Internet as a whole. “Trust fosters collaboration,” Sally reminded us, and it “encourages innovation and investment in digital technologies.” She’s entirely right: progress cannot be made—good policies cannot be developed—without mutual trust that everyone is working towards the same goal. 

With that in mind, here’s a recap of the important progress and policy decisions made during ICANN78.

DNS Abuse

We’ve been following the progress of the amendments to the Registrar Accreditation Agreement (RAA) and Base Registry Agreement since the negotiations began; indeed, one member of the Tucows Herd was on the negotiation team. Registrars and registries have until December 9, 2023, to vote to approve or reject the contract amendments, and we encourage you to make your voice heard before the deadline.  

Tucows is a strong supporter of these amendments. We know that most registrars and registries are already meeting the obligations that will become mandatory if the amendments pass:

  • Defining DNS Abuse as malware, botnets, phishing, pharming, and spam (when spam serves as a delivery mechanism for the other forms of DNS Abuse);
  • Allowing reports of DNS Abuse to be submitted via web forms instead of only by email; and
  • Taking action when a report of DNS Abuse is received: confirm that it was received, and then mitigate, stop, or otherwise disrupt the DNS Abuse.

By updating our collective RAA to include these obligations, registrars are showing the world that we’re committed to fighting DNS Abuse in ways that are thoughtful, appropriate, and impactful. This will, in turn, foster trust in the registrar and registry community and in ICANN’s multistakeholder model of Internet governance. If you’re an ICANN registrar and you’re unsure how to vote, please reach out to us.

gTLD Registration Data Policy and RDRS 

The Registration Data Policy work is now complete! After ICANN77, which took place in June 2023, there remained two open issues relating to this policy: 1) the timeframe in which registrars must respond to “Urgent” data disclosure requests and 2) the length of time given to registrars and registries to implement all changes necessary to comply with the new Policy. 

“Urgent” disclosure requests have now been removed from the Policy entirely. Instead, this topic will be separately considered by the GNSO Council and, perhaps, the ICANN Board. In part, this is because the Implementation Review Team could not reach agreement on how to appropriately and faithfully implement the Policy recommendation. But it’s also in part because the ICANN Board expressed concerns about the concept more broadly—if a request is truly so urgent that it meets the definition (“limited to circumstances that pose an imminent threat to life, of serious bodily injury, to critical infrastructure, or of child exploitation in cases where disclosure of the data is necessary in combatting or addressing this threat”), is an asynchronous process really the best way to handle obtaining the data? 

As we wrote in our recent TACO Stats post, we see “urgent” cases that meet this definition very rarely—usually law enforcement wants data relating to an IP address, not to a domain name. What’s often more useful is to have a conversation with the requestor about the situation and how we can help. Typically this involves explaining what information we do and do not have and how to find the hosting provider or forum owner, and facilitating that where we can.

The other open issue was implementation timing for the various changes: registrars and registries expressed the need for an 18-month implementation window, but there was some talk of an alternative approach. The 18-month plan starts with a 6-month “quiet period” during which each registrar and registry can coordinate with each other to prepare for the transition and begin the necessary updates to their own systems. Then there will be a 12-month period to implement the necessary system changes. At the end of this window, everyone needs to be following the new Policy. In the proposed alternative approach, registrars and registries could begin preparing immediately, but the actual implementation would have to be done during a small window of time in August 2025. We’re happy to say that ICANN Staff understood the concerns with that plan, and we’re now back to an 18-month rollout. 

As always, we’ll make the necessary updates in a way that minimizes work for our resellers, and we’ll provide plenty of notice. 

In other registration-data-related news, the pilot of ICANN’s centralized Registration Data Request Service (RDRS) is almost ready for requestors. Tucows has enrolled in the RDRS pilot to support the project and help ICANN gather community-wide request volume data (similar to what we already track), but we’ll continue to use our TACO system to grant and manage access to registration data. The data collected through the RDRS will help the ICANN Board decide whether a centralized system like this or, perhaps, a more complex version, is useful or needed.

Both the Registration Data Policy and the RDRS help foster trust in the broader Internet Community by promoting privacy by design and by default, and by helping people contact domain name registrants when necessary. 

New gTLD Program 

If you’re looking for a detailed review of the New gTLD Program you can check out our ICANN77 Recap. Here, we’ll just share this exciting piece of news: applications for creating new TLDs will start up in April 2026! ICANN has published an implementation plan (PDF) and we’re continuing to track this work while promoting our services as a backend registry operator and consultant for new gTLDs. If you or your clients are interested in a .yourbrand TLD, don’t hesitate to get in touch.

Transfer Policy 

The Transfer Policy Review PDP Working Group met at ICANN78 to continue their work on “ICANN-approved transfers,” which happens when a Registrar is acquired by another Registrar or when a Registrar is de-accredited and its domains are redelegated to another Registrar. The team is also considering a proposed change to the Transfer Dispute Resolution Policy (TDRP). Currently, disputes can only be initiated by a registrar in cases where the Transfer Policy is not followed; the question now on the table is whether registrants should also be able to initiate a dispute under the TDRP. 

It may instead be more useful to have a separate process (and perhaps a new policy) that registrants can use in cases where the Transfer Policy requirements were met (e.g. a valid transfer authorization code was provided to the gaining registrar) but the transfer itself was invalid (e.g. a bad actor accessed the domain owner’s account and changed the domain contact info so they could then transfer the domain away from its true owner). Updating the TDRP is likely out of scope for the current Transfer Policy Working Group, but the issue will be sent back to the GNSO Council for consideration of how best to proceed.

That’s everything for this ICANN78 Policy Roundup. Once again, we encourage all registrars to vote for the DNS Abuse Amendments to the RAA. See you at ICANN79!