I had intended to participate remotely in ICANN75, as I did for the past few ICANN conferences, but these plans were disrupted as I was called for jury duty and unable to attend most of the sessions. This blog post is thus gratefully dedicated to our RrSG Secretariat and the several RrSG members who provided notes and recaps, allowing me to catch up with the discussions and helping me to choose where to focus my time when watching panel recordings.
This ICANN75 policy update may not be quite as exciting or full of new work and fresh ideas as some past recaps, but important work is happening! If you have thoughts about the policy topics covered below, or other ICANN work, we’d love to hear from you.
Accuracy Scoping Team
The Registration Data Accuracy Scoping Team submitted their report (PDF) addressing Assignments 1 and 2 (of 4) and issuing Recommendations relating to how the accuracy of registration data can be measured; these Recommendations are grouped based on whether they require access to personal data or not. We wrote about this previously in our ICANN74 recap, so some of this will likely sound familiar to regular readers.
In the “no personal data” category, the most substantial Recommendation is for the GNSO Council to consider asking ICANN Org to survey registrars on the topic of accuracy obligation implementations and domain validation and verification rates. The Council should first find out what resources would be required to conduct the survey and how long it would take before deciding if it’s worth moving forward. Additionally, the Scoping Team Recommends that further work should be done with ICANN Org to consider dedicating one of the registrar audits to examining adherence to our accuracy-related obligations; the results of that exploration would also be shared with the Council for review and approval.
In the “yes personal data” category, the Recommendation is for any further work to be paused until ICANN Org determines whether they have a legal basis to process that personal data. To help with this determination, ICANN will undertake a Data Protection Impact Assessment and will submit a request for assistance to the European Data Protection Board.
Finally, the Scoping Team’s chair has stepped down, acknowledging that the work has not remained on schedule and that he was unable to help the group reach consensus; it is unclear who might step up to chair the Scoping Team. In our view, the current methods of validating and verifying registration data (which we wrote about here) are sufficient to ensure the data is accurate (and those who claim otherwise cannot provide evidence to that effect), so it’s probably not worth putting more time and resources into this project. We look forward to the Council’s determination of whether to proceed with the registrar survey and will of course continue to participate in the Scoping Team’s collaboration with ICANN Org on potentially dedicating a registrar audit to this topic.
Registration Data Policy (EPDP Phase 1 IRT)
It’s alive! The Registration Data Policy has been published for public comment! This represents the culmination of years of work to bring existing ICANN obligations into compliance with data privacy laws. We’re focusing our review on implementation; specifically: determining how we can best update our systems and processes for these modified obligations while minimizing the changes that our reseller partners will need to make. We will certainly be writing more on this topic and providing additional resources to help ease the transition, which will take place during an 18-month implementation period beginning after the public comments are reviewed and final policy is issued.
If you’d like to read the Policy, linked above, and submit your own comment, we highly encourage that. You can also watch ICANN’s public comment page to find our response, which will be submitted ahead of the October 31 deadline.
Overall (with some caveats that will be included in our public comment, stay tuned!) we are satisfied that the Policy faithfully implements the EPDP Phase 1 Recommendations (PDF), allowing us to minimize data processing and only share data with registries when there is a valid purpose, a legal basis exists, and a Data Processing Agreement (DPA) is in place. Relatedly, the DPA between ICANN and the Contracted Parties remains our final open concern. Entering into a DPA is a Phase 1 Recommendation as well as a legal obligation before sharing personal data, but we have several issues remaining on the negotiation table and the DPA remains incomplete at this time.
Whois Disclosure System (EPDP Phase 2)
Efforts to determine how to proceed (or whether to proceed at all) with a Standardized System for Access and Disclosure (SSAD) of non-public gTLD registration data continue, with ICANN Org presenting their Whois Disclosure System Design Paper (PDF) at ICANN75. This is what I refer to as a “mini-SSAD”: a request intake system that would allow ICANN to track the volume and nature of disclosure requests so that the Board can have more information on which to base a decision about the cost and value of building the full SSAD. Registrars would have to log into ICANN’s Naming Services Portal to indicate how they responded.
The Design Paper is appropriately clear that this mini-SSAD is not required by any Policy and so participation is optional for registrars (and not available at all for registries). Members of the GNSO small team working on this design (myself included) are generally in agreement that requests for domains registered with non-participating registrars should also be tracked, so that the volume information is as complete as can be. There is disagreement as to whether the system should be able to take in and store a fully-populated request for a non-participating registrar and some concern about the lack of an API at the time of launch, as some requestors or registrars may want to build their own interfaces right away.
The small team now needs to consider whether the design meets their expectations and, of course, whether this implementation will help fill the informational gaps needed to inform the Board and GNSO Council of the cost effectiveness of building the full SSAD. I’m still not sure that we need an SSAD, since registrars and registries must always also accept requests sent in to us directly, but I do see the value for requestors in having a single location to submit requests. ICANN is offering two webinars in early October, open to everyone and focusing on sharing the design, answering questions, and gauging interest in participation.
I look forward to seeing the mini-SSAD’s volume of use over the coming months. And, don’t forget that we publish our own disclosure request and response stats regularly; the most recent post is available here and includes a review of law enforcement agencies’ due process obligations.
DNS Abuse
We wrote in the ICANN74 update about abusetool.org; this has now been renamed to ACIDTool.com—the Abuse Contact IDentifier. This allows a user to look up the website and email hosting information about a domain name so that abuse reports can be sent to the provider best able to respond to the report.
The GNSO Council has convened a small team to consider what policy efforts (if any) would be useful to address DNS Abuse. This small team has identified a lifecycle of DNS Abuse (slide 11 in this PDF) and determined the correct party to take action at each stage of that lifecycle. Consequently, the small team has recommended (slide 13 at the previous link) that the GNSO Council request a Preliminary Issue Report on malicious registrations, which could lead to a future Policy Development Working Group.
I do hope that if a Working Group is convened on this topic the GNSO Council also considers how success would be measured; it is difficult for any group to meet a nebulous or unattainable goal.
Separately, Section 3.18 of the Registrar Accreditation Agreement requires registrars to “take reasonable and prompt steps to investigate and respond appropriately to any reports of abuse.” Opinions differ on whether this language provides a clear obligation to disrupt and mitigate DNS Abuse (we think it does); this dispute over the contract language’s meaning has been used by ICANN Compliance as a reason to not take action against registrars that ignore abuse reports. We are pleased to report that ICANN has now adopted a definition of DNS Abuse that aligns with the CPH’s understanding of DNS Abuse (PDF) and, with that context in mind, the RrSG is considering initiating discussions to amend that section of the contract, specifically adding text that requires registrars to take action on DNS Abuse, providing ICANN Compliance the tools it believes it needs to take enforcement action. If this process commences, the hope would be to have this work fully completed within the next six to twelve months. We look forward to participating in continued community effort to mitigate and prevent DNS Abuse.
Transfer Policy WG
Since the Phase 1a Initial Report was published before the last ICANN meeting, the PDP Working Group has been reviewing the feedback. Tucows is supportive of those Recommendations overall but we are aware of concerns around process changes removing the ability to cancel a transfer during the time between when it is initiated and when it is completed. In our research, we found that domain owners prioritize efficiency and speed for a transfer and we believe that the updated process meets these objectives without opening the door to domain hijacking or fraudulent transfer. That said, it’s important that the Working Group as a whole fully considers the input and proposed modifications to the proposed new process. We will continue to support that consideration within the Working Group’s regular meetings.
That’s all for this ICANN75 Policy Recap, but I do want to encourage readers to go back through the Schedule and take a look at any sessions that catch your attention. The Public Forum is always a great one to watch, and the session on “Internet Fragmentation, the DNS, and ICANN” is another one that’s worth reviewing. See you at ICANN76!