- Gnso-rdrs-sc - lists.icann.org

REMINDER | Meeting Invitation | RDRS Standing Committee | Monday, 24 February 2025
by Terri Agnew Feb. 21, 2025

Feb. 21, 2025

Dear all, The next RDRS Standing Committee call is scheduled for Monday, 24 February 2025 at 17:30 UTC for 60 minutes. To join - Zoom Information: Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/92181477886?pwd=TlJHTU5E…> Passcode: Z@S07?t=v5 Audio only option: Webinar ID: 921 8147 7886 Passcode: 3121016458 International numbers available: https://icann.zoom.us/u/acS1yc2A1 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acS1yc2A1__;!!PtGJab4!9A…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send apologies to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> and the ICANN Community Anti-Harassment Policy<https://www.icann.org/resources/pages/community-anti-harassment-policy-2017…> * 2025 Wiki agenda pages: https://community.icann.org/x/JwFEFw * Check your time zone: https://tinyurl.com/48badwc6 ONLY for Members & Alternates * Please join via the above Zoom Webinar link and staff will promote you to panelist. * Please select “ Everyone” when posting to the chat for everyone to see your chat and so it’s captured in the recording. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands. Thank you. Kind regards, Devan Policy Team Supporting the GNSO

1 0

ICANN82 GNSO Policy Briefing and Policy Outlook Report
by Terri Agnew Feb. 20, 2025

Feb. 20, 2025

Dear All, On behalf of the GNSO Team, I am happy to report for ICANN82 the following are now available for download. * GNSO Policy Briefing: http://go.icann.org/gnsobriefing * Policy Outlook Report: https://go.icann.org/outlook82 Happy reading! With kind regards, Terri --- Terri Agnew Policy Team Supporting the GNSO Policy Operations Senior Specialist (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Skype ID: terri.agnew.icann Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

Proposed Agenda for RDRS SC Call 24 Feb 17:30 UTC
by Feodora Hamza Feb. 20, 2025

Feb. 20, 2025

Dear RDRS SC members, Please find below the proposed agenda for our next meeting. Proposed Agenda for RDRS SC Call 24 Feb 17:30 UTC 1. Welcome (10min) * Discussion on comment made by Steve Crocker reg. final findings report 2. Update on Chapter 1 (20min) * Flagged areas for improvement 3. Discussion on Chapter 2 (20min) 4. ICANN82 session update (7min) 5. AOB (3min) Kind regards, Feodora Hamza Policy Development Support Manager (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +32 496 30 24 15 Email: feodora.hamza(a)icann.org<mailto:feodora.hamza@icann.org> Website: www.icann.org<http://www.icann.org>

2 1

Re: The January RDRS Usage Metrics Report is Published
by Lisa Carter Feb. 19, 2025

Feb. 19, 2025

Hello Standing Committee Members, ICANN has published the January RDRS Metrics Usage Report: February 2025 (Reporting period: 1 January – 31 January 2025) [PDF] [CSV] [CSV 18] [CSV 19] Best, Lisa Carter Sr. Program Manager, Strategic Initiatives ICANN

1 0

2025-02-10 RDRS Standing Committee - Meeting #25
by Feodora Hamza Feb. 19, 2025

Feb. 19, 2025

Dear RDRS SC, Please see below the notes and action items from the last meeting. The next meeting is schedule for 24 February 2025 at 17:30 UTC. Kind regards, Feodora and Caitlin 2025-02-10 RDRS Standing Committee - Meeting #25<https://community.icann.org/pages/viewpage.action?pageId=390332717> Action Item: Owner Deadline Review Chapter One and mark any concerns and cannot live with areas. SC Members to highlight in the draft chapter or via list if there is an area of Chapter1 they believe requires further SC discussion. Flagged items will be added to the upcoming meeting agenda. All Members 18 February Review draft Chapter 2. Suggest what to keep, remove or modify. All Members 19 February Provide effectiveness ratings for implemented enhancements. Draft Chapter2 Table 1. All Members/Proposal Owners 19 February Add justification/rationale & risk analysis for proposed enhancements. Draft Chapter2 Table 3. All Members/Proposal Owners 19 February Add priority rating for proposed future enhancements from 1 to 10. 1 being high priority and 10 being lowest priority. Draft Chapter2 Table 3. All Members 19 February Documents to review: Draft Chapter 1: https://docs.google.com/document/d/1CBAHz7G2AmjOt7C68Rn_hFl5c9F83lz9/edit#h… Draft Chapter 2: https://docs.google.com/document/d/1oqXdMgsGltToV_JxDtubedfymvrmvoAH43kssxO… Agenda 1. Welcome * SC Chair opened the meeting and suggested discussing the comment Steve Crocker sent to list during the next meeting. 2. Updates from the ICANN Board * The ICANN Board acknowledges that the RDRS pilot was initially intended to be a two-year experiment. However, the Board believes that the primary insights have already been gathered, and extending the pilot may not yield significantly more useful information. * The Board does not intend to shut down the system but rather aims to refine and expand its scope based on the findings. * Key ICANN Board Considerations: · An Authentication Mechanism for verifying requestors seems necessary, with a current focus on law enforcement. · Registrar Participation: All ICANN-accredited registrars should participate in a fully functional system. · SC members noted that this could provide additional burden to Registrars. · Privacy/Proxy Services should be included in the RDRS system to ensure comprehensive data coverage. This would likely require additional policy work. · API Integration particularly for registrars and requesters, to improve efficiency. An API doesn’t require new policy but there is value in this enhancement and it's worth exploring that during the pilot period. · Voluntary Involvement of ccTLDs. · SC Members asked for ICANN Org experience in building RDRS should be included in the final report to inform further recommendations. ICANN is in the process of gathering that information. 3. Discussion on Chapter One (Trends and Metrics) * Clarification on Consensus: * The SC discussed whether the goal was to reach formal consensus or simply document key takeaways. Since this is not a PDP, Standing Committee discussions and observations, including areas of disagreement, will be noted in the report, where relevant. There will not be a formal consensus call. * SC members noted that these are not policy recommendations as described in the Bylaws, but that the RDRS SC will make recommendations to inform the GNSO Council as it prepares its dialogue with the ICANN Board on how to proceed with SSAD recommendations/RDRS. * There was broad agreement that some kind of generic agreement should apply to the Standing Committee’s recommendations to the GNSO Council (Chapter 4), not data interpretations (Chapter 1). * Suggestions to Modify Chapter One: * Recommendations should be moved to Chapter 3 or 4 (Recommendations) for clarity. * SC members were asked to mark any findings they cannot accept before finalizing Chapter One. * Sankey Graph Analysis: A key data point discussed was the large number of incomplete requests (~61%). Agreement that causality is unclear, and multiple reasons likely contribute and that language in paragraph will be updated. Action Items: * SC Members to review Chapter One and mark any areas they cannot accept/cannot live with by 18 February. * SC Members to highlight in the draft report or via list if there is an area of Chapter 1 they believe requires further SC discussion by Tuesday, 18 Feb. Flagged items will be added to the upcoming meeting agenda. 4. Discussion on Chapter Two (Technical Enhancements & Future System Design) * Structure of Chapter Two: * Implemented Enhancements: Includes the features already added to RDRS. * SC Members are requested to evaluate the effectiveness of the implemented enhancements in the final column of the table. (Did the enhancement have the intended effect?) * Pending Enhancements: Previously discussed but not yet implemented. * Future Enhancements: Proposals gathered from previous discussions/RDRS workbook. * SC members are to provide justification (goal/rationale) and identify risks/dependencies for each proposed enhancement. * SC Members are to provide a priority ranking from 1 to 10 for each proposal. 1 being high priority and 10 being lowest priority. * The Action Items/instructions are included in the document as comments. Action Items: * SC Members to evaluate the effectiveness of the implemented enhancements in the first table of draft Chapter 2. * SC Members to review the enhancement proposals and provide feedback, particularly in the “Effectiveness” and “Risks/Dependencies” columns. * SC Members are to provide a priority ranking from 1 to 10 for each proposal. 1 being high priority and 10 being lowest priority. 4.1. Broader Discussion on System Development & Future Vision * Should ICANN build on or outsource the final system? · Some suggested ICANN Org should determine the best technical approach. · Others, including Steve Crocker, emphasized that the system should not necessarily be built and controlled by ICANN but rather allow for multiple implementations to ensure flexibility. · Some SC members suggested interoperability between various implementations rather than a centralized system. · SC Chair noted that technical design should not be dictated by policy teams. Instead, the committee should define policy goals and let technical experts determine the best implementations. · SC members noted that the SC should prioritize their focus on what the system should do vs paying attention to who is going to build/run it. 5. AOB Feodora Hamza Policy Development Support Manager (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +32 496 30 24 15 Email: feodora.hamza(a)icann.org<mailto:feodora.hamza@icann.org> Website: www.icann.org<http://www.icann.org>

2 2

RDRS SC - kind Reminder on pending action items
by Feodora Hamza Feb. 18, 2025

Feb. 18, 2025

Sent on behalf of Sebastien Ducos Dear RDRS SC members, As we continue to progress with our work on the final findings report, I want to kindly remind everyone of the pending action items that need your attention before our next meeting. 1. SC Members to review Chapter One <https://urldefense.com/v3/__https:/docs.google.com/document/d/1CBAHz7G2AmjO…> and mark any areas they cannot accept/cannot live with by 18 February. SC Members to highlight in the draft report or via list if there is an area of Chapter 1 they believe requires further SC discussion by Tuesday, 18 Feb. Flagged items will be added to the upcoming meeting agenda. 1. SC members to review Chapter Two<https://urldefense.com/v3/__https:/docs.google.com/document/d/1oqXdMgsGltTo…> that focuses on proposed system enhancements by Wednesday 19 February. SC Members are kindly requested to evaluate the effectiveness of the implemented enhancements in the final column of table 1. (Did the enhancement have the intended effect?) SC members are kindly requestes to provide justification (goal/rationale) and identify risks/dependencies for each proposed enhancement in table 3 of the document. SC Members kindly asked to provide a priority ranking from 1 to 10 for each proposal. 1 being high priority and 10 being lowest priority. As discussed during our last call, Standing Committee discussions and observations, including areas of disagreement, will be noted in the report, where relevant. There will not be a formal consensus call and the report will not include policy recommendations as described in the ICANN Bylaws, but the RDRS SC will make recommendations to inform the GNSO Council as it prepares its dialogue with the ICANN Board on how to proceed with SSAD recommendations/RDRS. The recommendations from chapter 1 will be moved to Chapter 3 or 4 for clarity. Please let me know if you have any questions or require any clarifications. Thank you for your time and effort. Looking forward to your valuable input. Kind regards, Sebastien Ducos Chair - RDRS SC

1 0

Re: Strong negative view of RDRS
by Sebastien＠registry.godaddy Feb. 14, 2025

Feb. 14, 2025

Dear Steve, Thank you for your comments. It is not for me to decide what ends in the report or not, I’ll leave it to the Standing Committee, but rest assured that if these points are to appear in the final report, we will find room for them in the structure Staff proposed. This said, I feel I need to comment them from the point of view of someone who has been trying to guide this process since inception, 3 years ago now. Both SSAD and RDRS have been based on the key assumptions that: 1. The system had to be defined, implemented and operated by ICANN Org. No, at least certainly not in case of RDRS. I have relayed on several occasions, particularly since ICANN81, that the decision of going for an ICANN built and/or operated system remains an open question. It has been so from inception, the question of relying on ICANN.org for any development was posed, including at Board-level. The main reason for having ICANN.org developing this pilot, was because it was a pilot and opening an RFP to cater for it was deemed too large of an endeavour for this pilot. It’s been raised in our spreadsheet, it will appear as such in the final report. 2. The system must not be involved in any decisions regarding disclosure due to the perceived risk of massive GDPR fines. Yes, and may I note that no one (ICANN or other) has offered to share this responsibility, let alone to indemnify Registrars or any other future disclosing party for the risk incurred in disclosures that might be legally challenged and found unlawful. 3. The system had to be focused on just the contracted parties. This positioned ICANN as serving just the needs of the contracted parties instead of the full Internet community. No, the fact that we believe the next stage should include willing ccTLDs has been raised in our spreadsheet and will be included in the report. We concentrated today on contracted parties (or the Registrar side of the CPH) because they are the only one that have an agreement with ICANN which stipulates that they should handle disclosure requests, a contractual element ICANN considered as key in the absence of Policy to justify getting involved in the request process at all. In the absence of policy, the alternative was and remains, for each Registrar to go about it on their own. 4. For SSAD, the essential requirement was for identification of the requestor, and the estimate for building and operating such a system required massive expenditures. Yes, I concur at least for 50% of the cost. Staff is seeking cost evaluations internally for the RDRS (based on a 18 months of development and operations) which should help us better forecast what it may cost in the long run. In the view of many, each of these assumptions should be challenged. Far better solutions are possible if the functionality is provided in a distributed fashion and with a focus on greater clarity regarding which requests would and would not be honored and more efficient design to reduce costs and increase performance. The usage data that has been collected is a good predictor of the usage of the RDRS. The data does not provide any useful information about the underlying demand. The primary results of the RDRS experiment are twofold: 1. Re-examine the assumptions and potential solutions, i.e. start over with a holistic approach. 2. The RDRS, though deeply flawed, is providing some degree of useful service. Continue it indefinitely until a suitable replacement is available. I appreciate your conclusions. I believe we have consensus on your second point, to keep RDRS on until replaced by a more permanent solution. After years of work on this (starting with EPDP Phase 2) and 1,000s of volunteer hours spent I’ll let the Standing Committee decide if it wants to recommend to the GNSO to “start over with a holistic approach”. May I also personally note: The data, RDRS or any future system that proposes to facilitate the lawful disclosure of, is currently under the care of the Registrars who have been entrusted it by their Registrant clients, covered by their agreements with the said Registrants. It is being transmitted to Registries and Escrow Providers under ICANN contracts, which define each party’s responsibility over the said data. No system will change this fact/construction. Any system facilitating disclosure will need the cooperation of the data holders, as responsible Data Controllers, to operate. Unless and until the Controllership and inherent responsibilities are assigned to anyone else, working with the CPH in the case of gTLDs and the different ccTLD managers for cc’s is unavoidable. Before we were able to roll the RDRS pilot out, the Small Team, Staff and the RrSG in particular, spent months working with the Registrar community to educate and convince them that participating in RDRS was a good idea and would allow the Community to gain knowledge. I don’t see any successor system operating without their full cooperation. Kindly, Sebastien Ducos GoDaddy Registry | Senior Client Services Manager [signature_1238579664] +49 172 690 8418 Germany sebastien(a)registry.godaddy<mailto:sebastien@registry.godaddy> From: Steve Crocker via Gnso-rdrs-sc <gnso-rdrs-sc(a)icann.org> Date: Monday, 27 January 2025 at 3:14 pm To: gnso-rdrs-sc(a)icann.org <gnso-rdrs-sc(a)icann.org> Cc: GNSO-Secs <gnso-secs(a)icann.org> Subject: [Gnso-rdrs-sc] Strong negative view of RDRS Folks, I have added the following comment to the draft outline of the RDRS Final Report. Steve Crocker ============================================================ Both SSAD and RDRS have been based on the key assumptions that: 1. The system ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Folks, I have added the following comment to the draft outline of the RDRS Final Report. Steve Crocker ============================================================ Both SSAD and RDRS have been based on the key assumptions that: 1. The system had to be defined, implemented and operated by ICANN Org. 2. The system must not be involved in any decisions regarding disclosure due to the perceived risk of massive GDPR fines. 3. The system had to be focused on just the contracted parties. This positioned ICANN as serving just the needs of the contracted parties instead of the full Internet community. 4. For SSAD, the essential requirement was for identification of the requestor, and the estimate for building and operating such a system required massive expenditures. In the view of many, each of these assumptions should be challenged. Far better solutions are possible if the functionality is provided in a distributed fashion and with a focus on greater clarity regarding which requests would and would not be honored and more efficient design to reduce costs and increase performance. The usage data that has been collected is a good predictor of the usage of the RDRS. The data does not provide any useful information about the underlying demand. The primary results of the RDRS experiment are twofold: 1. Re-examine the assumptions and potential solutions, i.e. start over with a holistic approach. 2. The RDRS, though deeply flawed, is providing some degree of useful service. Continue it indefinitely until a suitable replacement is available. =========================================== The above are key points that MUST be accommodated in this final report. It is not clear the current outline provides a clear place for these points to be included. They must be included, they must be included in a way that gives them credence and balance against the apparent default plan to treat the RDRS as a success and a signal to continue toward the original SSAD design.

3 3

BBQ Group call tomorrow
by Steve Crocker Feb. 13, 2025

Feb. 13, 2025

Folks, We're meeting tomorrow, Friday, 14 Feb, at 1:00 p.m. EST, in my zoom room, https://zoom.us/j/3015264569. Please let me know you're coming. Thanks, Steve -- Sent by a Verified sender

1 0

RDRS Standing Committee
by ICANN Policy Calendar Feb. 12, 2025

Feb. 12, 2025

Meeting: RDRS Standing Committee Pattern: Biweekly on Mondays at 17:30 UTC for 60 minutes (24 March – 02 June 2025) To join - Zoom Information: Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/92181477886?pwd=TlJHTU5E…> Passcode: Z@S07?t=v5 Audio only option: Webinar ID: 921 8147 7886 Passcode: 3121016458 International numbers available: https://icann.zoom.us/u/acS1yc2A1 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acS1yc2A1__;!!PtGJab4!9A…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send apologies to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> and the ICANN Community Anti-Harassment Policy<https://www.icann.org/resources/pages/community-anti-harassment-policy-2017…> * 2025 Wiki agenda pages: https://community.icann.org/x/JwFEFw * Check your time zone (24 March 2025): https://tinyurl.com/mfhdznx9 ONLY for Members & Alternates * Please join via the above Zoom Webinar link and staff will promote you to panelist. * Please select “ Everyone” when posting to the chat for everyone to see your chat and so it’s captured in the recording. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. * Observers will not be able to use chat or raise hands.

1 0

Post call | RDRS Standing Committee | Monday, 10 February 2025
by Devan Reed Feb. 10, 2025

Feb. 10, 2025

Dear all, The recordings for the RDRS Standing Committee call held on Monday, 10 February 2025 can be found on the agenda wiki page <https://community.icann.org/x/LQFEFw> and the GNSO Master Calendar<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance (please let us know if your name has been left off the attendance list) * Audio recording * Zoom recording (including audio, visual, rough transcript, chat archive) * Presentation displayed during the meeting (if applicable) * Agenda and Notes/Action Items (if applicable) For additional information, you may consult the mailing list archives<https://urldefense.com/v3/__https:/lists.icann.org/hyperkitty/list/gnso-rdr…> and the main wiki page<https://community.icann.org/x/HgH8E>. Thank you! Kind regards, Devan Policy Team Supporting the GNSO

1 0