Dear RDRS SC,

 

Please find below the high-level notes and Action Items from the two RDRS sessions at ICANN83.

 

The next meeting is scheduled for 23 June at 17:30 UTC.

 

Kind regards,

Feodora

 

 

RDRS SC ICANN83 Sessions June 9 and 10 June

 

Action Items:



  1. Welcome
    1. SC Chair opened the meeting and gave a brief introduction on the work and background of the RDRS SC. The slides can be found here.
  1. Working Session on Assignment 4

 

Discussion Summary: 

·         Proposal: To Recommend reviewing forms by a “focus group” with requesters/responders; perhaps form a Requester Group.

·         Some SC members noted to maintain standardized form but improve interface and documentation.

·         Acknowledged functionality works, but:

·         Not a full ticketing system.

·         Limited history tracking of request status changes (e.g., expedited to standard).

·         Suggestion to improve visibility/history of status changes.

·         Draft Conclusion: Functionality adequate but could benefit from enhancements.

·         Central Gateway Manager not incorporated into RDRS.

·         Limited explanation options (dropdown menu) may be insufficient.

·         Law enforcement noted some issues about being redirected away from RDRS.

·         Remove “auto-reject” from draft conclusion.

·         Explicitly note that some SSAD concepts (gateway manager) were not piloted.

·         Suggestion for requester-responder communication feature in RDRS.

·         Current Priority levels don’t “make sense” anymore.

·         Suggestion to list technical and policy prerequisites for urgent processing.

·         SC members noted for this recommendation to enumerate the features that would be needed to potentially handle urgent request.

·         SC member noted for authentication for groups other than law enforcement, LEA authentication should be prioritized, but there should be a lightweight authentication for other requestors.

·         RDRS does not offer automation features.

·         Concerns around registrars disclosing data beyond request scope.

·         Need for clarity in final recommendation language.

·         SC members noted need to look at the recommendation as a whole.

·         SC members noted the current RDRS are very helpful.

·         Some SC members noted for further metric improvements, especially around requester accountability.

·         Request form requires requesters to identify the issue and purpose using a mandatory field and dropdown.

·         Some noted the GDPR-centric language.

·         Discussion acknowledged need for training and better user guidance.

·         No further comment. 

·         Concerns about assumptions equating high request volume with abuse.

·         Review the original Recommendation text as a whole. 

·         RDRS logs certain data

·         No user-level logs currently

·         Differentiation of logging purposes (accountability, statistics, debugging, transparency)

·         The current RDRS Standing Committee functions well but differs from the SSAD’s envisioned permanent review mechanism.

·         Partial alignment; recommendation should be retained with understanding it applies to future governance.

·         Participants see potential in RDRS but hesitant to invest further unless it's confirmed as permanent.

·         API development highlighted as critical to system usefulness and integration.

·         Standardized forms, improved interface, and better user feedback were named as other important system enhancements.

·         Discussion on whether RDRS will evolve into a final system or be replaced.

·         Notes and updated draft conclusions from both sessions to be compiled.

·         July goal: Final review of full report by Standing Committee.

·         Strong emphasis placed on completing the report by July to maintain alignment with the 2-year pilot timeframe.

3.                   AOB