Dear RDRS SC, Please find below the high-level notes and Action Items from the two RDRS sessions at ICANN83. The next meeting is scheduled for 23 June at 17:30 UTC. Kind regards, Feodora RDRS SC ICANN83 Sessions June 9 and 10 June Action Items: * Support staff to update draft conclusions<https://docs.google.com/document/d/1NOhKGqMMSypLpEF5rucEb-_Z3-iPb5_q/edit> based on ICANN83 discussion. * SC members to review working documents<https://docs.google.com/document/d/1NOhKGqMMSypLpEF5rucEb-_Z3-iPb5_q/edit> and provide additional comments by June 23. 1. Welcome * SC Chair opened the meeting and gave a brief introduction on the work and background of the RDRS SC. The slides can be found here.<https://icann-community.atlassian.net/wiki/spaces/EOTSFGRD/pages/208142348/2...> 1. Working Session on Assignment 4 Discussion Summary: * EPDP Phase 2 - Recommendation 3: Criteria and Content of Requests · Proposal: To Recommend reviewing forms by a “focus group” with requesters/responders; perhaps form a Requester Group. · Some SC members noted to maintain standardized form but improve interface and documentation. * EPDP Phase 2 - Recommendation 4: Acknowledgement of Receipt and Relay · Acknowledged functionality works, but: · Not a full ticketing system. · Limited history tracking of request status changes (e.g., expedited to standard). · Suggestion to improve visibility/history of status changes. · Draft Conclusion: Functionality adequate but could benefit from enhancements. * EPDP Phase 2 -Recommendation 5: Response Requirements · Central Gateway Manager not incorporated into RDRS. · Limited explanation options (dropdown menu) may be insufficient. · Law enforcement noted some issues about being redirected away from RDRS. · Remove “auto-reject” from draft conclusion. · Explicitly note that some SSAD concepts (gateway manager) were not piloted. · Suggestion for requester-responder communication feature in RDRS. * EPDP Phase 2 - Recommendation 6: Priority Levels · Current Priority levels don’t “make sense” anymore. · Suggestion to list technical and policy prerequisites for urgent processing. · SC members noted for this recommendation to enumerate the features that would be needed to potentially handle urgent request. · SC member noted for authentication for groups other than law enforcement, LEA authentication should be prioritized, but there should be a lightweight authentication for other requestors. * EPDP Phase 2 - Recommendation 9: Automation · RDRS does not offer automation features. * EPDP Phase 2 - Recommendation 12: Disclosure Requirements · Concerns around registrars disclosing data beyond request scope. · Need for clarity in final recommendation language. · SC members noted need to look at the recommendation as a whole. * EPDP Phase 2 - Recommendation 17: Reporting Requirements · SC members noted the current RDRS are very helpful. · Some SC members noted for further metric improvements, especially around requester accountability. * EPDP Phase 2 - Recommendation 7 – Request Purpose Requirement · Request form requires requesters to identify the issue and purpose using a mandatory field and dropdown. · Some noted the GDPR-centric language. · Discussion acknowledged need for training and better user guidance. * EPDP Phase 2 - Recommendation 11 – Terms and Conditions · No further comment. * EPDP Phase 2 - Recommendation 13 – Query Policy · Concerns about assumptions equating high request volume with abuse. · Review the original Recommendation text as a whole. * EPDP Phase 2 - Recommendation 15 – Logging Requirements · RDRS logs certain data · No user-level logs currently · Differentiation of logging purposes (accountability, statistics, debugging, transparency) * EPDP Phase 2 - Recommendation 18 - Standing Committee · The current RDRS Standing Committee functions well but differs from the SSAD’s envisioned permanent review mechanism. · Partial alignment; recommendation should be retained with understanding it applies to future governance. * Other Discussion Points: · Participants see potential in RDRS but hesitant to invest further unless it's confirmed as permanent. · API development highlighted as critical to system usefulness and integration. · Standardized forms, improved interface, and better user feedback were named as other important system enhancements. · Discussion on whether RDRS will evolve into a final system or be replaced. * Timeline and Next Steps · Notes and updated draft conclusions from both sessions to be compiled. · July goal: Final review of full report by Standing Committee. · Strong emphasis placed on completing the report by July to maintain alignment with the 2-year pilot timeframe. 3. AOB