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