ICANN82 was hosted in Seattle, which is lovely in mid-March. The crisp Pacific Northwest coast offers beautiful views and Seattle has a whole “underground city”—it’s well worth a visit.
ICANN’s new CEO Kurtis Lindqvist participated throughout the week-long meeting. With his technical background and pragmatic approach, Kurtis offers more than 30 years of experience (and some memorable stories of navigating technical challenges). We anticipate that his technical expertise will be pivotal for the ICANN Community as Kurtis leads us through the interesting times ahead: the United Nations is working on their World Summit on the Information Society (WSIS) +20 review, assessing progress towards the goals they set out 20 years ago and determining whether to maintain their endorsement of the multistakeholder model of Internet Governance.
The alternative would be a multilateral system, which may sound good (it has “multi” in it!) but which actually means that governments would control how the Internet operates. This would lead to crucial stakeholders, including the technical community (that’s us), civil society, academia, and the private sector being shut out of the Internet Governance process. Kurtis affirmed his commitment to the multistakeholder model in his ICANN82 session with the Contracted Party House, and we trust that he will do the same in his interactions with governments and the United Nations.
Tucows strongly supports the multistakeholder model of Internet Governance and believes that the technical service providers and other stakeholders mentioned above have an important role to play and unique insights to bring to the table. As part of this commitment, Tucows is an active member of the Technical Community Coalition for Multistakeholderism (TCCM), which advocates for multistakeholder Internet Governance throughout this UN review process.
Our public support and advocacy for the multistakeholder model of Internet Governance also prompted Tucows’ participation in the CIRA Technical Community Summit, which took place the day before ICANN82. This event centered around a research project conducted by the Canadian Internet Registration Authority (CIRA) documenting the technical community’s “priorities and concerns for evolving and improving multistakeholder internet [sic] governance.”
Tucows’ Head of Policy and Privacy, Sarah Wyld, participated on a panel looking at challenges and pain points in multistakeholder Internet Governance, focusing on issues of inclusivity and transparency. It can be very difficult to participate in UN processes, as participation typically requires a direct invitation by a government; at ICANN anyone can simply attend meetings (online or in person) and participate. Where are the opportunities to provide input to the UN, the ITU, or the WSIS+20 process, and how do we prioritize them? How do we ensure technical voices are heard effectively? How do we track the impact of our input? One strategy that helps is banding together in groups like the TCCM, strengthening our individual voices through unified and broader messaging. We appreciate the work done by CIRA and the TCCM leadership in these areas.
Now, let’s jump into our ICANN Policy updates. The ICANN Board Seat 13 vote, mentioned in our ICANN81 recap, has concluded: the Contracted Party House (registrars and registries) selected Greg DiBiase (Amazon Registrar) as our Board representative.
Registration Data
Accuracy
Despite the lack of any articulable or documentable problem, registration data “accuracy” continues to be a significant topic of conversation in sessions throughout ICANN82.
The Registrar Accreditation Agreement (RAA) includes specific provisions to ensure both syntactical accuracy (all the fields are filled in correctly) and operational accuracy (the domain owner can be contacted at the phone number or email address they provided), as well as processes to follow if the data is inaccurate, which lead to domain suspension. There remain claims that registration data for most domains is inaccurate; this is, however, unsupported by data. Further, despite the clear requirements in the RAA and years of work within the Accuracy Scoping team, the ICANN Community has been unable to reach agreement on even the definition of accuracy for registration data.
All together, these areas of disconnect make it difficult to determine the next steps. Is the issue that some community members don’t understand the RRA requirements or the processes in place to ensure they are met? Or is it a fundamental disagreement about when data can be considered “accurate” and what the process should be to “verify” domain holders? And what’s the ultimate concern here? The case is often made that domains with inaccurate data are more likely to be used for abusive purposes. This intuition may indeed be true, but effective strategies are already in place to mitigate both inaccurate registration data and DNS Abuse. It seems, therefore, that the real motivator might be an unrealistic desire to preempt bad actions before they occur and to obtain registration data in circumstances that registrars do not agree warrants that disclosure.
Requiring validation of government-issued identification would severely curtail the free and open Internet by limiting the ability to register a domain name and introducing a host of security and privacy concerns with no confirmed benefit: as we said, the problem is unclear, which makes finding a solution hard. The Registrar Stakeholder Group has published a resource outlining their approach to registration data accuracy, which has more info on the topic of identity document verification.
In an attempt to further the policy work, the GNSO Council invited each Stakeholder Group and Advisory Committee to submit input on registration data accuracy issues. The Council will now review that input and consider next steps for the Accuracy Scoping Team which has been on hold since 2022.
Sessions to watch: CPH & NCSG Memberships Work Session; GNSO Council Meeting
Registration Data Request Service
We wrote a lot about the Registration Data Request Service (RDRS) in our most recent TACO Stats post. At ICANN82 the RDRS Scoping Team met to continue work on their report, which they hope to finalize before ICANN83 in June 2025. They also discussed whether and how the RDRS will continue to operate after they’ve submitted their report to the Board for review. The Board will use the Standing Committee’s input as a factor in their decision on whether ICANN should build a larger, permanent Standardized System for Access and Disclosure.
Sessions to watch: RDRS Standing Committee Work Session
Privacy and Proxy Services Accreditation Implementation Review Team (PPSAI)
After ICANN80, we thought the Final Report on the Privacy & Proxy Services Accreditation Issues Policy Development Process would be sent back to the GNSO Council to determine the best next steps; that still has not happened. The Implementation Review Team (IRT) is working on threshold questions that summarize concerns or unclear areas from the Final Report. These questions will be sent to the GNSO Council for response before next steps can be determined.
Sessions to watch: PPSAI IRT Working Session
Transfer Policy
This policy update has been near and dear to our cow-printed hearts for years and, although we didn’t get everything we advocated for (we still think the ‘fast transfer’ idea had merit), consensus means compromise and the end result will be an easier process for registrants, which maintains security and builds in potential for future improvements. The proposed policy updates that we wrote about last fall remained unchanged following the Public Comment period, and the Recommendations in the Working Group’s Final Report were approved by the GNSO Council at their ICANN82 meeting. The next step is for the ICANN Board to review and hopefully approve those Recommendations. Once they do, an Implementation Review Team will be formed to ensure that the updated Transfer Policy correctly and faithfully implements those Recommendations. We were honored to support the Working Group’s efforts, and a member of the Tucows “Herd” will participate in the IRT; we extend our sincere thanks to the members of the Working Group, and its Chair, Roger Carney (GoDaddy).
Sessions to watch: GNSO Council Meeting; CPH TechOps Working Session (2 of 2)
DNS Abuse
The Contracted Party House (CPH, made up of the Registrar Stakeholder Group and the Registries Stakeholder Group) and Commercial Stakeholder Group (CSG: Business Constituency and Intellectual Property Constituency) held a joint working session to review specific incidents of DNS Abuse: what was reported, what was the outcome, and why? A number of important things surfaced during this session:
- People confuse phishing (which is considered DNS Abuse and can be addressed by the registrar) with intellectual property infringement (not DNS Abuse);
- It can be challenging to know where to submit reports of DNS abuse; and
- It can be challenging to understand when it’s appropriate to submit a registration data disclosure request.
There was such active discussion that the group ran out of time to get through all the examples, which shows how valuable this kind of collaborative, open format is for participants.
The CPH has also published three new resources: how to submit Effective DNS Abuse Reports, a short-form Abuse Reporting Guide, and a Reporting Online Harm Flow Chart, which helps users determine where to submit complaints that are not DNS Abuse-related. These are intended to be “living documents,” which will be updated as needed and will, hopefully, prove helpful to those submitting reports of DNS Abuse.
The CPH is considering what policy work may be effective in further addressing DNS Abuse, brainstorming ideas that we expect will be presented more broadly at ICANN83.
Sessions to watch: CPH & CSG Work Session; CPH DNS Abuse Community Update; Developing Human Rights Impact Assessment (HRIA) Guidelines for DNS Abuse
Other areas of interest
This post is running long, so we’ll just share a few more highlights:
- How We Meet: Registrars find significant value in face-to-face meetings of the full ICANN Community. As ICANN considers updates to its meeting strategy and opens up Public Comments on the topic, we’ll advocate for changes that are based on data (how much money would it save?) and don’t diminish our ability to work effectively.
- Code of Conduct: The discussion about Statements of Interest that we wrote about after ICANN81 remains ongoing; the Public Comments raised concerns about the enforcement of the transparency obligations. Now, ICANN needs to update its draft Code of Conduct in light of those comments; the new draft will also be shared for comment before going to the Board for approval.
- Next round of gTLDs: The Subsequent Procedures (SubPro) Implementation Review Team (IRT) met several times over the week at ICANN82, to work through several topics of discussion, including updates to the base Registry Agreement and how to deal with string similarity. A related group, the Latin Script Diacritics PDP Working Group, held their first meeting at ICANN82. Diacritics are accents on letters that modify their sounds, like the “é” in café; in this context, they are considered to be entirely separate characters rather than variations of the same character. Once a gTLD has been delegated, there are limits on the ability to create other gTLDs with similar or variant characters: if .cafe exists, no one can get .café; the owner of .quebec can’t also own .québec, and so on. As a Canadian company, we’re particularly interested in the .québec situation, and we’ll continue to track this group’s work. If you want a better explanation, check out their Issue Report.
- Urgent Request Authentication: the EPDP on Registration Data Phase 1 IRT was not able to come to agreement on what the response turnaround time for Urgent Requests should be. Urgent Requests are defined as situations 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—and these situations absolutely merit a fast response. But there are a few factors that make it difficult to agree on a turnaround time:
- Nearly all requests marked as “Urgent” don’t meet the definition above; and
- Typically, “urgent” requests aren’t submitted by authenticated law enforcement agents
We provided some context about this in a previous post. The Governmental Advisory Committee (GAC) has offered to work on a method to authenticate law enforcement requestors, resolving that part of the difficulty with addressing this topic. This is a helpful step, but the issue remains that in most life-or-death cases registration data is not actually useful; what they really need is the IP address or other information that only the hosting company can provide. Nonetheless, we appreciate the work towards a Community solution and will support the policy work as it progresses.
That concludes our ICANN82 review and policy recap. We hope it’s useful and would love to hear your feedback on these topics.