Sebastian, Thanks for your carefully written and constructive note. I'm involved in another event tonight and I have our webinar tomorrow, so it may be a day or so before I can reply substantively. You made several key points that will be the basis for very useful discussion. Thanks! Steve On Wed, Feb 5, 2025 at 4:22 PM Sebastien--- via Gnso-rdrs-sc < gnso-rdrs-sc@icann.org> wrote:
Dear Steve,
Thank you for your comments.
It is not for me to decide what ends in the report or not, I’ll leave it to the Standing Committee, but rest assured that if these points are to appear in the final report, we will find room for them in the structure Staff proposed.
This said, I feel I need to comment them from the point of view of someone who has been trying to guide this process since inception, 3 years ago now.
*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.*
No, at least certainly not in case of RDRS. I have relayed on several occasions, particularly since ICANN81, that the decision of going for an ICANN built and/or operated system remains an open question. It has been so from inception, the question of relying on ICANN.org for any development was posed, including at Board-level. The main reason for having ICANN.org developing this pilot, was because it was a pilot and opening an RFP to cater for it was deemed too large of an endeavour for this pilot. It’s been raised in our spreadsheet, it will appear as such in the final report.
*2. The system must not be involved in any decisions regarding disclosure due to the perceived risk of massive GDPR fines.*
Yes, and may I note that no one (ICANN or other) has offered to share this responsibility, let alone to indemnify Registrars or any other future disclosing party for the risk incurred in disclosures that might be legally challenged and found unlawful.
*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.*
No, the fact that we believe the next stage should include willing ccTLDs has been raised in our spreadsheet and will be included in the report. We concentrated today on contracted parties (or the Registrar side of the CPH) because they are the only one that have an agreement with ICANN which stipulates that they should handle disclosure requests, a contractual element ICANN considered as key in the absence of Policy to justify getting involved in the request process at all. In the absence of policy, the alternative was and remains, for each Registrar to go about it on their own.
*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.*
Yes, I concur at least for 50% of the cost. Staff is seeking cost evaluations internally for the RDRS (based on a 18 months of development and operations) which should help us better forecast what it may cost in the long run.
*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.*
I appreciate your conclusions. I believe we have consensus on your second point, to keep RDRS on until replaced by a more permanent solution. After years of work on this (starting with EPDP Phase 2) and 1,000s of volunteer hours spent I’ll let the Standing Committee decide if it wants to recommend to the GNSO to “start over with a holistic approach”.
May I also personally note:
The data, RDRS or any future system that proposes to facilitate the lawful disclosure of, is currently under the care of the Registrars who have been entrusted it by their Registrant clients, covered by their agreements with the said Registrants. It is being transmitted to Registries and Escrow Providers under ICANN contracts, which define each party’s responsibility over the said data. No system will change this fact/construction. Any system facilitating disclosure will need the cooperation of the data holders, as responsible Data Controllers, to operate. Unless and until the Controllership and inherent responsibilities are assigned to anyone else, working with the CPH in the case of gTLDs and the different ccTLD managers for cc’s is unavoidable. Before we were able to roll the RDRS pilot out, the Small Team, Staff and the RrSG in particular, spent months working with the Registrar community to educate and convince them that participating in RDRS was a good idea and would allow the Community to gain knowledge.
I don’t see any successor system operating without their full cooperation.
Kindly,
*Sebastien Ducos*
GoDaddy Registry | Senior Client Services Manager
[image: signature_1238579664]
+49 172 690 8418 Germany
sebastien@registry.godaddy
*From: *Steve Crocker via Gnso-rdrs-sc <gnso-rdrs-sc@icann.org> *Date: *Monday, 27 January 2025 at 3:14 pm *To: *gnso-rdrs-sc@icann.org <gnso-rdrs-sc@icann.org> *Cc: *GNSO-Secs <gnso-secs@icann.org> *Subject: *[Gnso-rdrs-sc] Strong negative view of RDRS
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
ZjQcmQRYFpfptBannerStart
*This Message Is From an External Sender *
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
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
