The ICANN Community met for this year’s Annual General Meeting in Dublin, Ireland and, while the weather was a bit gray, the conversations and conference sessions sparked many bright ideas.

ICANN policy work isn’t always glamorous. Conference centers can blur together, and even the most meaningful topics can test your focus by the fifth meeting of the day. But this work remains integral to the basic functionality of the Internet. Good governance allows us to maintain a stable, secure, interoperable, and open global network—and that’s more important than it’s ever been. Tucows continues to work hard to represent the interests of our reseller partners, registrants, and all users of the free and open Internet by advocating for data-driven and useful policy.

We’ll start this recap by looking at some recently completed work, then move to in-progress and upcoming policy development, and finish off with a quick overview of a few other topics of interest.

Completed work

Registration Data Request Services (RDRS)

The RDRS pilot project was set up to help the GNSO Council and ICANN Board determine the best outcome for the EPDP Phase 2 Recommendations. The question before them is: Is it worth building a very expensive Standardized System for Access and Disclosure (SSAD)?

We don’t think it is.

This past August, the RDRS Standing Committee’s Initial Report was published for public comment, and the Committee met twice at ICANN84 to consider adjustments to the Report in response to the comments received.

Tucows’ public comment emphasized the importance of two items that were confirmed in the Standing Committee’s Report:

  • any long-term system should remain voluntary for registrars to participate in and
  • it should operate on a cost-recovery basis with fees paid by the system users (requestors of registration data) rather than funded out of fees registrars and registries pay to ICANN, which ultimately come from the fees paid by registrants

If the Council and Board decide that the RDRS should be developed into a permanent SSAD, we’d expect that the first update would be the implementation of a billing system.

While the Council and Board consider the RDRS outcomes and SSAD recommendations, the Board has also requested an Alignment Analysis examining the various policies relating to registration data in order to understand what policies exist and how they fit together and to consider what policy work still needs to happen if their decision is to move forward with a centralized disclosure request system.

There are lots of ideas floating around but it’s crucial that we follow the multistakeholder policy development process and base decisions on data. Everyone deserves to have a seat at the table and have their input considered in community-developed, Board-approved policy; all decisions need to be grounded in relevant and reliable information.

Tucows continues to protect the registration data we are entrusted with by ensuring that all disclosure requests are carefully considered. We weigh the requestor’s stated purpose against the data subject’s rights and require due process where relevant. You can read more about our thoughts on RDRS in this ICANN82 Tiered Access update post.

Sessions to watch: RDRS Standing Committee Work Session (1 of 4); RDRS Standing Committee Work Session (2 of 4)

Timeline for response to Urgent disclosure requests

While the fate of the RDRS is being decided, other important work is also underway: the EPDP Phase 1 Implementation Review team (IRT) is looking at how to implement the final pieces of Recommendation #18.

In our pre-ICANN83 TACO Stats blog, we closely covered this Recommendation, which determines the requirements for registration data disclosure requests. The work now is to finish requirements for the special timeline for “Urgent” requests. The finalized language was posted for Public Comment just before ICANN84, with a deadline in mid-December. It includes the definition of Urgent requests, the definition of Authenticated Requestors (those permitted to submit an Urgent request), and the timeline for response. We’ll get into the details when we write our public comment, but—spoiler alert—we’re not thrilled with the outcome, as our concerns were not resolved through the IRT’s work.

One major objection we have is their proposed 24-hour turnaround for registrars to respond to Urgent requests for data disclosure. Urgent requests happen in very limited circumstances but, even still, this requirement would put registrars at risk of non-compliance with ICANN obligations; registrars will no doubt frequently exceed this 24-hour timeframe if they insist—as they often must—upon due process.

Tucows continues to advocate for a solution that allows both prompt handling of the request and essential flexibility in how registrars respond. Truly Urgent situations should be prioritized but the registration data that our resellers and registrants entrust us with should be protected.

As we work to achieve a balance between these two objectives, it’s important to keep in mind that registration data has typically not been found necessary to resolve Urgent situations.

Sessions to watch: Joint Meeting: GAC & GNSO

Code of Conduct concerning Statements of Interest

Everyone who participates in the ICANN policy development process is required to post a Statement of Interest disclosing who they work for, where they are located, and any areas where they may have a conflict due to a material interest in the outcome of the policy process. Until recently, however, it was possible to put “private” instead of disclosing one’s employer.

The ICANN Board took up this important issue and published a draft revision to the Code; when we last checked in about this after ICANN82, the revision was being updated in response to the first round of public comments. The updated version went through the standard second public comment period, and the final version of the Code is now in effect.

As we said in our public comment: “The revised draft addresses the Community’s concerns and takes appropriate steps to ensure that transparency of interests is formally codified as part of the ICANN Community Ethics Policy.”

We are pleased to see the updated Code now in effect.

Work in progress

PPSAI

The Privacy & Proxy Services Accreditation Issues (PPSAI) Implementation Review Team continues to determine next steps for the Working Group’s Recommendations, which would govern the accreditation of Privacy and/or proxy service providers. This is complicated because those Recommendations are about 10 years old and, since then, policy work and relevant laws have changed the registration data disclosure landscape.

Tucows continues to participate in the Implementation Review Team and advocate for a lightweight and flexible outcome. You can read more about Privacy services and proxy registration in our pre-ICANN84 Tiered Access update.

Sessions to watch: GNSO Council Meeting (Part 1 of 2)

Upcoming work

DNS Abuse

Before a policy development (PDP) working group can be formed, the issue it will work on needs to be clearly understood and documented. This is accomplished by requesting that ICANN Org create an Issue Report that assesses relevant information. It’s posted for public comment and revised accordingly, ultimately allowing the GNSO Council to determine if policy work should be undertaken.

In the context of DNS Abuse, ICANN Org has published an Issue Report that examines a wide range of related topics, considers whether they’re best addressed through policy work or some other process, and suggests the order of priority for those topics. They released it for public comment in October 2025 and we are now waiting for the revised Final Issue Report.

Tucows submitted a comment on this Issue Report, where we express support both for the three high-priority topics they’ve recommended the Community tackle and for the approach of having an individual PDP for each.

The topics are:

  • A requirement to check associated domains when investigating an actionable report of DNS Abuse—something Tucows and many other registrars already do
  • Mandatory clauses in the RAA with clear obligations for how API users (including resellers) would address DNS Abuse
  • Mitigation of batch-registered domain names generated by a botnet algorithm

DNS Abuse PDPs were on the agenda at several sessions during ICANN84 and a lot of the discussion focused on how the work would be scoped. There are three topics selected to move forward but there is only one draft Charter for a two-topic PDP, with the third proposed to be addressed as best practices “outside the contractual requirements.”

We think all three topics should move forward as PDPs. This helps ensure that the final outcomes—whether best practices, guidance, or a new Consensus Policy—benefit from input from the full Community.

Tucows is actively participating in this discussion on behalf of the Registrar Stakeholder Group and will, as always, advocate for data-driven work that is likely to make a measurable impact on the problems we are attempting to solve.

Sessions to watch: GNSO: DNS Abuse Work Session; Joint Session: ICANN Board and CPH

Human Rights Impact Assessments

A new and exciting change has been made to the PDP process: Working Groups must now conduct a Human Rights Impact Assessment (HRIA) considering the effects of their Recommendations on people’s fundamental human rights.

Tucows supports this effort and would like to see it supplemented with a Data Protection Impact Assessment process that reviews the effects of PDP Recommendations on the privacy and security of domain owners’ Personal Data. We participated in a panel discussion on the Registration Data Request Service in this context and shared how we assess disclosure requests and the potential impact on the domain owner of having their Personal Data disclosed to a third party.

Sessions to watch: DNS Security Without Sacrificing Rights: HRIA on RDRS

Other areas of interest

FOSS Security in the DNS Ecosystem

Here are some technical insights from our cowleague, Bahar Partov, Security Engineering Manager at Tucows Domains.

The Security and Stability Advisory Committee (“SSAC”) held a session on its new report: “The Domain Name System Runs on Free and Open Source Software (FOSS).”

This report highlights the key security advantages of free and open source software: transparency enables rapid vulnerability fixes and diverse implementations prevent single points of failure.

The SSAC emphasized that security often depends on development processes and patching speed, rather than whether software is open or closed source. For operators, FOSS offers advantages by avoiding vendor lock-in while enabling innovation.

At Tucows, we conduct risk assessments and follow security policies to review the open-source software we use; we are pleased to have the SSAC report show that this is the right approach.

Session to watch: Joint meeting: GAC and SSAC

Underserved regions

The RrSG worked with the At-Large Advisory Committee (ALAC) to host a discussion on how to reduce barriers for businesses that want to be accredited as registrars but operate in regions of the world where limited resources or access make this challenging.

Barriers identified included the significant financial cost of ICANN accreditation—a legacy requirement that should now be re-evaluated—as well as the level of effort and related costs required for compliance with the RAA and ICANN Consensus Policies. The latter of these points, Tucows emphasized to ALAC, should be a lens through which ALAC views Policy updates, as the ALAC represents Internet users.

Tucows provides reseller services to businesses in some of those regions around the world, so we understand keenly how that’s not the same as direct registrar accreditation. We also support resellers that become directly-accredited over time.

It’s important for Internet users around the world to have choices in who they do business with and that includes having local providers available to them. Tucows is proud to support resellers and our hosted registrar customers in that effort and was pleased to see this important matter brought to the ICANN forum. We look forward to helping ICANN make the changes they agreed were important and feasible and continuing to support the global Internet.

Session to watch: At-Large Plenary 2: Increasing capacity in underserved regions: registries and registrars

Registration data accuracy

It wouldn’t be an ICANN blog if we didn’t mention accuracy! If you’re someone who prefers to watch a video or listen to a podcast rather than reading an article, you’re in luck—our blog post “Requiring registrants to show ID is a Bad Idea” was presented at ICANN84, with robust discussion following.

Sessions to watch: Accuracy: Can We Have Anonymity and a Secure Internet?

That’s all for this ICANN84 policy recap! We hope it shows how ICANN policy decisions affect domain owners and resellers and the value Tucows brings to our reseller partners by continuing to participate in the ICANN policy process. We look forward to continuing that important work!