ICANN86 took place from June 8–11 in Seville, where the sunny skies complemented the energy and optimism felt throughout the conference.

In this ICANN recap, we’ll check in on some familiar topics, including how registration data is handled, methods to mitigate DNS Abuse, and an exciting (to policy wonks, at least) update on the status of the updated Transfer Policy. As always, if you’re a Tucows OpenSRS reseller partner and want to share your thoughts on these or any other policy topics, please get in touch.

Registration Data

SSAD Supplemental Recommendations Team

When we checked in following ICANN85, the ICANN Board of Directors had determined not to adopt the EPDP Phase 2 Recommendations to build a Standardized System for Access/Disclosure of gTLD Registration Data (SSAD); the expected benefits and usage levels did not justify the high cost of building the complex system that was envisioned.

Instead, they’ve chartered a Supplemental Recommendations Team (SRT), made up of interested GNSO Council members and representatives from each ICANN Community group with experience on the topic. Tucows is one of the Registrar Stakeholder Group (RrSG) members participating on this SRT.

The SRT is tasked with reviewing each of the EPDP Phase 2 Recommendations in order to determine how to modify them. They’re considering the impact of their Supplemental Recommendations on the Global Public Interest, Human Rights, and existing ICANN Consensus Policies, while also considering how to achieve specific goals set out by the Board. These include (1) determining how registrars will participate in mechanisms for disclosure requests, (2) confirming how the SSAD can be used to request data for domains using registrar Privacy or Proxy services, (3) developing required response times for authenticated Urgent requests, and (4)  creating a requestor authentication mechanism for Urgent requests.

The SRT met for a full day just before ICANN86 kicked off and then held three 90-minute sessions during the conference. Much of this time was spent on requestor accreditation: with a specific set of requirements in place, the responding registrar or registry could be assured the requestor is who they claim to be. The ICANN Board of Directors intends to create a separate Input Group that will work on the technical side of this accreditation mechanism. This accreditation would alleviate the burden of requestor verification, which currently falls solely on registrars, allowing them to process requests more quickly, especially those marked as Urgent, where the stakes are often high and timeframes short.

The team also touched on request priority levels and categorization, consequences for abuse of the system, and a very high-level view of the process the registrar or registry should follow when addressing a request.

Sessions to watch:  SSAD SRT Meeting 1 of 3, 2 of 3, 3 of 3. Day 0 meeting is here, look for meeting recordings and then go to 07 June 2026.

PPSAI

The Privacy and Proxy Services Accreditation Issues (PPSAI) Implementation Review Team (IRT) met, but the session conflicted with three other also-important sessions, drawing lower attendance than usual as a result. The group reviewed the “pass-through” requirements of the Registrar Accreditation Agreement (RAA), which holds registrars responsible for all requirements under the RRA, including where resellers offer services under those registrars.

This matters for the provision of Privacy and Proxy services and how resellers should offer those services is a hotly-debated topic in the PPSAI: while we know that resellers must comply with the requirements of the RAA, some members of the IRT are concerned that a reseller may list themselves as the domain owner (acting as a Proxy) without escrowing their customer’s information. This creates the potential for that party to lose access to the domain, as there could be no way to prove ownership. It’s  a valid concern but it’s best addressed between the reseller and their customer, not by creating a complex and convoluted structure that will require additional accreditation for resellers, with related costs being paid to ICANN Org. It could also potentially affect the structure of the GNSO, as Contracted Parties are an entity within that structure and adding a new accredited and contracted party will require a review of ICANN’s bylaws.

Sessions to watch: PPSAI IRT Working Session

DNS Abuse

DNS Abuse Mitigation: Associated Domain Checks

This Working Group met four times in Seville and has drafted Recommendations responding to the first seven of their twelve Charter Questions. While we think that, in some ways, the outcome is overbroad—our experience has shown that instances of DNS Abuse don’t always need to trigger an Associated Domain Check—it’s a helpful step towards creating a baseline obligation for registrars, one that matches  the anti-Abuse practices many already have in place.

Sessions to watch: DNS Abuse ADC PDP 1 of 4, 2 of 4, 3 of 4, 4 of 4

Whois Verification

We wrote about the relationship between Whois Verification timing and DNS Abuse, sharing data about when domains are verified, when DNS Abuse happens, and whether we could meaningfully reduce DNS Abuse by only activating domains after verification (spoiler: no). We concluded that the minor decrease in DNS Abuse that would likely result from such a requirement doesn’t justify the effort to implement it; we should instead focus our efforts on avenues that the data shows are more likely to succeed in combatting DNS Abuse.

At ICANN86, the GNSO Council was asked to speak to the Governmental Advisory Committee (GAC) on the topic of Whois Verification timing and the Council asked RrSG members, including Tucows, to participate. We started by recapping when and how registration data is verified and then shared the same data points provided in the above-mentioned blog post.
Some GAC members agreed with our approach and were supportive of the GNSO Council’s ongoing efforts to prioritize DNS Abuse topics for policy work. Others remain strongly convinced that the proposed change to the verification process is a straightforward technical change, a flip of a switch. They seem unconcerned about balancing effort level against outcome here.

Ultimately, we’d like to see our own findings considered in a larger context and, to that end, we support EuroDNS’s proposal to use ICANN’s own resources for gathering better data: “We’re calling on OCTO to commission a new DNS abuse report, developed with input from registries, registrars, security researchers, and ideally hosting providers, platforms, and other relevant stakeholders, so the analysis reflects the entire abuse lifecycle.” Data-driven decisions are a crucial foundation to our work and we’d like to see objective and industry-wide data made available for consideration as we move forward.

We also support the NCSG’s recommendation to solidify registrant recourses and remedies when their domain is suspended, including chartering a PDP on the Registrant Benefits and Responsibilities.

Sessions to watch: GAC Discussion on Registration Data Issues

Other topics of note

Transfer Policy Review PDP

We’ve been tracking the Transfer Policy Review PDP since the start; the Working Group’s Recommendations were approved by the GNSO Council over a year ago and have since languished, pending approval by the ICANN Board of Directors. The delay prompted a letter to the Board, drafted by the Registrar Stakeholder Group and signed by all groups in the Generic Name Supporting Organization (GNSO), calling for improved transparency and communication, permitting the Community to understand what the Board is working on and when their reviews are expected to be completed.

The ICANN Board of Directors has now adopted the Transfer Policy Review PDP’s Recommendations. This is incredibly welcome news and means that ICANN Org can now initiate the Implementation Review Team (IRT) and move forward with translating those recommendations into updated Consensus Policy language. Over the coming months, we will participate in that IRT, working to ensure that the Recommendations are implemented faithfully. In the long term, we look forward to updating our platform to reflect those changes.

The result of this updated Policy will be a more secure and straightforward domain registrar transfer process, as well the removal of the Change of Registrant process, which has proven to be more of a burden than benefit to domain owners.

That concludes our ICANN86 recap. Policy work is moving along at a good pace and we’re pleased to be able to contribute both at the conference itself and through our day-to-day work intersessionally. As always, we welcome input from resellers and customers on these or any other DNS governance topics. We’ll see you at ICANN87!