ICANN87 Policy Recap

As we recover from the time difference and workload of ICANN87, it’s time for a recap of what’s underway in the ICANN Policy space. It was a week of productive meetings where we made decisions about how to address policy gaps and discussed our community priorities—and how we decide what those priorities should be.

As always, if you’re a Tucows OpenSRS reseller and have thoughts on the topics below or any other areas of ICANN policy please get in touch. We’d love to hear from you!

Registration Data

SSAD Supplemental Recommendations Team

The Standardized System for Access and Disclosure (SSAD) Supplemental Recommendations Team (SRT) got off to a great start back at ICANN86 and now, as of ICANN87, they’ve just about wrapped up their work—this is shockingly quick in the ICANN policy space.

The SRT was tasked with reviewing the EPDP Phase 2 Recommendations for the SSAD and determining how to ensure that:

• all registrars participate in the SSAD

• there is a clear path to request underlying data for a domain using a registrar’s Privacy or Proxy service

• there is an appropriate response timeline for Urgent Requests for registration data disclosure, and

• there is a way to authenticate requestors so that they can make those Urgent Requests

The SSAD SRT has drafted Recommendations which meet these goals, and is almost ready to submit their Initial Report for Public Comment.

The SRT proposes an SSAD which offers a web interface as well as an API for registrars and requestors who want to connect directly to it. This provides an automated way for registrars to pull requests into their own systems, the lack of which was highlighted as a significant limitation by registrars participating in the voluntary RDRS data-gathering pilot project.

The SRT has also considered the request submission process in the context of a domain that uses a registrar’s Privacy or Proxy service. They’ve made sure that the path is clear for requestors and that, if a disclosure cannot be completed via the SSAD—for example, the registrar requires submission of a subpoena or court order before revealing customer data—this is clearly conveyed to the requestor within the SSAD.

Finally, the SRT has worked out a framework for requestor authentication conducted by third parties (not by ICANN) and confirmed that the Urgent Request timeline laid out in the Registration Data Policy should apply for those authenticated requestors. One important factor for this framework is that it be legally binding in some way—the authenticating body must be responsible for the authentications it completes to a degree that gives the registrar reasonable assurance that relying on the authentication as part of disclosing registration data is legally defensible. 

The Governmental Advisory Committee (GAC) has raised concerns about this. They've contended that some governments, and by extension their associated law enforcement agencies, cannot enter into contracts; without these agreements, the authentication process is unreliable—we're right back where we started. We’re working with the GAC team and SRT to draft compromise language that provides the necessary assurances without including unattainable obligations.

All in all, the speed and success of this Policy shows how efficiently ICANN work can be accomplished. This is in large part thanks to the SRT Chair, Marc Anderson (Verisign), who was part of the EPDP and RDRS teams and understands the background context as well as the specific concerns of each ICANN Community group represented on the SRT. We’ll continue to track this topic and participate in the SRT until it concludes and, of course, will submit our own Public Comment at the appropriate time.

Sessions to watch: SSAD SRT Session 1, Session 2, Session 3

PPSAI

The Privacy and Proxy Services Accreditation Issues (PPSAI) Implementation Review Team (IRT) continues their work, which technically began in 2016. When we checked in after ICANN86, we noted that there is complexity around who any potential Privacy/Proxy Accreditation program should apply to: is it for registrars that offer these services, for resellers who offer their registrar’s Privacy/Proxy service to their customers, for law firms that register domains to protect their clients from scrutiny, for people who register domains for their friends because they know more about domains? All of the above? 

The GNSO Council has confirmed that the last two are out of scope for the IRT but some groups within the ICANN Community want to gather up all these possible Privacy or Proxy provider types in the PPSAI net so that this reasonable privacy protection measure can be circumvented by law enforcement and other interested parties. We think that, regardless of the type of Privacy or Proxy provider, the potential accreditation program should apply to registrars and our affiliated businesses only; not to third parties that we don’t control.

The work continues, with the Public Comment period expected early in the new year.

Sessions to watch: PPSAI IRT Work Session

DNS Abuse

DNS Abuse Mitigation: Associated Domain Checks (ADC)

The DNS Abuse Associated Domain Checks (ADC) PDP Working Group met four times in Bali to review input from the Public Comments on their Initial Report and determine whether changes to their Recommendations would be appropriate. 

While the general operating principle is that already-discussed topics should only be revisited during the Public Comment review if new information or evidence has come to light, there were times when the conversation was certainly familiar to regular participants. Topics under discussion at ICANN87 included: 

• determining how to define a Compromised domain (situations where a third party gains access and uses a domain for Abuse, unbeknownst to the actual owner); these are out of scope for this Policy work

• clarifying language around registrar obligations when the same legal entity controls multiple registrar accreditations

• confirming what information is included in a “reasonable” investigation, and 

• clarifying expectations around ICANN enforcement of compliance with the Policy.

Some of the suggested changes from the Public Comments were accepted by the Working Group, while in other cases the group did not reach agreement and so the original language was retained. Once the revisions are complete, a revised Final Report will be issued and eventually submitted to the GNSO Council, followed by submission to the ICANN Board of Directors for their approval. After that the Implementation Review Team work can kick off to bring the Recommendations to life.

We’re generally satisfied with the PDP outcome, as the ADC process being formalized lines up nicely with our current business practices.

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

DNS Abuse Mitigation: Registrations "At Scale"

When the ADC PDP work that we outlined above was first initiated, it was one of about 20 potential areas for policy development documented in the DNS Abuse Mitigation Issues Report and considered by the GNSO Council. The next issue slated to be worked on is referred to as “domain registrations at scale” and its scope is still being determined.

The general idea is that there’s more DNS Abuse when lots of domains can be registered all at once, so we should restrict access to services that enable bulk registrations to ensure they aren't used for DNS Abuse. The difficulty is determining what exactly we mean by “lots of domains”—what is at scale, or bulk, or a batch? Is it ten domains? If it's ten, could it be five? Or should the limit be much higher? Is 100 domains too many to buy all at once? 

The GNSO Council has a charter drafting team exploring these questions right now, and Tucows is supporting the Registrar Stakeholder Group (“RrSG”) in providing input. We think that it makes more sense to monitor for patterns rather than specify a hard limit on bulk domain registrations, but putting that into Policy language for all to follow is complicated. We will continue to track this work and hope to participate in the PDP.

Session to watch: DNS Abuse and Human Rights, Plenary on DNS Abuse Next Steps

Registrant Recourse

With the first DNS Abuse PDP nearly complete and the second almost underway, the GNSO Council is considering what will come next after the planned work. The topic we and many others in the ICANN Community think should be selected next is recourse for domain owners who are affected by DNS Abuse mitigation actions.

If somebody's domain is suspended due to DNS Abuse, there should be a process through which they are informed about the suspension and can contact the registrar to dispute the decision. Alongside this there should be a requirement for the registrar to review new evidence in good faith—this would not require the registrar to reverse their decisions; rather, it would obligate them to consider new input on these decisions. We support this as an upcoming PDP topic because domain owners’ experience is important and is not sufficiently considered at ICANN. 

Sessions to watch: Plenary: The Gap in Registrant Recourse

Other ICANN Business

Prioritization of potential work

The GNSO Council ran a pilot prioritization project over the summer, asking each constituency group to score five potential ICANN Policy projects across five criteria— like community demand and level of complexity—and, ultimately, rank each one against each other. Overall the Council found this exercise useful, although it would have been helpful for the participating groups to have had a better understanding of each project's resource needs before trying to score it. 

The results: a review of the Transfer Dispute Resolution Policy (TDRP) was ranked as the top priority, while Expiration Policies and adjustments to the new gTLD delegation process came in at the bottom. We agree with this ranking. A review of the TDRP is appropriate, as the recent Transfer Policy Working Group recommended changes to the TDRP. With the new Transfer Policy recommendations themselves slated for Implementation and the Registrant Recourse PDP under consideration, the timing works out well.

Speaking of the new Transfer Policy recommendations, regular readers will recall that they were with the ICANN Board of Directors for approval from April 2025 until June 2026. At ICANN87 we received a very welcome update: the Implementation Review Team is slated to start in the third quarter of 2027. We look forward to seeing this project move forward and anticipate that a Tucows staff member will join the IRT. 

Sessions to watch: GNSO Council Work Session 1; Joint Session: ICANN Board and CPH

Data verification timing

Another topic on the ICANN87 agenda was the duration of time provided for domain owners to verify their registration data. The GAC considers the current 15-day period to be a significant gap in the fight against DNS Abuse, and they're advocating that ICANN should instead require verification to be complete before a domain can be activated (at which point associated services, like a domain or email would begin to work). 

We posted data on this subject in May 2026 and again following ICANN86, when we spoke with the GAC. We don't see the significant potential here to reduce DNS Abuse that the GAC sees. Perhaps more importantly, we believe that the GNSO Council’s prioritization processes, which we discussed earlier, should be followed when determining what work the Community takes on. The GNSO Council itself took a similar position at ICANN87, discussing how the GAC’s perspective on this issue fits into the current prioritization exercise and work plan.

The GAC has based much of their argument on the INFERMAL report but there are multiple ways to interpret the information in that report. In fact, the report's author was invited by the GAC to speak at a session in Bali, where he expressed that the report does not draw strong conclusions around the 15-day period and emphasized that data provided by registrars should be more thoroughly considered. Ultimately, we are hopeful that the ICANN OCTO team will pull together research across the industry, as discussed after ICANN86, and we remain supportive of the GNSO Council’s role in selecting and prioritizing policy work to be undertaken.

Sessions to watch: GNSO Council Work Session 2; GAC Discussion on WHOIS Registration Data Issues

New gTLDs

The final subject of note for this post is that Reveal Day for new gTLDs was 7 October 2026: we can now see which new strings were applied for! Now there is an adjustment period for applicants who applied for a second-choice or alternate "replacement" string, and then, in late November, we’ll get the revised list of all the applied-for gTLD strings. That triggers a review and objection period that lasts through March 2027, at which point there will be a process to set the order in which applications will be processed. ICANN has yet to announce when approved strings will be selected and successful applicants will be notified.

This concludes our ICANN87 policy recap. We hope this is useful and informative. Once again, if you are a Tucows partner or reseller, we’d love to hear your opinion on these or other ICANN topics. See you for ICANN88 in Lisbon!