Thanks Feodora.

This message is to confirm that I have again reviewed Chapter 1 and left comments about suggested changes.

Dear RDRS SC,

 

Please see below the notes and action items from the last meeting.

The next meeting is schedule for 24 February 2025 at 17:30 UTC.

  

Kind regards,

Feodora and Caitlin

 

 

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

 

Action Item:	Owner	Deadline
Review Chapter One and mark any concerns and cannot live with areas. SC Members to highlight in the draft chapter or via list if there is an area of Chapter1 they believe requires further SC discussion. Flagged items will be added to the upcoming meeting agenda.	All Members	18 February
Review draft Chapter 2. Suggest what to keep, remove or modify.	All Members	19 February
Provide effectiveness ratings for implemented enhancements. Draft Chapter2 Table 1.	All Members/Proposal Owners	19 February
Add justification/rationale & risk analysis for proposed enhancements. Draft Chapter2 Table 3.	All Members/Proposal Owners	19 February
Add priority rating for proposed future enhancements from 1 to 10.  1 being high priority and 10 being lowest priority. Draft Chapter2 Table 3.	All Members	19 February

Documents to review:

 

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

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

 

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 requires further 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

 

 

 

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

Website: www.icann.org

 

 

_______________________________________________
Gnso-rdrs-sc mailing list -- gnso-rdrs-sc@icann.org
To unsubscribe send an email to 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.