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
|
+49 172 690 8418 |