The air-conditioned conference center balanced out Mumbai’s heat and humidity and, despite lower in-person attendance, ICANN85 was a productive meeting.

Tucows Registry Services was one of the official meeting sponsors, and we were happy to see many visitors stop to say hello and learn about our registry service offering. Perhaps most importantly, the squishy cows were out in force and were made available for attendees to take home (in pairs, of course)!

A pyramid of toy cows.

In this ICANN recap post, we’ll tackle the most talked-about topics of the meeting, looking at what the effects might be on resellers and domain owners. As always, if you’re a Tucows customer and want to share your feedback on these or any other policy topics, please get in touch.

A team photo.

DNS Abuse Mitigation: Associated Domain Checks

When we checked in before ICANN84, we noted that ICANN Org had published the Issue Report, an important step to scoping out a topic before a Working Group can be formed (in ICANN parlance, “chartered”). The Charter, which defines the scope of work for the Working Group, is now complete, and the Policy Development Process Working Group (PDP WG) held four sessions at ICANN85. To refresh your memory, this PDP is considering a new requirement for registrars: when they investigate an actionable report of DNS Abuse, they would also have to check if other associated domains are used for the same Abuse. This is something Tucows and many other registrars already do.

The very first session of ICANN85 provided space for the consideration of a Human Rights Impact Assessment (HRIA) for the Associated Domain Checks process. The presenters reviewed what an HRIA is and how it fits into the policy development process, giving attendees an opportunity to ask questions and discuss. The main takeaways were:

  1. Human rights, like privacy, should be ‘baked in’ to the Policy Development work: they should shape decisions from the start, not only considered as an assessment of recommendations that are already complete and unlikely to be changed.
  1. The PDP work must remain within scope. If the Working Group starts to consider online harms unrelated to DNS Abuse, the work will never end—and certainly not within the planned 18-month timeframe.

The Working Group met four times in Mumbai; the first two sessions focused on process and logistics, such as how often the group will meet and the timeline of their work. This included a target completion date—they’d like to publish the Initial Report by February 2027. That may sound far off, but it’s fairly ambitious for ICANN policy work.

The third session offered presentations from three registrars on how they currently perform Associated Domain Checks. This was interesting, even to those among us quite familiar with registrar operations. It demonstrated that registrars across different business models—wholesale, retail, corporate—may hold different information beyond the required registration data and have different processes already in place. It also highlighted that registrars with similar business models may still have different information available to them. The Working Group’s final session gave the group’s members time to start thinking about the questions in the Charter (see page 4) which will guide their work, focusing on what should trigger the requirement to investigate associated domains.

Finally, the Registrar Stakeholder Group (“RrSG”) held an interactive and engaging “CSI ICANN: DNS Abuse Investigators” session. Sarah Wyld, Tucows’ Head of Privacy and Policy and the RrSG’s Vice-Chair for Policy, presented example scenarios of confirmed DNS Abuse collected from several Registrars, including information about the associated domains. Attendees provided their perspectives and voted on what action should be taken on those associated domains.

Some important insights came out of this session: 

  • Determining whether DNS Abuse is happening and how best to respond is complicated and contextual.
  • Not every bad thing that happens online is DNS Abuse.
  • Registrars still need to evaluate each report carefully to assess the most appropriate response, ensuring that effects are proportionate and effective.

Tucows already performs associated domain checks as part of our standard Abuse response process, although the information available to us as a primarily reseller-based provider is different from what a retail registrar would have.

You might be thinking: “If registrars already have processes in place for associated domain checks, why do we need a PDP?” This was also a topic of discussion in Mumbai, and the short answer is: a PDP can formalize the good work that many of us already do and require registrars that aren’t yet checking associated domains to follow a set of standards that are reasonable, achievable, and effective.

At the same time, it’s important to us that the recommendations the Working Group arrives at are flexible enough for registrars of all business models and that they don’t adversely affect resellers. They also cannot disclose information about our anti-abuse processes that could enable bad actors to circumvent them. It’s a delicate balance, and we’re pleased to be a part of working towards reaching it.

Sessions to watch: CSI ICANN – DNS Abuse Investigators  NCSG Interim HRIA DNS Abuse PDP;  DNS Abuse Mitigation PDP WG Session 1, Session 2, Session 3, Session 4

Registration Data

RDRS & SSAD next steps

When we last talked about this topic, Tucows had just submitted a public comment on the RDRS Standing Committee’s Initial Report; the big question for ICANN85 was how the Board would decide to proceed: is a long-term system needed? And, if so, is it the SSAD? The RDRS? A hybrid of the two or something completely new?

To refresh your memory, the Standardized System for Access/Disclosure of gTLD Registration Data (SSAD) is a complex and mandatory-for-registrars request submission system that was recommended by the EPDP Phase 2 Working Group, which would cost somewhere between $14 million and $140 million USD to build; the Registration Data Request Service (RDRS) is a smaller test system built to gather request volume data to help pin down exactly what the SSAD would cost so that a decision can be made as to whether it’s worth the expense.

At ICANN85, two important things happened. First, the GNSO Council held a session focusing on the potential next steps for the SSAD. Attendees were reminded about the Supplemental Recommendation process, which would follow a decision from the ICANN Board to not adopt the EPDP Phase 2 Working Group’s Recommendations  to build an SSAD and instead send the recommendations back to Council for further work.

The focus of this GNSO Council session was what would happen next: who works on creating Supplemental Recommendations, and what would they entail? The Council expects to convene a Small Team to work on these Supplemental Recommendations, made up of interested Councillors as well as subject matter experts from ICANN Community groups, especially participants in the previous RDRS Standing Committee.

The second significant update on the RDRS/SSAD work is that, as anticipated, the ICANN Board determined not to adopt the EPDP Phase 2 Working Group’s Recommendations to build an SSAD. This confirms that we’ll take the path discussed by the GNSO Council to create Supplemental Recommendations that bring the SSAD recommendations in line with other relevant policy work and allow the Community to determine how to proceed.

We look forward to tracking the work and contributing to decisions on how to modify the SSAD recommendations in accordance with the RDRS Standing Committee’s input, ensuring that whatever comes out the other side is useful, financially sustainable, and appropriately respects data privacy rights for both domain owners and system users.

Urgent disclosure request timing

Tucows wrote about Urgent requests ahead of ICANN83 and posted our Public Comment on the draft timeline in late December 2025. In it, we noted that the 24-hour timeline with extremely limited exceptions is a source of significant concern for registrars and their resellers and offered questions for consideration regarding the potential mechanism to authenticate law enforcement users so they can submit these Urgent requests. Following ICANN Org’s publication of the Public Comment Report, the process has remained at a standstill, though it was a topic of discussion at ICANN85.

The big question at hand now is whether a mechanism to authenticate law enforcement users, currently being developed by law enforcement agencies, requires further ICANN policy work. This is hard to answer because there remain many open questions about how the authentication process would work and what the expectation is when a request is authenticated—is it informative, giving the registrar more information to consider? Or is it determinative, not to be questioned and only to be accepted?

The good news is we have some time to figure it out. While we are not happy with the timeline arrived at by the Implementation Review Team, we do accept their output; that’s just how the multistakeholder model works sometimes. Compromise means we don’t always get what we want. We think, and the GNSO Council seems to agree, that the timeline language, which went out for Public Comment, should now be published in the Registration Data Policy, as it was drafted to be.

We also think that the work to develop a law enforcement authentication mechanism should be brought into the ICANN process, perhaps not as a formal Policy Development Working Group, but as something more nimble that still includes all affected parties. Right now, it’s being completed by an ad hoc team of Governmental Advisory Committee members and a few others. Once this process and surrounding expectations are better understood, we can determine what kind of policy requirements remain.

Sessions to watch: GNSO Discussion on Next Steps for SSAD Recommendations; ICANN Board Meeting

PPSAI check-in

The Privacy and Proxy Services Accreditation Issues (PPSAI) Implementation Review Team (IRT) met for a working session focused on the potential requirements for providers of Whois privacy services and discussed references to resellers in the current documentation.

Registrars must already ensure that resellers comply with ICANN requirements (or the registrar must do it on their behalf). For this reason, we’re advocating against duplicating this pass-through language in the new Privacy Provider policy.

In addition, the manner that resellers are referred to in the current documentation would create contractual ambiguity, which we are pushing back against. Now, the ICANN Org team will update the draft Policy language for the IRT to review, starting with definitions and including an update to the visual diagram of requirements, which we look forward to seeing.

Sessions to watch: PPSAI IRT Working Session

Other Open topics

Transfer Policy

We continue to check in about the Transfer Policy at each ICANN meeting, since the Working Group’s Recommendations were submitted to the Board in early 2025. These Recommendations remain with the Board to adopt, and we expect that to be completed by the time ICANN86 comes around, hopefully with enough lead time that an IRT can be convened to begin at ICANN86 or shortly thereafter.

That covers the highlights of ICANN85. We hope this update shows why ICANN policy matters and why we travel around the world to advocate on behalf of resellers and domain owners. See you in Seville!