2025-04-21 RDRS Standing Committee - Meeting #29

PROPOSED AGENDA

1. Welcome

   1. Update on Chapter 2 and 3

2. Update from RDRS doodle poll

3. Discussion on Chapter 4

4. AOB

BACKGROUND DOCUMENTS

PARTICIPATION

Apologies: none

Attendance

RECORDINGS

Audio Recording

Zoom Recording

GNSO transcripts are located on the GNSO Calendar

Notes/ Action Items

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[docs.google.com] and 3 [docs.google.com] and provided comments.

Documents: 

• Chapter 1-3: 

• 1https://docs.google.com/document/d/1CBAHz7G2AmjOt7C68Rn_hFl5c9F83lz9/edit [docs.google.com] 

• 2https://docs.google.com/document/d/1oqXdMgsGltToV_JxDtubedfymvrmvoAH43kssxOTnRk/edit?tab=t.0[docs.google.com] 

• 3https://docs.google.com/document/d/1c2Nm5s1Q-4jrAqWvsurH-k6BhpyanGIW/edit [docs.google.com] 

Agenda

1. Welcome

1. Update on Chapter 2 and 3

·         There have been no further comments received on Chapter 2 [docs.google.com] and Chapter 3 [docs.google.com]

·         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 ofChapter 2 [docs.google.com] and 3 [docs.google.com] and provided comments.

2. 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.

3. 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.

4. AOB