2025-02-10 RDRS Standing Committee - Meeting #25

Notes/ Action Items

Documents to review:

Draft Chapter 1:https://docs.google.com/document/d/1CBAHz7G2AmjOt7C68Rn_hFl5c9F83lz9/edit#heading=h.4pzcaxt3ksmk[docs.google.com]

Draft Chapter 2:https://docs.google.com/document/d/1oqXdMgsGltToV_JxDtubedfymvrmvoAH43kssxOTnRk/edit?usp=sharing [docs.google.com]

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 requiresfurther 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