If we’ve known each other or worked together for any significant period of time, you know that I have a strong sense of FOMOW—fear of missing out on work. The hybrid-format ICANN74 meeting simultaneously eased and exacerbated those feelings. I was so glad to be able to participate in sessions remotely but found myself longing for the days when I’d run into colleagues in hallways or share a meaningful discussion over an impromptu meal. As with so many aspects of life In These Unprecedented Times, it was difficult to determine what made the most sense for my personal health and wellness, and attending online was certainly better than not participating at all. I appreciate that the option continues to remain available.

Right now, one theme that’s coming up repeatedly and in many different contexts is data-driven decisions: questions around what data is necessary, what data is available, and what decisions can be made with or in the absence of data. This was evident in the policy work at ICANN74 and can be seen in our recent ICANN’s SSAD ODA and TACO statistics blog posts. I’m gratified to help bring ideas and clarity to these discussions.

Registration Data Accuracy Scoping Team

I was surprised to realize that I haven’t yet blogged about the work of the Registration Data Accuracy Scoping Team, especially since I’m a participating member and it’s a significant area of focus for me! Scoping Teams are interestingly (and necessarily) different from Policy Development Working Groups. Their work happens at an earlier stage in the policy development process and, instead of creating policy recommendations, this Scoping Team exists to determine if there is a problem which should be addressed with policy.

The Registration Data Accuracy Scoping Team is charged with four tasks1 and is now preparing a report for the GNSO Council detailing outcomes for the first two. To summarize, the first task is to assess the measures that ICANN Compliance has available to ensure that registrars and registries meet contractual obligations for registration data accuracy. A foundational part of this assessment is finding a working definition of registration data accuracy for this Scoping Team to use. The second task is to recommend ways to measure the accuracy of registration data on a broad scale (rather than for specific domains).

The Scoping Team has had some challenges understanding ICANN Compliance’s work, despite an open channel of communication between the two groups. The greater challenge, however, is defining accuracy and measuring the current state of accuracy.

There have been several methods proposed to allow the Scoping Team to measure whether the current goals of Accuracy obligations are being met. Some necessitate actually reviewing many individual domain name contact records to see if the data is accurate, while others do not: this could be a survey of registrars to understand the results of their validation and verification processes (remember, we described how we do it in our most recent TACO blog), assessment of those same processes by a neutral third party, a review of the rate and type of accuracy complaints sent in to ICANN Compliance, or even dedicating ICANN’s next registrar audit to focusing on adherence to the data accuracy requirements and/or restarting ICANN’s Accuracy Reporting System.

There are, of course, challenges to consider with each of these proposed methods. Registrars and registries could volunteer rates of validation/verification vs. domain suspension, which will likely not be accepted as authoritative by other groups represented in this Scoping Team. A third party, such as ICANN, could perhaps evaluate the accuracy of registration data, but this would require them to actually process the data, which can’t be done without determining both a valid purpose and legal basis to do so in adherence with data protection laws. To that end, ICANN is working with the European Commission (see this PDF) to send a letter to the European Data Protection Board (EDPB) asking for input as to whether ICANN has a “legitimate interest” legal basis to process the data.

The Scoping Team is now trying to figure out what to do next: is it worthwhile to proceed with the voluntary registrar survey? Is there other work that can be done to evaluate accuracy levels without processing personal data? If not, is there data that can be gathered and reviewed without waiting for the EDPB’s response? We need data about accuracy if we are going to be able to evaluate the accuracy of data.

I look forward to continuing to work with this Scoping Team through issuing the report to the GNSO Council and beyond.

Transfer Policy Review Working Group

The Transfer Policy Review Working Group initially focused on the core aspects of transferring a domain from one registrar to another, which we covered in detail in our ICANN73 recap blog. The initial report for that phase of the work was just released for comment, and so the decisions we discussed in the previous blog are available for the entire Community to review and respond. The deadline for input is August 16.

The Working Group is now ready to proceed with the second phase of work: reviewing the Change of Registrant (CoR) process (also referred to as IRTP-C). This review begins by considering a claim from the Transfer Policy Review Scoping Team Report: the CoR process “does not achieve the stated goals” and “is not relevant in the current & future domain ownership system.” Can the Working Group confirm if this is indeed the case, and if so, why?

This speaks to the importance of data-driven decisions. The CoR policy addresses a perceived need (protecting against domain theft) by ensuring that the domain owner participates in ownership changes. In order to make an informed decision about modifying or even removing the CoR process, the group needs to figure out what data would feed into that decision and how to get that data. I’m excited to dig into this work!

The data we do have tells us that the current CoR process is the source of significant complaints and confusion on the part of registrants. With that in mind, I’d like to see us move to a simplified ownership update process, with the initial owner being notified of the change and no requirement to wait on their approval before completing it. This would improve the registrant’s experience while still ensuring they’re notified in case of an unexpected update.

Next steps for the SSAD ODA

We did a deep dive into the SSAD Operational Design Assessment (ODA) fairly recently, so I won’t do it again here, but the fate of the EPDP Phase 2 Recommendations was certainly a topic of discussion at ICANN74. After the GNSO Council reviewed the ODA, they convened a small team of Council members and former EPDP Phase 2 members (I participate on behalf of the Registrar Stakeholder Group) to consider the concerns outlined by the ICANN Board and provide feedback to the Council on some specific areas: (1) if the ODA correctly interpreted the Phase 2 Recommendations, (2) if the ODA left out any key aspects of those Recommendations, (3) the team’s view on the Board’s concerns (PDF here), (4) and ideas for how to address those concerns.

It’s important to keep in mind that this small team is not a Policy Development Working Group, so we can’t change the Recommendations. Instead, this group is trying to figure out what information would be useful to the Board as they make their decision about whether or not to approve the Recommendations to build an SSAD.

Going back to our theme of “what data do we need?”, one point of feedback from this small team is that the ODA is unclear about anticipated usage volume of the SSAD, yet that information is the key to estimating how much the system might cost to operate. To address this data gap, the small team has proposed creating a less complex pilot or proof of concept (if you speak Agile, think of it as a Minimum Viable Product). This pilot project would allow requestors to use a centralized portal to submit requests, but it wouldn’t include user accreditation or some other components of the full SSAD. Some members of the small team and of the broader ICANN Community feel that this would be similar enough to the full SSAD to produce useful volume data; others do not.

At the ICANN74 session on this topic, ICANN Org described (PDF) how they could set up this mini-SSAD (now called a “Whois Disclosure System”) using existing services such as the ticketing system already used by ICANN Compliance. However, proceeding with this project would pull resources from other important projects, so the fate of this work remains unclear.

DNS Abuse

Finally, we return to the topic of how to address DNS Abuse2. ICANN recently published a report indicating that DNS Abuse is on the decline, which Contracted Parties have been saying for some time, so we welcomed the acknowledgment of this good news by ICANN Org. The information-rich report represents a significant step in ICANN’s efforts to obtain data to feed into the planning and decision-making around how to continue to combat DNS Abuse.

DNS Abuse is, of course, still a problem—as it always will be—but as Identity Digital (formerly Donuts)’s Compliance and Policy Director Alan Woods pointed out during the CPH DNS Abuse Community Outreach session, the overall downward trend of DNS Abuse tells us that we’re moving in the right direction.

The success of current anti-abuse work seems to be objectively demonstrated through the DAAR reports, but, as GoDaddy’s Vice President Global Policy James Bladel alluded to in a recent tweet, not everyone agrees:

The CPH DNS Abuse Community Outreach garnered in-session accolades from both the Business Constituency and the Intellectual Property Constituency, who consistently drive us toward better solutions to the ever-changing problems of DNS Abuse. And, although I wasn’t present in the room, there were also constructive “hallway conversations” afterward, giving us some ideas about how to continue to work together, making the Internet better.

Among other things, the CPH DNS Abuse Community Outreach introduced the RrSG’s acidtool.com, a resource for anyone who wants to know who’s really behind a domain name. This online tool provides web hosting and email hosting information about a domain name so that reports that are not appropriately directed at a registrar can be sent to the right place. The DNS Abuse Institute also introduced its NetBeacon tool, which consolidates abuse reports from various sources to give Contracted Parties a central repository of information.

The Registrar and Registry DNS Abuse subteams are currently focusing on the difference between malicious registrations, those created specifically to carry out DNS Abuse, and compromised domains, where the domain owner is unaware that someone else has accessed and misused their registration.

With all that said, I’m excited to continue gathering data to help ground our decisions, both internally at Tucows and with the broader ICANN Community. We’ll keep you posted on policy work as things change and encourage our resellers and customers to be in touch about the issues that interest you!

1https://community.icann.org/display/AST, look for “The Charge to the Scoping Team”
2Defined as phishing, pharming, malware, botnets, and spam when used to deliver those other four types of abuse