(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.

Farzenah, When I read your note, I wasn't sure you had interpreted my original note correctly. To avoid possible misinterpretation, here's what I wrote: 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. On Wed, Mar 12, 2025 at 4:51 PM farzaneh badii you wrote:

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.

I was asserting ICANN Org has behaved as if they decided or take it as an

implicit requirement that they were the ones to define, implement and operate the system. I think we're in agreement that others can and should have been involved in the design, implementation and operation of the system. (I did not use the word "governance" which refers to a different aspect of the system and requires a separate discussion.) 2. *The system must not be involved in any decisions regarding disclosure due to the perceived risk of massive GDPR fines.* I was asserting ICANN Org has behaved as if they must not be involved in disclosure decisions, but wrote too tersely. I did not intend to refer to whether ICANN Org would be involved in individual decisions on a request-by-request basis. That would be a bad idea for multiple reasons. However, though I wrote indistinctly, I meant to refer to whether ICANN Org should be involved in making sure there is an organized and reasonably predictable framework for disclosure decisions. You wrote: I disagree with this characterization. The system cannot make disclosure decisions not only because of potential GDPR fines but also because: It does not have access to the data.

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.

ICANN Org could and, in my opinion, should insist the registrars use consistent and transparent criteria in their balancing tests whenever possible. This need not cover every possible case, but it should cover the usual cases. I wrote: 3. T*he 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.* ICANN Org limited its concern to designing a system for the contracted parties. However, there is no fundamental difference between what the contracted parties need and what the ccTLD community needs.

1.

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.

ICANN's role is to serve the Internet community. The limitation of focus

to just the contracted parties undermine's ICANN's legitimacy and make it more of a trade organization. *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.* This was my assertion of ICANN's assumption that this was the essential requirement. In my view, this is wrong-headed and set ICANN down a path that caused it to create an extraordinary estimate of the cost of operation. A better approach is to realize the registrars need to know whether they can trust the requestor. The identity of the requestor may or may not play an important role in determining that trust, but even if the registrar knows with complete certainty the identity of the requestor, it would still not be sufficient. What the registrar needs is that the requestor is bound by a set of obligations that underwrites the requestor's behavior and will deal with impermissible behavior, should it occur. I think this is more or less aligned with what you wrote:

1.

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.

The established procedures you're referring to is to point out where the policies are unworkable and not fit for purpose, which is what I've done. Thanks, Steve

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