+1 Sarah and Farzaneh. I don't recall ever walking through the SSAD Recommendations as a group and deciding whether or not they are fit for purpose and I don't think that was part of our assignment. I do think the RDRS is a great experiment and we continue to learn more as it continues in the marketplace. Best, Paul ________________________________ From: farzaneh badii via Gnso-rdrs-sc <gnso-rdrs-sc@icann.org> Sent: Tuesday, April 22, 2025 3:20 PM To: Sarah Wyld <swyld@tucows.com> Cc: gnso-rdrs-sc@icann.org <gnso-rdrs-sc@icann.org> Subject: [Gnso-rdrs-sc] Re: 2025-04-21 RDRS Standing Committee - Meeting #29 I agree with Sarah. My impression of RDRS is that we should treat it as an experiment that can contribute to making better policies regarding disclosure. Farzaneh On Tue, Apr 22, 2025 at 3:30 PM Sarah Wyld via Gnso-rdrs-sc <gnso-rdrs-sc@icann.org<mailto:gnso-rdrs-sc@icann.org>> wrote: Hello all, Thanks for the notes. The very final point surprised me:
A significant part of the SCs work is proposing a path – it seems what the Committee is coalescing on is that there is a need for a system, and there is a need for further policy work in this area. The SSAD recs, as written, however, are not fit for purpose, and new policy work is needed. This should be made clear in Chapter 4 what the SC thinks the GNSO Council should consider doing.
While some members of the SC believe that the SSAD recs are not fit for purpose, and that further policy work towards a mandatory system is required, this is not the view of the entire SC and I don't think it's correct to say that the SC is coalescing on this understanding. Assignment #4 is "Suggestions to the Council for a proposed recommendation(s) to the ICANN Board in relation to the consideration of the SSAD recommendations." I think the most appropriate recommendation for us to make to the Council would be to take the RDRS metrics as authoritative data with which to update the Operational Design Assessment and inform the Board's decision, and we should let the Board decide what to do with the EPDP Phase 2 Recommendations in light of this data. Thank you, Sarah Wyld, CIPP/E Pronouns: she/they Head, Policy & Privacy Tucows #MakingTheInternetBetter swyld@tucows.com<mailto:swyld@tucows.com> Responses to this email are processed according to the Tucows Privacy Policy<https://www.tucows.com/privacy> On 2025-04-22 1:57 p.m., Feodora Hamza via Gnso-rdrs-sc wrote: Dear RDRS SC, Please see below the notes and action items from the last meeting. The next meeting is currently scheduled for 28 April at 17:30 UTC. Kind regards, Feodora and Caitlin 2025-04-21 RDRS Standing Committee - Meeting #29<https://icann-community.atlassian.net/wiki/spaces/EOTSFGRD/pages/115684781/2...> Action Items: 1. Support Staff to provide a draft of Chapter 4 (Standing Committee’s Recommendations to the GNSO Council). 2. RDRS SC will now be focusing on Chapter 4, but RDRS SC asked to please ensure you have reviewed the text of Chapter 2<https://docs.google.com/document/d/1oqXdMgsGltToV_JxDtubedfymvrmvoAH43kssxOT...> and 3<https://docs.google.com/document/d/1c2Nm5s1Q-4jrAqWvsurH-k6BhpyanGIW/edit#he...> and provided comments. Documents: * Chapter 1-3: * 1https://docs.google.com/document/d/1CBAHz7G2AmjOt7C68Rn_hFl5c9F83lz9/edit * 2https://docs.google.com/document/d/1oqXdMgsGltToV_JxDtubedfymvrmvoAH43kssxOT... * 3https://docs.google.com/document/d/1c2Nm5s1Q-4jrAqWvsurH-k6BhpyanGIW/edit Agenda 1. Welcome * Update on Chapter 2 and 3 • There have been no further comments received on Chapter 2<https://docs.google.com/document/d/1oqXdMgsGltToV_JxDtubedfymvrmvoAH43kssxOT...> and Chapter 3<https://docs.google.com/document/d/1c2Nm5s1Q-4jrAqWvsurH-k6BhpyanGIW/edit#he...> • Support Staff has updated the text based on earlier comments received Action Item: RDRS SC will now be focusing on Chapter 4, but RDRS SC asked to please ensure you have reviewed the text of Chapter 2<https://docs.google.com/document/d/1oqXdMgsGltToV_JxDtubedfymvrmvoAH43kssxOT...> and 3<https://docs.google.com/document/d/1c2Nm5s1Q-4jrAqWvsurH-k6BhpyanGIW/edit#he...> and provided comments. 1. Update from RDRS doodle poll • Based on poll results, we will be moving to weekly 60-minute meetings • Meetings will continue to be on Monday 17:30 UTC. • Based on feedback, we will not be meeting the week of 5 May due to member conflicts from the CP Summit. 1. Discussion on Chapter 4 • Chapter 4 is the crux of the Standing Committee’s assignment as this section provides the recommendations the Standing Committee will be making the GNSO Council. • ICANN Org presented rough overview of potential recommendations to GNSO Council based on review and feedback from Chapter 1 -3. • Disclaimers: • Support Staff worked with RDRS Leadership to provide rough drafts of recommendations that we thought we heard during the group’s work • This text/slides presented were for discussion purposes and can be edited later. • It’s important to remember that the recommendations the group makes should represent what the group largely agrees to or can achieve consensus on. • The aims was to show the potential recommendation ideas to get initial feedback from RDRS, and once the group provides initial input, Support Staff will take this input and incorporate it into draft text that the Committee can review. • There are not capital “r” Recommendations, but rather, lowercase “r” recommendations to the Council, as these are not policy recommendations. • Potential Recommendations and Group’s reactions • Maintain RDRS while additional policy and implementation work is outstanding • Suggest changing this to maintain RDRS until a successor system is in place • Consider treating SSAD recs with flexibility rather than strictly adhering to the recommendations as one package • Discomfort with the text as currently worded, as could result in cherry picking which recommendations to keep or modify and which not to keep or modify, which amounts to policy work. • Instead of saying “treat with flexibility,” the SC may identify which recommendations were implemented in RDRS and which were not and make some further observations on that the GNSO could potentially send to a working group to work on. • It may not have to be a new PDP. • Consider additional policy work on key system enhancements • Privacy/Proxy disclosure • RDRS links to RDAP • Making RDRS mandatory • The recommendation should clearly state the GNSO Council should consider additional policy work • P/P should be included in the discussion of the successor system (in whatever form that takes), but important to note that there is currently an IRT working on P/P accreditation. • Regarding making RDRS mandatory, what does this mean? Does it mean registrars must participate in this as a stopgap measure prior to the successor system, or do we mean the successor system should be mandatory? • Consider additional implementation work on key system enhancements • API • Authentication Mechanism • Optional ccTLD participation • The API should be RDAP-based • Update from PSWG on authentication – there are currently discussions ongoing regarding a short-term and long-term solution. The short-term idea is to provide unique domain names for known law enforcement agencies to ICANN to include in RDRS so that if someone were to make an RDRS request and the email address they're using that a response would be sent to matches with a known law enforcement agency's domain, that data point could also be shared with the registrar, so they can use that in their balancing test and their disclosure decisions. • NCSG to consider this point • No other objections • Question whether it makes sense to add these bullets (like API) to the existing RDRS or if we want to apply these recommendations to a successor system • Not the Committee’s place to tell Org how to implement, but it would be helpful to know what they intend to do, i.e., start from scratch or add on to RDRS so that we can word the recommendations appropriately. • Implementation in this context means technical work on RDRS, not the work of a traditional IRT • A significant part of the SCs work is proposing a path – it seems what the Committee is coalescing on is that there is a need for a system, and there is a need for further policy work in this area. The SSAD recs, as written, however, are not fit for purpose, and new policy work is needed. This should be made clear in Chapter 4 what the SC thinks the GNSO Council should consider doing. 1. 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@icann.org<mailto:feodora.hamza@icann.org> Website: www.icann.org<http://www.icann.org/> _______________________________________________ Gnso-rdrs-sc mailing list -- gnso-rdrs-sc@icann.org<mailto:gnso-rdrs-sc@icann.org> To unsubscribe send an email to gnso-rdrs-sc-leave@icann.org<mailto:gnso-rdrs-sc-leave@icann.org> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ Gnso-rdrs-sc mailing list -- gnso-rdrs-sc@icann.org<mailto:gnso-rdrs-sc@icann.org> To unsubscribe send an email to gnso-rdrs-sc-leave@icann.org<mailto:gnso-rdrs-sc-leave@icann.org> _______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. This email originated from outside the firm. Please use caution.