Dear RDRS Standing Committee Members, Please find the notes and action items from the RDRS Standing Committee Meeting on Monday, 7 July 2025. Thank you. Best regards, Caitlin RDRS Standing Committee Call Monday, 7 July @ 17:30 UTC High-Level Notes and Action Items Action Items 1. Standing Committee members to continue commenting on Chapter 4<https://docs.google.com/document/d/1oqXdMgsGltToV_JxDtubedfymvrmvoAH43kssxOT...> through Wednesday, 9 July. Reminder: Chapter 4 must represent recommendations and observations that can reach consensus of the Standing Committee. Accordingly, this requires SC members to respond to other members’ proposed additional text, comments, and questions and noting if you cannot support the proposed text or edits. 2. RDRS Support Staff to update Chapter 4 based on today’s discussion. 3. Following Wednesday, 9 July, RDRS Support Staff to compile the full draft Findings Report, including removing duplicative text, moving the recommendations to the beginning of the report, etc., for presentation and provision to the Standing Committee during its meeting on Monday, 14 July. – Notes 1. Welcome 2. Discussion of Draft Chapter 4<https://docs.google.com/document/d/1oqXdMgsGltToV_JxDtubedfymvrmvoAH43kssxOT...> · Intro text re: cost of SSAD · Per our discussion last week, ICANN org is planning to provide a cost estimate for maintaining the system as is while the Board and GNSO Council discussions regarding the next steps for the SSAD recommendations are ongoing. · ICANN org will provide an updated number for the overall budget in Chapter 3 next week - this will go through June 2025. ICANN org will also provide a cost estimate for maintaining the RDRS as is while the GNSO Council and Board discuss the SSAD recs. · Important to make clear that a large share of this cost is ICANN org personnel. While the SC may be familiar with these numbers, readers may not appreciate this nuance, and it’s important to make this clear. · ICANN org staff time dedicated to RDRS is included in the chart in Chapter 3. All staff time, including the staff supporting the RDRS SC, is included in that number. · Support Staff to add text clarifying the number in Point 1, noting the large share of the cost is ICANN org personnel hours. · Sarah added text for the SC to consider, noting that financial sustainability is very central to what this SC is working on. Ultimately, if the RDRS is to continue, Rec. 14 should be implemented - in other words, the RDRS should be paid for by requestors and not the community (registrants). · Could we consider having ICANN partially fund the RDRS and having an arbitrary fee for requestors? · Would need to further consider this. May consider the going forward costs needs to be borne by requestors. · The previous text may conflate two concepts - the cost/value and who is paying for it. The main point is that the RDRS should not be permitted to continue in its current funding model. · The requestor pays concept was very important to NCSG. The requestor should not get the service for free, but until we can achieve something that is reasonable for requestors to pay, perhaps ICANN could cover some of this. · Rec. 14 should be considered for the SSAD, but this is the RDRS - not the SSAD. All we are saying is we think RDRS should continue. · Not supportive of the text as it stands - GAC is discussing making RDRS a more permanent system. These points should be bifurcated. · If we are recommending RDRS should be kept as a long-term solution, then it’s appropriate for us to say if we think it should be free of charge or not. What we seem to be hearing is that the RDRS is going to be maintained indefinitely and will be paid for entirely by ICANN, which is not appropriate. · The concern here is if the requestor community is unable to fully fund it - is there a compromise solution here? · There is confusion here on if the RDRS will become permanent and if that is what this group is suggesting. We should be clear on this. · It is our job to figure out what comes next and provide a clear recommendation of this. So far, we have not done this. · This group should be specifying exactly what capabilities a new system should have and then it’s up to someone else to decide how to implement that. · This group is not constituted to take on the task of what a future system should look like because these discussions have largely been excluded; we have discussed the RDRS vis-a-vis the SSAD recs. It’s important to have a fresh discussion on what a future system could look like. · We are being asked to provide lessons learned based on what we learned from what was incorporated in RDRS. What we are suggesting is how the SSAD recs can be interpreted in light of what we learned from RDRS. · One thing we can recommend is new policy work. We could say - based on the learnings from RDRS, this particular recommendation needs to be revisited. We could even provide a recommendation of what the new recommendation could look like based on our experience with RDRS. · Rec 1 - continue RDRS beyond pilot period · No additional comments. · Recommendation 2.2 · Marc noted a concern with the way this is worded. · Support work on the authentication challenge, but not sure the current wording explains what the Council is expected to do with this. This needs to detail what should be done, what are the next steps, etc. · The key point is the system can exist without authentication, but we recommend partial authentication instead of originally-recommended full authentication, and that is a change that will make the system more viable. · Hope to have ICANN take a proactive role in creating the technical and administrative standards for authentication - hoping to collaborate with ICANN on this. Technical - here is how to receive authentication token; admin - sign some sort of MOU. · There is no single entity in the world that will be trusted by everyone else. There could be multiple entities that make attestations for their individual members. · Authentication is an important component going forward. Is this something we want to say about a future system or bolt onto RDRS. The idea that one entity cannot be trusted to authenticate everyone is an important lesson learned. 3. Next Steps · The support team is currently working on incorporating all chapters into the official report template. The Standing Committee will have ample time to review and comment on the complete draft in its final format. · Please note the structure of the chapters might change slightly (reducing duplication, relocating recommendations to the beginning, etc.), but the substance will remain the same. 4. AOB