ICANN80 took place in Kigali, Rwanda, with four days of policy meetings and a beautiful conference center. There is an exciting piece of ICANN news to share before we dive into highlights from this series of policy-focused meetings: the search has concluded! Kurt Erik “Kurtis” Lindqvist has been selected as ICANN Board President and CEO. We look forward to getting to know him over the coming years, starting with ICANN81 in advance of his official December 2024 start date.
All things registration data
Several sessions focused on ICANN’s Registration Data Request Service (RDRS), including one planned and hosted by the Registrar Stakeholder Group (RrSG) Communications team (which I lead). In that session, we shared a dozen real disclosure requests (anonymized for privacy) with the aim of helping attendees understand the type of information requests often include—or lack—and how registrars arrive at their decisions.
Attendees overwhelmingly expressed appreciation not just for the content that was shared but also for the session format, which included breakout groups to discuss the examples. There were some real “aha moments” during the session that may not have happened in a more traditional presentation-style session. Some expressed concern that there was no “magic formula” for crafting a request that would always result in disclosure from all registrars; unfortunately, this is the nature of beast—each registrar has different local requirements it must adhere to. That said, giving a registrar as much pertinent information as possible allows the registrar to come to the best decision.
I also participated in a related session put on by the Commercial Stakeholder Group, where I shared high-level info about common gaps in disclosure requests from the registrar perspective, and listened to impressions from CSG members about their experiences with the RDRS process.
The ICANN Community has dedicated—and continues to dedicate—a lot of effort into improving the RDRS platform’s functionality and developing a shared understanding of what effective request and response processes look like. Hopefully this translates into an intuitive and reliable system for requestors that also meets the Board’s need for disclosure request volume data (as we discussed in our ICANN79 recap). Tucows is participating in the RDRS project while also, of course, continuing to use our TACO platform to manage and track registration data disclosures for the domains on our platform. If you haven’t yet read our most recent TACO stats update, I recommend checking it out!
The Registration Data Policy was also a topic of focus for registrars and registries: we talked about how we’ll coordinate technical and operational changes as well as potential timing for different phases of the implementation. August 2024 is approaching shockingly quickly (time really does speed up as I get older!), and as of that date, we can start pushing changes to our live platform, although we won’t be making any significant changes that early on in the year-long implementation buffer window. We want to be clear that the updates to this policy won’t spell major process changes for our reseller partners. Most likely, resellers will need to send us less data moving forward—data minimization in action!
Finally, the Privacy and Proxy Services Accreditation Issues group is starting up again. Right now this work is in the implementation phase, but they face a complex task. The policy recommendations made in 2015 were approved by the Board in 2016, but they don’t actually make sense anymore because of changes in data protection law (GDPR, I’m talking about you!). Plus, there are concerns that these recommendations conflict with other policy that has been made since 2016, including the Registration Data Policy. It’s a complicated situation because there is no defined process within the ICANN system to change a policy decision that hasn’t yet been implemented. There has, however, been broad acknowledgement that that’s exactly what needs to happen here. The Implementation Review Team (IRT) has reconvened but, as regular readers know, the IRT is not able to make policy decisions; they can only implement policy that was recommended by the Working Group and approved by the GNSO Council and ICANN Board. The IRT can’t just decide that some (or all) of the recommendations no longer make sense to implement, even if everyone agrees. Regardless, the first step is certainly for the IRT members to review both the policy recommendations as well as ICANN Staff’s analysis and be prepared to discuss them in early July. After that, I think we’ll see the entire Final Report sent back to the GNSO Council to determine next steps.
Work with ICANN Compliance
The Registrar Accreditation Agreement (RAA) and Registry Agreement (RA) Amendments for DNS Abuse came into full effect on April 5th, 2024. Now, it’s time to see how they will be enforced. To that end, the RrSG met with ICANN Contractual Compliance to get into the nitty-gritty details of what’s expected when a registrar is notified of alleged DNS Abuse on their system. We had a productive conversation about how we treat reports, how we think ICANN Contractual Compliance should treat reports, and how we can work together moving forward.
ICANN’s Contractual Compliance Team also shared an interesting statistic: 90% of incoming complaints they receive are not sent through to the domain’s registrar because ICANN determines the complaint is unfounded or invalid. Further, they often find that the complainant had not yet attempted to resolve the issue with the registrar directly before escalating to Contractual Compliance (which they definitely should do). We appreciate the work the ICANN Contractual Compliance team does to filter through these reports.
The ICANN Contractual Compliance team also spoke about how they will approach enforcement of the new Registration Data Policy. Typically, there is a single cutover date at which point a new policy is mandatory, but here we have a year-long transition period during which time registrars can comply with old Policy obligations, the new Registration Data Policy, or pieces of both. ICANN understands that registrars may take a phased approach to their updates and their auditing and compliance review processes will reflect this.
The Multistakeholder Model
Tucows is a long-standing dedicated supporter of the ICANN model of multistakeholder Internet governance. Although imperfect, we believe it’s the best way to ensure that everyone’s perspective is heard and no single voice takes precedence or dominates the conversation.
Lately, there’s been discussion about the multistakeholder model centered on a big question: Can this model be effective when participants are not obligated to disclose their interests or employers behind the scenes? We don’t think so. We talked about this in our ICANN76 recap where we looked at proposed changes put forward by the SOI Task Force; as of today, ICANN participants are asked to disclose the name of the individual or entity they represent when participating in the ICANN GNSO policy development process or they can state “private” if ethical or professional obligations prevent them from doing so. Under the proposed revision, they would instead provide a high-level description of the party they represent and whether this party is also actively participating in ICANN policy development work. While this greater level of detail might seem like a step forward, we worry that it would encourage participants to opt out of sharing who they’re working for, when they should instead disclose that information (perhaps with the consent of the party they represent). Ultimately, participants in the GNSO policy development process should have to disclose who they represent.
Because of these concerns, the proposed recommendations for the revised disclosure exemption did not receive the GNSO Council’s approval. The ICANN Board has now taken up the issue and is working on drafting an ethics policy; we’re tracking that work and are supportive of efforts to ensure transparency of interests when participating in the ICANN process.
We’re also participating in Internet governance discussions happening more broadly. The UN is working on its Global Digital Compact, and we’ve joined with other members of the DNS Industry in a Technical Community Coalition for Multistakeholderism, which published this statement and delivered a follow-up to the UN just last week. As indicated in that statement, we strongly believe that the voices of technical service providers are essential to any conversation about how the Internet should be managed, and we will continue to advocate for that wherever possible.
That concludes our ICANN80 Recap. If you have thoughts on these or other ICANN policy-related topics, please don’t hesitate to reach out!