Farzaneh, Thanks for your responses. I'll provide some detailed replies to your responses later. Steve On Wed, Mar 12, 2025 at 4:51 PM farzaneh badii <farzaneh.badii@gmail.com> wrote:
(oops I forgot to send this email last month)
Hi Steve, please see my responses below:
1.
*The system had to be defined, implemented, and operated by ICANN Org.* I question this assumption. It is not necessarily the case that ICANN Org must be the sole entity responsible for defining, implementing, and operating the system. Alternative governance models can be explored. 2.
*The system must not be involved in any decisions regarding disclosure due to the perceived risk of massive GDPR fines.* I disagree with this characterization. The system cannot make disclosure decisions not only because of potential GDPR fines but also because: 1. It does not have access to the data. 2. Registrars must comply with their own legal and regulatory obligations, including conducting fundamental rights balancing tests. Any centralized system cannot replace this legal responsibility. Additionally, the concern is not just about fines; involving the system in disclosure decisions could jeopardize data subjects’ privacy rights, which is a fundamental issue beyond financial penalties. 3.
*The system had to be focused on just the contracted parties. This positioned ICANN as serving just the needs of the contracted parties instead of the full Internet community.* I find this point unclear. The system was designed to standardize the process for receiving disclosure requests within the contractual framework between ICANN, registries, and registrars. The EPDP process actively considered the legitimate interests of requesters, but ICANN's role remains confined to its limited mission. Expanding beyond this would require fundamental changes to ICANN’s remit. 4.
*For SSAD, the essential requirement was for identification of the requestor, and the estimate for building and operating such a system required massive expenditures.* Identification of requesters is essential to prevent abuse and ensure the protection of personal data. Authentication is a necessary safeguard to uphold privacy rights and maintain accountability. This aligns with the NCSG’s long-standing position, which is a key perspective within the community.
*General Comment:* When referring to “many,” could you clarify which stakeholders or groups specifically hold this view? The EPDP resulted in a consensus-based policy developed through a multistakeholder process. If there are concerns with existing policies, there are established procedures within ICANN for revisiting them.
Farzaneh
On Mon, Jan 27, 2025 at 9:14 AM Steve Crocker via Gnso-rdrs-sc < gnso-rdrs-sc@icann.org> wrote:
Folks,
I have added the following comment to the draft outline of the RDRS Final Report.
Steve Crocker
============================================================
Both SSAD and RDRS have been based on the key assumptions that: 1. The system had to be defined, implemented and operated by ICANN Org. 2. The system must not be involved in any decisions regarding disclosure due to the perceived risk of massive GDPR fines. 3. The system had to be focused on just the contracted parties. This positioned ICANN as serving just the needs of the contracted parties instead of the full Internet community. 4. For SSAD, the essential requirement was for identification of the requestor, and the estimate for building and operating such a system required massive expenditures.
In the view of many, each of these assumptions should be challenged. Far better solutions are possible if the functionality is provided in a distributed fashion and with a focus on greater clarity regarding which requests would and would not be honored and more efficient design to reduce costs and increase performance.
The usage data that has been collected is a good predictor of the usage of the RDRS. The data does not provide any useful information about the underlying demand.
The primary results of the RDRS experiment are twofold:
1. Re-examine the assumptions and potential solutions, i.e. start over with a holistic approach.
2. The RDRS, though deeply flawed, is providing some degree of useful service. Continue it indefinitely until a suitable replacement is available.
===========================================
The above are key points that MUST be accommodated in this final report. It is not clear the current outline provides a clear place for these points to be included. They must be included, they must be included in a way that gives them credence and balance against the apparent default plan to treat the RDRS as a success and a signal to continue toward the original SSAD design. _______________________________________________ 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.
-- Sent by a Verified sender