INTA thanks ICANN for the opportunity to provide comments to the RDRS Policy Alignment Analysis. INTA is on record for having deep concerns about the efficacy of the RDRS system and we are pleased that the ICANN community is exercising serious efforts towards its improvement. INTA’s principal issue with RDRS is that it was not designed with both requestors and registrars needs in mind. For example, the interface is burdensome and confusing to someone who is not familiar with ICANN policy. Responses are mostly unsupported and unpredictable. While INTA proposed a rethink of the entire system, we respect the ICANN Board’s decision to continue the pilot. With regard to the suggested improvements, we submit the following on behalf of our members.

Mandatory Registrar Participation in RDRS - INTA strongly supports making participation mandatory for all ICANN-accredited registrars to ensure a reliable, centralized request system, mirroring assumptions in existing EPDP Phase 2 policies. Achieving this requires adopting a Consensus Policy, and INTA urges the GNSO Council to incorporate mandatory adoption into policy work, either by amending current recommendations or initiating a new expedited policy development process.

Inclusion of Privacy/Proxy Customer Data - A significant gap exists concerning the disclosure of underlying customer data for domains registered via privacy or proxy services, which currently are not obligated to participate or disclose data under RDRS. Since about 30% of domains use such services, this gap limits RDRS’s scope and effectiveness. INTA advocates for mandatory disclosure of underlying data when justified by well-founded IP rights violation claims, referencing the PPSAI Final Report Annex B framework, which remains valid under current regulations. INTA recommends reconvening the PPSAI Implementation Review Team to integrate these recommendations into existing policies and RDRS, with further policy development if needed.

Response Timeline and Service Level Agreements for Urgent Requests - Currently, the Registration Data Policy mandates responses to disclosure requests within 30 calendar days but lacks expedited timelines for urgent requests such as threats to life or critical infrastructure attacks. INTA and other stakeholders view this absence of binding rapid response timelines as a serious concern.

Accreditation and Authentication of Requestors - The RDRS pilot lacks formal accreditation or identity verification for requestors, which hinders automation, causes caution or delays among registrars, and creates inefficiencies for requestors who must repeatedly prove legitimacy. INTA supports introducing a streamlined accreditation system, starting with law enforcement, and moving then to IP and cybersecurity professionals to improve trust and efficiency while avoiding costly full implementations.

Standardization of Request Handling and Transparency of Responses - Operational inconsistencies during the RDRS pilot have led to varied and sometimes inadequate responses to requests, including vague refusals and misalignment with EPDP Phase 2 recommendations, such as denying requests solely based on intellectual property infringement claims. As a matter of efficacy, requestors must receive either the requested data or a clear, comprehensible rationale for refusal, as required by the Registration Data Policy, effective since August 2025. To be clear, the uniform template rationales currently contained within the RDRS are inadequate (for example, where the only rationale for rejection was, “More Info Required”) and should be revised to require clear, consistent, and actionable explanations of the basis for refusal and/or requirements for requestor responses. ICANN Compliance is obligated to enforce these obligations and INTA recommends enhancing implementation notes and adopting relevant EPDP Phase 2 recommendations to improve standardization and transparency.

API Integration and System Efficiency - INTA supports rapid development of Application Programming Interfaces (APIs) to allow automated request submission and response retrieval, facilitating integration with existing workflows and systems. This improvement does not require new consensus policy and can reduce transaction costs while encouraging participation. INTA recommends prioritizing API development as part of ongoing RDRS maintenance and evolution.

Optional Participation for ccTLDs - INTA supports this voluntary expansion and recognizes it cannot be mandated due to sovereign policies governing ccTLDs. INTA encourages continued dialogue and designing the RDRS successor system to accommodate ccTLD integration with minimal adjustments.

General Comments - The underlying notion that the sole intended purpose of the RDRS is to facilitate communication between requestors and registrars is fundamentally flawed. The system is more than about basic communication. It should be a sophisticated and efficient means for requestors to clearly communicate all relevant information to establish a legitimate basis for data disclosure from data controllers. It is essential that the system lawfully discloses the requested data or provides a clear, reasoned, and actionable explanation for refusal to disclose requested data when the registrar has determined that the privacy interests of the data subject outweigh all other legitimate interests. For those who view the RDRS merely as means for communication, the RDRS Usage Metrics serve as compelling evidence that it fails to facilitate even simple or clear communication. [See metrics infographic on Slide 36 of the Key Insights from the 2-year RDRS Pilot Program presented during ICANN prep week on October 14, 2025.] While some of the deficiencies of the RDRS may be addressed by the improvements currently under consideration in the Alignment Analysis, many deficiencies remain unaddressed. For example, mandatory registrar participation is intended to address the myriad requests where the “Domain [is] Not Supported.” And inclusion of privacy and proxy services is intended to address the numerous requests where the “Data [is] Publicly Available.” However, for the RDRS or any other system to be effective, these metrics should show only two or three paths (not dozens of them), namely either “Approved” or “Denied,” because privacy interests outweigh requestor interests. To achieve this, many additional improvements are required to cover all facets of the system.

As demonstrated in the reference above, all paths represent problems with the RDRS that need to be addresses as soon as possible. For example, rather than leaving requestors in the dark, INTA recommends that ICANN require disclosure in instances where “Domain was Transferred,” or where certain “Other Corrective Action Required” (such as when an abusive domain is disabled). Furthermore, the existence of a privacy or proxy service does not justify blanket rejection on the basis that “R[egistrar] Cannot Disclose Due to Law,” or a blanked subpoena requirement policy. Finally, if the RDRS request instructions and template are written in clear, plain English then there should be no rejections on the basis that “More Info [Info [is] Required.”   Indeed, certain registrars have shared that their own in-house data access systems yield a higher quality of disclosure requests. INTA suspects that the reason may be as simple as the plain English instructions for those in-house access systems, as distinct from the RDRS, which requires expertise in both ICANN policy and data privacy law to navigate. Improvements to the RDRS instructions and request template have been discussed throughout the pilot with continuous input from INTA members. However, INTA is unaware of any meaningful progress on implementation to date.

The attachment is our response in letter form with a few more details than space allows in this form. We urge that the entire attachment be reviewed for our complete answer to questions posed in the request for comment.

INTA strongly supports making RDRS participation mandatory for all ICANN-accredited registrars to ensure a centralized and reliable system, requiring a Consensus Policy for enforcement. INTA has provided detailed feedback on the Registration Data Request System (RDRS) pilot in previous meetings and submissions. We have emphasized the need for improvements to enhance its effectiveness and usability for both requestors and registrars, with a focus on mandatory participation, privacy data inclusion, and system efficiency. The manual RDRS web portal is cumbersome for high-volume users; INTA supports rapid development of APIs for automated request submission and response retrieval to reduce transaction costs and encourage participation. While ccTLDs are not mandated to participate, INTA supports voluntary ccTLD inclusion to unify request handling across TLDs, encouraging system design to accommodate this with minimal adjustments. INTA highlights that RDRS is more than a communication tool; it must enable lawful data disclosure or provide clear refusal reasons when privacy interests prevail. Usage metrics reveal RDRS fails to facilitate clear communication, with many problematic response paths such as “Domain Not Supported” or “Data Publicly Available,” which should be streamlined to primarily “Approved” or “Denied”. INTA urges improvements including clearer instructions, elimination of blanket rejections based on privacy services or subpoena requirements, and better implementation of plain English templates.