Re: Strong negative view of RDRS
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 [signature_1238579664] +49 172 690 8418 Germany sebastien@registry.godaddy<mailto: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.
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
Sebastian, Thanks for your careful, thoughtful and constructive comments. 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.
For a serious system, effectiveness, clarity, and efficiency are the important criteria. - Effectiveness: Does it provide the correct results for both requestors and data holders? - Clarity: Is the behavior predictable and understood by the users? E.g. can a requestor learn what requests will and won't be answered? - Efficiency: Does the system work efficiently and can its users -- both requestors and data holders -- use the system efficiently? A pilot to measure demand has to be pretty close to what the actual system will be. Otherwise, the way it gets used will not be indicative of how the actual system will be used. Rather than approaching the task from this point of view, ICANN Org approached from the perspective how they could design, build and operate the system, and how they could limit their exposure to the risks they perceived. They focused on making use of existing software and mangled the functionality. No API and no mechanism to return results were critical limitations to Effectiveness. Not being willing to work with data holders to develop guidance, examples, etc. of good requests foreclosed all possibility of achieving Clarity. The lack of guidance or requirements on response times made measurement of efficiency irrelevant. It seems pretty clear that ICANN Org felt they needed to design, build and operate the RDRS. Perhaps they felt that because it was going to be such a limited system it would take too much time or money to outsource these functions. As a consequence, they thought in terms of what they could do as opposed to how best to get the job done. Further, it took a fairly long time to build and field the system they designed, and they have a fairly long cycle for making changes. If there were ever a situation that called for agile development, surely this was it. It also seems clear that Org wanted control. Instead of thinking in terms of what would be best for the Internet community, they took as given that it would be Org's system. This is antithetical to the design and operation of the Internet.
*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.
Org got nonsensical legal advice about the risks. The risks could easily be limited through simple contracts and accountability mechanisms, and the requestors could provide insurance to cover the more common misadventures. No one has wanted to have that conversation, but it seems to be both necessary and straightforward.
*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.
Next stage? This should have been included from the beginning. The attitude from Org was, "but that's all we can control." Emphasis on "control." 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.
The actual behavior of the registrars is all over the map. Some registrars are not responding at all. The current situation is there is actually nothing that compels a registrar to respond to any requests other than those accompanied by a court order. If you subdivide requests into three buckets, (a) purely public info, (b) legitimate requests for private data without a court order, and (c) requests with a court order, the middle bucket has not been approached in any meaningful way. *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.*
Indemnification of the requestor? Perhaps you mean the registrar? The requestors have to provide: - reasonable assurance that they protect the data they receive and use it only for the agreed purpose(s); - adequate assurance they can be trusted; and - viable method of being held accountable in the event they are at fault when there is a proble 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.
Agreed.
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.
I think I agree with this, but the devil is in the details. I think we need to compare our respective understandings. 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.
Thanks, Steve
*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
Hi all, Apologies for just pulling one small piece out of this email thread, but - "/Some registrars are not responding at all/." I'm curious how we know this, is there documentation we can all review as a group? it seems odd to me that a registrar would sign up to participate in RDRS and then not respond to any requests but also not withdraw from this optional program. If we can identify a registrar who's done so I would be interested in talking to them to understand why it's happening. Thanks, *Sarah Wyld, CIPP/E* Pronouns: she/they Head, Policy & Privacy Tucows #MakingTheInternetBetter swyld@tucows.com /Responses to this email are processed according to the Tucows Privacy Policy <https://www.tucows.com/privacy>/ On 2025-02-11 5:43 p.m., Steve Crocker via Gnso-rdrs-sc wrote:
Sebastian,
Thanks for your careful, thoughtful and constructive comments.
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.
For a serious system, effectiveness, clarity, and efficiency are the important criteria.
* Effectiveness: Does it provide the correct results for both requestors and data holders?
* Clarity: Is the behavior predictable and understood by the users? E.g. can a requestor learn what requests will and won't be answered?
* Efficiency: Does the system work efficiently and can its users -- both requestors and data holders -- use the system efficiently?
A pilot to measure demand has to be pretty close to what the actual system will be. Otherwise, the way it gets used will not be indicative of how the actual system will be used.
Rather than approaching the task from this point of view, ICANN Org approached from the perspective how they could design, build and operate the system, and how they could limit their exposure to the risks they perceived.
They focused on making use of existing software and mangled the functionality. No API and no mechanism to return results were critical limitations to Effectiveness. Not being willing to work with data holders to develop guidance, examples, etc. of good requests foreclosed all possibility of achieving Clarity.
The lack of guidance or requirements on response times made measurement of efficiency irrelevant.
It seems pretty clear that ICANN Org felt they needed to design, build and operate the RDRS. Perhaps they felt that because it was going to be such a limited system it would take too much time or money to outsource these functions. As a consequence, they thought in terms of what they could do as opposed to how best to get the job done.
Further, it took a fairly long time to build and field the system they designed, and they have a fairly long cycle for making changes. If there were ever a situation that called for agile development, surely this was it.
It also seems clear that Org wanted control. Instead of thinking in terms of what would be best for the Internet community, they took as given that it would be Org's system. This is antithetical to the design and operation of the Internet.
*/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.
Org got nonsensical legal advice about the risks. The risks could easily be limited through simple contracts and accountability mechanisms, and the requestors could provide insurance to cover the more common misadventures. No one has wanted to have that conversation, but it seems to be both necessary and straightforward.
*/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.
Next stage? This should have been included from the beginning. The attitude from Org was, "but that's all we can control." Emphasis on "control."
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.
The actual behavior of the registrars is all over the map. Some registrars are not responding at all.
The current situation is there is actually nothing that compels a registrar to respond to any requests other than those accompanied by a court order. If you subdivide requests into three buckets, (a) purely public info, (b) legitimate requests for private data without a court order, and (c) requests with a court order, the middle bucket has not been approached in any meaningful way.
*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.*
Indemnification of the requestor? Perhaps you mean the registrar?
The requestors have to provide:
* reasonable assurance that they protect the data they receive and use it only for the agreed purpose(s); * adequate assurance they can be trusted; and * viable method of being held accountable in the event they are at fault when there is a proble
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.
Agreed.
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.
I think I agree with this, but the devil is in the details. I think we need to compare our respective understandings.
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.
Thanks,
Steve
*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
_______________________________________________ Gnso-rdrs-sc mailing list --gnso-rdrs-sc@icann.org To unsubscribe send an email tognso-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.
participants (3)
-
Sarah Wyld -
Sebastien＠registry.godaddy -
Steve Crocker