The comments below address the topics raised in the RDRS Policy Alignment Analysis and follow the document’s section-by-section structure for clarity and alignment.

Section 3.1 – Voluntary Registrar Participation. The Analysis correctly identifies that voluntary participation leads to inconsistent outcomes, since some registrars respond to requests while others do not. This directly affects requestors who need data for operational or abuse-mitigation purposes. If the system is expected to evolve into a more stable model, registrar participation should not remain a purely operational choice; it should be treated as a policy matter to ensure coherence, minimum coverage, and predictability.

Section 3.2 – Privacy/Proxy Customer Data. Requests related to Privacy/Proxy services often fall outside the RDRS workflow, forcing requestors to use parallel processes that create delays and uncertainty, especially in sensitive situations. The future roadmap should explicitly integrate the PPSAI IRT work to avoid duplication and move toward a unified and coherent request-handling process.

Section 3.3 – Authentication. The Analysis correctly states that authentication does not guarantee disclosure. However, in practice many requestors interpret authentication as a form of pre-approval, leading to expectations that do not align with registrars’ legal and contractual disclosure obligations. Future operational guidance should clarify this distinction to prevent misunderstandings and improve system transparency.

Section 3.4 – Urgent Requests. In incidents such as active phishing, fraud, or attacks on critical infrastructure, the lack of defined response timelines has direct consequences for harm mitigation. Currently there are no clear SLAs or predictable escalation paths. Since the Registration Data Policy IRT is also addressing urgent requests, both efforts must be coordinated to avoid conflicting requirements or incompatible processes.

Section 3.5 – Technical Integration, UI Improvements, and API. Reliance on manual processes creates significant variability among registrars and affects response times, traceability, and overall consistency. Without a standardized API, each operator handles requests differently. Technical integration should be considered a fundamental component of the roadmap, not an optional enhancement, and must align with PPSAI, the Registration Data Policy, and the SSAD-related components to avoid a fragmented technical architecture.

Section 3.6 – Roles and Responsibilities. The Analysis points out that roles within the system remain insufficiently defined. Many requestors lack clarity regarding which entity is responsible for each stage of the process, what response timelines should be expected, or how to proceed when a registrar does not respond. These ambiguities should be resolved before expanding capabilities or increasing automation in the system.

Section 3.7 – IDN Variant Requests. The absence of guidance for requests involving IDN variant sets leads to confusion about whether one request should cover all variants or whether multiple requests must be submitted. This gap particularly affects requestors monitoring malicious or suspicious behavior. Guidance should be aligned with ongoing IDN policy work to ensure consistent handling across registrars.

Section 4 – Path Forward. The proposed path forward is a solid starting point but requires clearer prioritization. PPSAI implementation, the Registration Data Policy, and SSAD-related work are advancing in parallel without a unified sequence, increasing the risk of duplication or conflicting outcomes. ICANN should publish a consolidated roadmap that identifies dependencies among these efforts and establishes the sequence of decisions necessary for coherent progression.

Section 5 – Considerations for a Successor System. There is currently no public clarity regarding how a successor system to the RDRS should be defined. It is important for ICANN to articulate its expectations for the long-term direction of such a system. The RDRS has been useful as a pilot, but it should not transition into a permanent model by default. Any successor system should emerge through an open, community-driven policy process and reflect a unified, predictable, policy-based approach informed by lessons learned from the pilot.

Additional Analysis. The gaps identified across Sections 3.1 through 3.7 create an operational environment with inconsistent responses, limited predictability, and fragmented processes. Coordination between PPSAI, the Registration Data Policy, and SSAD-related efforts—together with a consolidated roadmap and clearer direction for a successor system—is essential for building a stable and reliable long-term model. Since the RDRS remains an extended pilot, this is an appropriate moment for ICANN to define expectations and next steps.

This comment provides individual observations aligned with Sections 3.1–3.7, 4, and 5 of the RDRS Policy Alignment Analysis, identifying operational and policy gaps, recommending coordination across PPSAI, Registration Data Policy, and SSAD efforts, and requesting clearer direction on the long-term successor system roadmap.