Thank you Feodora –
If the SC elects to not delete Rec5, U.S. would propose the following alternate language for Rec5, which I have also inserted into the work table; please note that under the first bullet, there are two sub-bullets;
the copy/pasted text in the work table may have lost that formatting detail. It is our hope that this text has captured the diversity of viewpoints expressed thus far (including Marc’s helpful advice to make clear when we are speaking about applying Rec 14
elements to RDRS, vs the Rec 14 applicability as part of a package of recommendations considered for SSAD/successor systems, which can be addressed elsewhere):
Gabriel
The SC acknowledges the value of a RDRS as a stopgap system to standardize the disclosure request process and route requests to the appropriate contracted parties, as well as the value of iterative enhancements
to the RDRS system. The SC has further noted concerns from various of its members pertaining to the application – or non-application – of elements of Recommendation 14: Financial Sustainability upon the RDRS itself (prior to adoption of a more permanent system).
Such concerns – which are not put forward as consensus positions but rather as important topics for considerations by any party subsequently seeking to implement Recommendation 14 upon the RDRS - include:
· Whether application of fees or charges to use the RDRS would prove fatal were they to be applied before
o
the system achieves the full participation of registrars and/or
o
norms are established for RDRS interoperability with the near universal existence of Privacy/Proxy service providers
· Whether absence of fees unduly places costs upon ICANN org for the ongoing operation of RDRS (until such time as a permanent system is implemented)
· Whether the logistics and cost of implementing a fee-for-request system would introduce more expense to the RDRS’ operations than it otherwise would have recovered
· Whether fees to requestors for their own accreditation would need to apply if/when requestor groups provide at their own cost means of authenticating their members (such as is contemplated by the
PSWG’s work to establish large law enforcement agencies as Identity Providers)
· Whether requestors who take on the cost and burden of becoming Identity Providers (which were the primary cost driver of the SSAD’s total estimated expenses) would thereby meet the expectation that
requestors primarily bear the ongoing operational costs of a request system.
From: Feodora Hamza via Gnso-rdrs-sc <gnso-rdrs-sc@icann.org>
Sent: Tuesday, July 29, 2025 9:55 AM
To: gnso-rdrs-sc@icann.org
Subject: [EXTERNAL EMAIL] - [Gnso-rdrs-sc] Notes and Action Items 2025-07-28 RDRS Standing Committee - Meeting #40
Dear RDRS SC,
Please find below the high-level notes and Action Items from our last meeting.
Deadline for all AIs: 4 August
Documents:
The next meeting is scheduled for Monday 4 August and 17:30 UTC.
Kind regards,
Feodora on behalf of Support Staff
2025-07-28 RDRS Standing Committee - Meeting #40
Deadline for all AIs: 4 August
Documents:
·
SC Chair opened the meeting and noted the sessions extended to 2 hours due to the volume of discussion points remaining.
·
Goal: finalizing the committee’s report by mid-August for public comment.
·
Support Staff presented the pending comments for SC discussion.
·
Focus on unresolved or substantive comments, especially around Chapter 4 (Assignment 4). Noted that comments marked green (in review document) were resolved.
Discussion on Recommendation 5 – Financial Sustainability for RDRS
·
SC members suggested removal of Recommendation 5. Suggested for including factual cost data without recommending financial models.
·
SC members
noted any fees for the current RDRS system until the board formally adopts a successor system should not be considered. The system is not mandatory. Stated any charge implies endorsement of Recommendation 14, which the board hasn’t approved. Implementing
a billing system could discourage use of RDRS.
·
SC members proposed fees only if RDRS evolves with features like APIs or RDAP integration. Emphasized the need to fund enhancements via requester fees + ICANN support.
Expressed concern about resource commitment until “suecssor system” is in place.
·
SC members
noted that any billing system, regardless of the charge, introduces significant complexity and operational costs.
·
SC members
supported retaining current text in Recommendation 5 as a minimal viable statement on funding.
Action Items: Gabriel to draft
additional language
for Recommendation 5.
Discussion regarding Privacy/Proxy
·
SC members requested removal of “wall of text” in RDRS regarding privacy/proxy-related requests.
·
SC members supported the edit but suggested relocating it to Recommendation 2 (system enhancement/user experience).
·
SC members agreed it’s more of a user interface fix than a policy issue.
·
Suggested simplifying the rationale by removing references to “behavioural change.”
Discussion on Recommendation 6
·
SC members
proposed GNSO Council formally ask the ICANN Board to reject the SSAD recommendations as a whole. Then the Recommendation can return to Council to enable new deliberations.
·
Emphasized treating SSAD recommendations as a complete package.
·
No objections raised.
Discussion on Fundamental Rights Balancing
·
SC members proposed a broader approach where all registrars apply fundamental rights balancing, not just when GDPR applies.
·
Requested future edits to be developed in coordination with John McElwaine (regarding Rec8).
·
SC members clarified current SSAD language requires applying local law where GDPR is not applicable.
Action Item:
Farzaneh and John to discuss prior to next SC meeting and draft mutually agreeable language.
3.
Discussion on RDRS SC meeting cadence/duration (10min)
·
SC Chair noted that the remaining SC meetings will be extended to 2hrs until all pending comments are resolved.
·
Next meeting 4 August 2025 at 17:30 UTC.