During CSG Open Working Session at ICANN79, Members from the ICANN Community were invited to an open meeting to share their experiences with Registration Data Request System (RDRS) from the Requestor side. As President of the Edgemoor Research Institute (ERI), I had the honor to present the keynote address and I am pleased to be able to provide you with ERI’s report of the meeting.

Background

Last November, ICANN launched a ticketing system for those interested in obtaining domain name registration data formerly known as the Whois System. Titled Registration Data Request Service (RDRS), the portal aims to direct requests for WHOIS data to participating registrars, who then decide whether or not to disclose the data. ICANN has positioned the service as a two-year test to gauge the marketplace demand level for domain name registration data. (“Registration Data”). Registrar participation is voluntary, and they are the sole decision makers as to whether Registration Data will be released according to applicable law. If enough demand is demonstrated, then the ICANN Board will consider whether to adopt more permanent solutions like the System for Standardized Access/Disclosure (SSAD) recommended by the Generic Name Supporting Organization (GNSO) Expedited Policy Development Process (EPDP).

In response to requests from ICANN org and the community, Requestors have been testing the service and documenting their results. The Registrars meet regularly within the Registrar Stakeholder Group (RrSG). The Requestors have been providing feedback within their various organizations, but there has not been a forum for Requestors from across all constituencies to share their experiences. Accordingly, in the spirit of working with the community to try to improve the system and thus the results of the test, ICANN’s Commercial Stakeholder Group (CSG) hosted an open working session to discuss requestor experiences and potential system improvements.

The following summarizes the findings, experiences, lessons learned, and recommendations for potential future steps. These are organized into three groups, disclosure related issues, usability of RDRS, and suggestions for follow-up.

We have attempted to reflect, as faithfully as possible, the contributions made by the participants from various stakeholder groups and ICANN.org. The opinions and conclusions included below are taken from the meeting and do not represent the opinion of the session organizers nor that of the report authors.

The recordings, transcriptions and chat of the event are available at: https://icann79.sched.com/event/1a1Ep/gnso-csg-membership-work-session

Disclosure related issues

1. Discrepancy Between Registrars in Disclosure rates: Requestors’ experiences demonstrate wide discrepancy in disclosure rates for similar requests between Registrars. This points to possible differences in disclosure policies. The disclosure rates could be improved if a) Requestors receive information about why a request was denied and not just that it was denied or partially denied through a check box system, b) Registrars work together to define disclosure criteria and policies, and c) Requestors and Registrars improve the understanding of each other needs through joint case studies.
2. Accuracy of Disclosed Registration Information: Requestors are frustrated when the data they receive turns out to be inaccurate. While gauging “demand” for data is the key metric for future decision making, accuracy is of key concern to Requestors. Inaccurate domain registration restricts the stated purpose and functions of the RDRS. All stakeholders of the RDRS have an interest in accurate registration data and should work together to develop remedies to reduce inaccurate registration data.
3. Specific types of requests seem to get automatically denied: Some Registrars seem to automatically deny disclosure for specific types of requests, for example:
   • Confidentiality Box: Requestors receive automatic response to take the request out of the RDRS system and use Registrar’s own complaint and disclosure procedures when they request non-disclosure of the inquiry to prevent offenders to get alerted and allowing them to cover their tracks. A special category for law enforcement requests was suggested.
   • TM related requests: Some Registrars automatically deny Trademark and Intellectual Property related requests or refer them to Registrar’s own complaint and disclosure procedures. The Registrars and IP/Trademark community need to develop through joint awareness and capacity building events a better understanding of their respective needs and roles. This would result in better disclosure policies of the Registrars and an increase in successful disclosure requests.
4. Takedown response to Request of Disclosure: Some Registrars deny the request for disclosure but take down the website of the requested domain. This might be well intentioned, but it enacts the remedy before the abuse of the DNS could be investigated. Many requests for disclosure are part of larger investigations and represent puzzle pieces to obtain a complete picture. Takedowns and consequent denial of disclosure ahead of investigation do not prevent and could have the unintended effect of covering up key details of DNS abuse. Generic responses such as: “There is no content being hosted” miss the point of the inquiry. Inquiries are part of an investigation into possible systematic abuse, and it would be helpful to know what are the substantive reasons that registrars are applying in terms of their disclosure decisions.
   
   Again, Registrars and Requestors need to develop a better understanding of another’s interests, needs and roles through joint awareness and capacity building events, resulting in better disclosure policies of the Registrars and more effective and successful requests by investigators in the Intellectual Property and Law Enforcement spaces.
5. Ensuring Legality: Registrars want to ensure that the disclosure of the data has a solid legal basis. They would like to see more specific information regarding the legal basis on which the requests are made. The risk of liability under data protection laws is high in the event the information requested is deemed improperly disclosed by the Registrar. For example, GDPR requires a balancing test before information is released. For the purposes of such a test, it is crucial to a) determine what legal reasons justify disclosure, and b) how specific requests for disclosure comply with the approved reasons. This requires an understanding and collaboration between Requestors and Registrars, but once accomplished, would raise the quality of requests, speed up response rates and improve response quality. The determination of the legality of requests does not have to take place inside the RDRS system but can be a parallel effort that supports and informs the RDRS system.
6. Evaluation Criteria: The RDRS system’s success seems to be evaluated from the point of view of the Registrars by the numbers of requests processed, and from the point of view of the Requestors in terms of the numbers of requests processed and the percentage rate of disclosures. From the Requestor’s point of view, the ability to Request without a substantial probability of response diminishes the utility of the RDRS. Registrars and Requestors need to develop common ground and establish joint understanding of what constitutes success. The goal should be aligned to align the understanding of RDRS success means. We need quantitative numbers and qualitative analysis of the request received and data disclosed.
7. Clear Reason for Non-disclosure: Requestors require a clear reason for non-disclosure. The “Partially Approved” and “Denied” responses are not sufficient from the Requestor point of view. Requestors would like to have a more in-depth explanation about why the data could not be disclosed. It is understood that the four existing disclosure categories are used to prevent the unintended or accidental disclosure of registration data. However, given the importance and impact of the disclosure categories, there should be a cross stakeholder review that results in better and more defined disclosure categories.
8. Definition: RDDS Request Successful or Not: There needs to be a common understanding of what constitutes a successful request. This is demonstrated when a domain is protected by a privacy/proxy agreement. In such a case the response to a disclosure request is that the information is publicly available through the Registrars own complaint and disclosure procedures. For the Registrar and the RDRS system that constitutes a successful request. For the Requestor it is a failure as they have not received the requested data. The Requestor is referred to the Registrar’s own complaint and disclosure procedures outside the RDRS system. Any response that is not a denial is currently counted as a success by the Registrar. If a disclosure request is only partially approved, it counts as a successful response even if the requestor does not receive the information as in one case the contracted party was unable to disclose the data due to applicable law.
9. Listing Types of Complaints: Some participants would find it helpful if the RDRS reports included the types of complaints, like phishing, IP, and others.
10. Registrar Disclosure Procedures vs. RDRS: Requestors that used to use direct contact methods and have switched to RDRS see a dramatic reduction of data disclosed. This results in a lack of RDRS system adoption by the Requestors because they will return to the Registrars’ individual complaint and disclosure procedures.

Usability of RDRS

1. Limited Data fields: The data field to justify the request is currently limited to 1000 characters. Requestors find it sometimes difficult to make and explain their case within this limit. Increasing the limit of 1000 characters is seen as a low hanging fruit and a problem that can be easily resolved.
2. Numbers of Clicks Required to Enter Information: On average of 35 clicks per request. Requestors feel that is too many, particularly if they are doing a bulk request.
3. Registrars Not Participating in the RDRS system: Requestors note the significant percentage of Registrars not participating in the RDRS system and would like to see initiatives by the Registrar Stakeholder Group, (RrSG) to convince nonparticipating Registrars to on-board. The Registrar Stakeholder Group has expressed interest in doing so.
4. Legal Certification: Requestors suggested providing the ability to attach POA/legal authority to the RDRS template. Now, it must be attached to the request every time it is submitted. Corporations do not have POA. They use signed certifications by the corporate secretary for in-house staff. Vendors such as law firms and investigation services must have legal powers. Many Requestors submitted simple notarized declarations, resulting in request denied. Corporations are advised to use Secretary’s Certificates stating legal authority as requestor on behalf of requests as POA are not feasible. Verizon has graciously provided a model. Please request at [email protected].
5. Sub-accounts: Some Requestors would find it helpful to have in the RDRS system sub-accounts within firms on behalf of clients.
6. Lack of Clarity - Response Regarding a Particular Domain Name: Requestors observed that some of the RDRS systems responses do not list the domain the response refers to. That causes confusion and should be an easy fix.
7. Ineligible Domains: Users of the RDRS are frustrated with the considerable number of requests that are ineligible domains such as ccTLDs, 3^rd level domains, historical domains, etc. The non-inclusion of such domains limits usefulness of the system. It is also observed that the RDRS is sometimes mistaken for a system to determine if a domain is already registered or not.
8. Reveal Rates: Requestors requested that the actual reveal rates should be added to RDRS reports.
9. Expectations for the RDRS system: It was noted that from the point of view of the Registrar many Requestors have unrealistic expectations towards the RDRS system. Requestors can request but not demand, and a response may be granted but is not guaranteed. From this point of view the effectiveness and reliability of the RDRS is limited and Requestors need to adjust their expectations towards the RDRS.
10. Bulk Bequests: Bulk requests are used to investigate infringements where a particular individual or organization is registering a lot of domain names. Up until this point Requestors really have not been able to do any of that type of due diligence and relied on doing guess work looking to see when domains are abused.
11. Requests taken out of RDRS System: Some Registrars made a point to demonstrate their openness to talk with Requestors to address their questions directly. This willingness to communicate is to be applauded. The question remains whether taking a sizable portion of requests out of the system impacts the overall effectiveness of the RDRS. Some Requestors that traditionally contacted the registries directly and then moved to the RDRS are now moving back to the direct approach. There is because the use of the RDRS system resulted in a dramatic reduction of disclosures.

Suggestions for Follow up

1. Registrars and Requestors: Registrars and Requestors need to develop a better understanding of another’s interests, needs and roles through joint awareness and capacity building events, resulting in transparent and consistent disclosure policies of the Registrars and more effective and successful requests by IP representatives. Besides other awareness and capacity building measures, joint case studies to identify problems and implement practical solutions should take place. The conversation revealed misalignment that should be corrected for the program to work well for both sides of the equation. Requestors can provide the name of non-participating Registrars to the RrSG to help recruiting efforts.
2. RDRS System Awareness and Promotion: There is a need to promote awareness about the RDRS system towards all stakeholders. One practical step would be to provide a direct link to the RDRS from the WHOIS. Organizations like INTA are promoting the system to its members and more should be done in that direction by other organizations.
3. Ongoing Evaluation: The goal of the session was to kick start a cross community conversation that focused on Requestors’ experiences. The is more to be done as more use the system and we have a greater field of responses to evaluation. It is also clear that the “clunky” user experience described on the Requestor side may be experienced on the Registrar side as well. The RDRS has created more front and back-end work for both sides of the request. If the system does not work equally well for all stakeholders, then the volunteer participation numbers will fall and corrupt the results of the 2-year project as it will not adequately reflect demand.

Acknowledgments

The CSG plans to continue its engagement in the RDRS program and anticipates more community events. Future events may be organized with other groups, particularly the RDRS Small Group with the assistance of interested stakeholders.

Thanks to all the presenters and participants, with special thanks to:

Business Constituency – Mason Cole, Chair
Intellectual Property Constituency – Lori Schulman, President
Internet Service Providers and Connection Providers, Philippe Fouquart, Chair
Edgemoor Research Institute – Rapporteur
Verizon Inc. – Patrick Flaherty
Meta Inc. – Margie Milam
Nelson Mullins – John McElwaine and Chris Casavale
Holland & Knight – Thomas Brooke
IIlumintel – Greg Aaron
Tracer – Faisal Shah
GAC Public Safety Working Group
ICANN Global Domains – Eleeza Agopian