Dear members of the Standing Committee, Please find below the high-level notes from this week’s meeting. The next meeting is scheduled for Monday, 4 November at 17:30 UTC. Kind regards, Feodora and Caitlin -- RDRS Standing Committee Meeting 21 October 2024 1. Welcome 2. ICANN Standards of Behavior * This is a necessary reminder that all Standing Committee members are governed by ICANN’s Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en#:~:text=Protect%20the%20organization's%20assets%20and,a%20responsible%20and%20principled%20way.> * During our last meeting, there was a comment made to an ICANN org staff member where inappropriate language was used – please remember to be respectful of all participants, including ICANN org staff. 1. Pending Action Items * Please remember to document any outreach events you participate in using the RDRS Outreach Tab<https://docs.google.com/spreadsheets/d/1XFK-RCT5Nv-KcNgX4eQunkUKgSI35Yc_nUZ6...> of the RDRS Standing Committee Workbook. * The action item related to providing a rationale for reporting of countries associated with law enforcement requests will be discussed later in this meeting under Item 8. 1. GSE Presentation on RDRS Outreach and Engagement * The Global Stakeholder Engagement (GSE) Team is dividing its engagement into two buckets: (i) working with registrars in the region to increase participation, and (ii) working with potential requestors to direct them to the system to submit requests. * GSE has primarily focused on the second bucket – working on requestor awareness across the five ICANN regions * We have distributed translated written materials, conducted webinars in various time zones and multiple styles to account for different audience needs, and reached out to key stakeholders in the various regions – for example, law enforcement has been very helpful in disseminating information * We have worked closely with our Communications Team who helped create a tool kit for us to use as we meet more potential requestors * As we look to the future, we will continue participating in technical engagement events, civil society events, and governmental events to discuss the RDRS. * SC question: With respect to cyber security professionals and researchers, there are two groups: (i) security practitioners who are aligned with law enforcement, and (ii) researchers who do research on a longitudinal basis, which is broader. These groups should not be lumped together because they are distinct. * Will endeavor to take this under consideration, but this may be difficult to report on. * SC question: When you reach out to law enforcement, are you usually making groups aware for the first time or are they already familiar with the RDRS? * Speaking particularly from Latin American and the Caribbean, there have been some shifts. One year ago, all groups were hearing about this for the first time; now, there are more agencies (for example in Argentina) that are familiar, and we believe this will continue. * SC: believe we are making good progress, and appreciate all of these efforts. To that end, there is one system that everyone already knows about (Whois) where we should consider putting a message that says “for redacted data, go here” to reach as many users as possible. * SC: how are outreach efforts considering registrants? Also, it would be helpful to know, for the sake of transparency, which law enforcement agencies you work with. * We have worked with the RALOs for particular awareness for registrants. GSE could prepare additional information to drill down on the law enforcement agencies we have contacted. 1. Discussion on Vice Chair Selection for RDRS SC * To help manage the work of the SC and assist from a leadership perspective, Sebastien reached out to John McElwaine to see if he would be willing to serve as vice chair, provided the SC does not object. * John has graciously agreed to serve in this role – are there any objections to this? * No objections: John M. will serve as vice chair or the RDRS SC. 1. ICANN81 Session preparation * We will discuss this at the next meeting due to limited time today * Would like to get the ball rolling with the report to Council. Registrars have been working on this, but would appreciate input from other groups * Encourage all members to come prepared to discuss what we have learned so far in reviewing the metrics * SC: registrars plan to submit some thoughts next week, so that it will be well in advance of ICANN81 * SC: note that the BC believes the considering the pilot as a predictor of demand is incorrect and would be a terrible assessment of demand * Suggest discussing this more during ICANN81 due to time constraints today 1. Update on RDRS to GNSO Council * Update will continue at ICANN81 due to time constraints during the October Council meeting; however, wanted to note that Sebastien will send a draft letter to the Council (making sure that RDRS SC is sticking to its scope). Plan to share this letter with the RDRS SC next week. * ACTION: Sebastien to share draft letter to GNSO Council with RDRS SC by 1 November 2024. 1. Europol RDRS Webinar Feedback * Deferred to next meeting 1. Discussion on Metric 18 and 19 * ICANN org: Thank you for the feedback during the last meeting. * There is a lot of data in the monthly metrics reports, and it’s important that ICANN org understood precisely what the Standing Committee was asking for. * ICANN is committed to working with the SC to ensure you have the data that you need to fulfill your scope of work. * ICANN looked at the ask closely and has two mock-ups to share with the group. Metric 18 breaks down the requests by law enforcement type, and the country where the law enforcement requestor is coming from. * Similarly, Metric 19 breaks down the data, but this breaks it down by the jurisdiction where the data is being processed. * With this, there are two important caveats: * (1) RDRS does not have an authentication mechanism – this means, in practice, that we do not actually know if the requestor is from law enforcement. It is a self-selected field by the requestor. * (2) Within the RDRS, ICANN is not the recipient of the requests. Accordingly, ICANN is not evaluating or making determinations on requests. * While we propose to include this data in the next monthly report, it may require the production of a separate CSV. * SC: as a registrar receiving the request, we would have the same issue because we do not know if a request marked as law enforcement is actually coming from law enforcement. Also, can we get the data of all countries? * ICANN: Yes, the breakdown will be by country. * SC: the concern is that this is self-reported, unverified data, so perhaps the inclusion of a disclaimer could be helpful here. A CSV will be fine. * ICANN: The next report will include the data requested – a breakdown of self-reported law enforcement requestors by country. Also, would like to highlight that because ICANN is not the recipient of the requests, the example of a transparency report from a company like Google is not analogous to ICANN’s reporting. There was some confusion about the claim of lack of transparency. With the understanding that the data being provided is not from authenticated law enforcement agencies, ICANN can provide the data to the RDRS SC. The RDRS SC will see this data for the October report, which will be published shortly after ICANN81. * The exact format of the data (CSV, PDF, etc.) is still being worked out. 1. AOB * None.