If I understand the RDRS correctly, it would be more precise to say "the RDRS tracks requests and provides and option for registrars to post outcomes." Steve On Wed, Aug 2, 2023 at 1:33 PM Sarah Wyld <swyld@tucows.com> wrote:

Hello all,

Thank you Yuko for providing these and for highlighting the differences between the three docs, that was very helpful for reviewing.

I have one comment, re this part: “Moreover, the RDRS tracks requests and registrar-provided responses”

This makes it sound like the response itself (including the contents, e.g. the registration data that is disclosed) is tracked in RDRS. Maybe instead you could change it to "the RDRS tracks requests and outcomes" which is more clear?

Thanks,

--

*Sarah Wyld*, CIPP/E

Policy & Privacy Manager

Pronouns: she/they

swyld@tucows.com

*From: *Yuko Yokoyama <yuko.yokoyama@icann.org> *Sent: *July 27, 2023 5:42 PM *To: *gnso-epdpp2-smallteam@icann.org *Subject: *[GNSO-EPDPP2-SmallTeam] RDRS Talking Points - 3 clean documents

Dear GNSO Small Team,

Thank you again for all your valuable input on the RDRS Talking Points document <https://docs.google.com/document/d/1UmDhymtc4kOrHjEEDmeLikwBP5X908DS/edit>. Due to the nature of the cleaning up process, I have opted to preserve all redline/comments in the original document, but created 3 clean documents based on that. These 3 documents incorporated all of you feedback and comments as appropriate.

- Cybersecurity Professionals <https://docs.google.com/document/d/1OxE2oiwwVuHu9mkmS82enMRPH7aD4ur20c1VYgtf...> - Law Enforcement Agencies <https://docs.google.com/document/d/1lR8R2BdbKYcy2YStdwGBDMzsVhzx1cRgIdc68q3p...> - Commercial and Consumer Protection <https://docs.google.com/document/d/1ugKLUQ5bsbnaiiGlxRKXnkNopb35KFmF5Ja4APDf...>

If you see something glaring, please do let me know. Otherwise, please consider these final in principle, and are ready for your use.

Please also be reminded that ICANN now has a one-page flyer, that will complement the talking point documents. They are translated into 6 UN languages + Portuguese:

- English <https://www.icann.org/en/system/files/files/new-service-request-access-nonpu...> - Arabic <https://www.icann.org/ar/system/files/files/new-service-request-access-nonpu...> - Spanish <https://www.icann.org/es/system/files/files/new-service-request-access-nonpu...> - French <https://www.icann.org/fr/system/files/files/new-service-request-access-nonpu...> - Portuguese <https://www.icann.org/pt/system/files/files/new-service-request-access-nonpu...> - Russian <https://www.icann.org/ru/system/files/files/new-service-request-access-nonpu...> - Chinese <https://www.icann.org/zh/system/files/files/new-service-request-access-nonpu...>

Thank you,

Yuko Yokoyama

Program Director

Strategic Initiatives, Global Domains & Strategy

Internet Corporation for Assigned Names and Numbers (ICANN)

Direct Line: +1 310 578 8693

Mobile: +1 310 745 1517

E-mail: yuko.yokoyama@icann.org

www.icann.org

_______________________________________________ GNSO-EPDPP2-SmallTeam mailing list GNSO-EPDPP2-SmallTeam@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdpp2-smallteam

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

Hi Sarah and Steve, Thank you for your comments. The RDRS does track what registrars input in the system (outcome, reasons for denial, etc). The distinction is that the outcome is a “self reported” by registrars, and not systematically captured data like we do with requestor’s request form data. This is why we used the phrasing of “registrar-provided responses.” “Response” being what registrar input in the RDRS, not the data that was disclosed to the requestor. Sarah, while we would like all participating registrars to input the outcome (and hope they do), due to lack of contractual or policy mandate for RDRS, we cannot “require” registrars to do so. I hope this clarified your questions or concerns. Thank you, Yuko From: GNSO-EPDPP2-SmallTeam <gnso-epdpp2-smallteam-bounces@icann.org> on behalf of Sarah Wyld <swyld@tucows.com> Date: Wednesday, August 2, 2023 at 10:59 AM To: "Anderson,Marc via GNSO-EPDPP2-SmallTeam" <gnso-epdpp2-smallteam@icann.org> Subject: Re: [GNSO-EPDPP2-SmallTeam] RDRS Talking Points - 3 clean documents Hi, Re “provides an option for registrars to post outcomes”, I thought that participating registrars are required to track the outcomes of all the requests we get through RDRS. I’m no longer sure where to find the basic documentation of those requirements, but how else would the reporting include the outcome rates (number of closed disclosure requests by type) if the outcome (type) is not tracked? Thanks, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com<mailto:swyld@tucows.com> From: Steve Crocker<mailto:steve@shinkuro.com> Sent: August 2, 2023 1:40 PM To: Sarah Wyld<mailto:swyld@tucows.com> Cc: Yuko Yokoyama<mailto:yuko.yokoyama@icann.org>; gnso-epdpp2-smallteam@icann.org<mailto:gnso-epdpp2-smallteam@icann.org>; Steve Crocker<mailto:steve@shinkuro.com> Subject: Re: [GNSO-EPDPP2-SmallTeam] RDRS Talking Points - 3 clean documents If I understand the RDRS correctly, it would be more precise to say "the RDRS tracks requests and provides and option for registrars to post outcomes." Steve On Wed, Aug 2, 2023 at 1:33 PM Sarah Wyld <swyld@tucows.com<mailto:swyld@tucows.com>> wrote: Hello all, Thank you Yuko for providing these and for highlighting the differences between the three docs, that was very helpful for reviewing. I have one comment, re this part: “Moreover, the RDRS tracks requests and registrar-provided responses” This makes it sound like the response itself (including the contents, e.g. the registration data that is disclosed) is tracked in RDRS. Maybe instead you could change it to "the RDRS tracks requests and outcomes" which is more clear? Thanks, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com<mailto:swyld@tucows.com> From: Yuko Yokoyama<mailto:yuko.yokoyama@icann.org> Sent: July 27, 2023 5:42 PM To: gnso-epdpp2-smallteam@icann.org<mailto:gnso-epdpp2-smallteam@icann.org> Subject: [GNSO-EPDPP2-SmallTeam] RDRS Talking Points - 3 clean documents Dear GNSO Small Team, Thank you again for all your valuable input on the RDRS Talking Points document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1UmDhymtc4kOrH...>. Due to the nature of the cleaning up process, I have opted to preserve all redline/comments in the original document, but created 3 clean documents based on that. These 3 documents incorporated all of you feedback and comments as appropriate. * Cybersecurity Professionals [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1OxE2oiwwVuHu9...> * Law Enforcement Agencies [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1lR8R2BdbKYcy2...> * Commercial and Consumer Protection [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1ugKLUQ5bsbnai...> If you see something glaring, please do let me know. Otherwise, please consider these final in principle, and are ready for your use. Please also be reminded that ICANN now has a one-page flyer, that will complement the talking point documents. They are translated into 6 UN languages + Portuguese: * English<https://www.icann.org/en/system/files/files/new-service-request-access-nonpu...> * Arabic<https://www.icann.org/ar/system/files/files/new-service-request-access-nonpu...> * Spanish<https://www.icann.org/es/system/files/files/new-service-request-access-nonpu...> * French<https://www.icann.org/fr/system/files/files/new-service-request-access-nonpu...> * Portuguese<https://www.icann.org/pt/system/files/files/new-service-request-access-nonpu...> * Russian<https://www.icann.org/ru/system/files/files/new-service-request-access-nonpu...> * Chinese<https://www.icann.org/zh/system/files/files/new-service-request-access-nonpu...> Thank you, Yuko Yokoyama Program Director Strategic Initiatives, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) Direct Line: +1 310 578 8693 Mobile: +1 310 745 1517 E-mail: yuko.yokoyama@icann.org<mailto:yuko.yokoyama@icann.org> www.icann.org<http://www.icann.org/> _______________________________________________ GNSO-EPDPP2-SmallTeam mailing list GNSO-EPDPP2-SmallTeam@icann.org<mailto:GNSO-EPDPP2-SmallTeam@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdpp2-smallteam _______________________________________________ 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.

Sebastian, et al, Thanks. As best I can tell, the proposed revised charter is to proceed with the old SSAD. To say this another way, the implementation and deployment of RDRS is a two to three year temporizing step, and then the plan is to return to the previously proposed SSAD concept. I think this is a major mistake. At the very least, it deserves a careful assessment of the purpose and whether the design will accomplish the purpose. Here are the key points. (This is not necessarily complete; there may be other key points.) 1. Users (requesters) of the system need to know whether their requests will be fulfilled and what data they will receive. As part of this, they need to know what they have to do to be qualified to make those requests, and they need to know what their obligations are after they receive the requested data. 2. Holders of the data, usually the registrars, need to know they will not incur significant risk if they provide responses in accordance with the rules. 3. The vast majority of the requests and responses should be handled automatically. This is the only way to keep costs under control and to make the system usable for the majority of cases. 4. There needs to be a way to perform searches and correlations. These may need to be done via trusted intermediary processes. 5. The quality/accuracy of the data has to be addressed. Allowing privacy/proxy services without control vitiates the entire notion of accurate registration data. 6. Privacy laws and general privacy principles have to be observed. 7. The system should be designed and operated to apply to and be for the benefit of the entire Internet community, not just the ICANN contracted parties. I'll try to say more going forward. For the present, this note signals an objection to the proposed charter as it is currently written. Thanks, Steve On Thu, Aug 24, 2023 at 8:46 AM Sebastien@registry.godaddy <Sebastien@registry.godaddy> wrote:

Dear Small Team,

As we will all be back at our desks in the next week or two I wanted to get us back into thinking about what is ahead of us with the RDRS.

1/ Thank you to those who contributed to the documents shared by Yuko last month. I am including her 27 July email below if anyone needs a refresher.

We agreed that there was no immediate need to pivot this into presentations, brochures or any other support you might need to promote the service, but as we are now able to look at our calendars for the next few months, it would be good to raise possible requests and deadlines if you are attending relevant events and would want Staff support in producing material.

2/ Marika sent 2 days ago a reminder to review and confirm the proposed charter for the Standing Committee to continue our good work after launch (see https://docs.google.com/document/d/1IFmCY1xEtWy7IoyM-uSYiRkzFkc0jLdM/edit). Thank you to those who confirmed it works. Thumbs up also from the Requestor side would be great.

3/ We will need to get into reviewing T&Cs before launch. I understand these have been in the working and we can look forward to drafts soon.

4/ We have not scheduled our next meeting yet. A number of us haven’t yet returned from their break.

Next week (28 July) looks early and the following Monday is Labor Day in the US. Unless anyone is itching to get back to it earlier, can I suggest for prepare our next call for Monday 11 September at our regular schedule, for a call every second week thereafter? I will ask Staff to send us invite to block the time slot. We can always agree to augment the cadence in the lead to launch if we find we need more time to get ready for it.

Kindly,

*Sebastien Ducos*

GoDaddy Registry | Senior Client Services Manager

[image: signature_3256585056]

+33612284445

France & Australia

sebastien@registry.godaddy

*From: *GNSO-EPDPP2-SmallTeam <gnso-epdpp2-smallteam-bounces@icann.org> on behalf of Yuko Yokoyama <yuko.yokoyama@icann.org> *Date: *Thursday, 27 July 2023 at 11:43 pm *To: *gnso-epdpp2-smallteam@icann.org <gnso-epdpp2-smallteam@icann.org> *Subject: *[GNSO-EPDPP2-SmallTeam] RDRS Talking Points - 3 clean documents

Caution: This email is from an external sender. Please do not click links or open attachments unless you recognize the sender and know the content is safe. Forward suspicious emails to isitbad@.

Dear GNSO Small Team,

Thank you again for all your valuable input on the RDRS Talking Points document <https://docs.google.com/document/d/1UmDhymtc4kOrHjEEDmeLikwBP5X908DS/edit>. Due to the nature of the cleaning up process, I have opted to preserve all redline/comments in the original document, but created 3 clean documents based on that. These 3 documents incorporated all of you feedback and comments as appropriate.

- Cybersecurity Professionals <https://docs.google.com/document/d/1OxE2oiwwVuHu9mkmS82enMRPH7aD4ur20c1VYgtf...> - Law Enforcement Agencies <https://docs.google.com/document/d/1lR8R2BdbKYcy2YStdwGBDMzsVhzx1cRgIdc68q3p...> - Commercial and Consumer Protection <https://docs.google.com/document/d/1ugKLUQ5bsbnaiiGlxRKXnkNopb35KFmF5Ja4APDf...>

If you see something glaring, please do let me know. Otherwise, please consider these final in principle, and are ready for your use.

Please also be reminded that ICANN now has a one-page flyer, that will complement the talking point documents. They are translated into 6 UN languages + Portuguese:

- English <https://www.icann.org/en/system/files/files/new-service-request-access-nonpu...> - Arabic <https://www.icann.org/ar/system/files/files/new-service-request-access-nonpu...> - Spanish <https://www.icann.org/es/system/files/files/new-service-request-access-nonpu...> - French <https://www.icann.org/fr/system/files/files/new-service-request-access-nonpu...> - Portuguese <https://www.icann.org/pt/system/files/files/new-service-request-access-nonpu...> - Russian <https://www.icann.org/ru/system/files/files/new-service-request-access-nonpu...> - Chinese <https://www.icann.org/zh/system/files/files/new-service-request-access-nonpu...>

Thank you,

Yuko Yokoyama

Program Director

Strategic Initiatives, Global Domains & Strategy

Internet Corporation for Assigned Names and Numbers (ICANN)

Direct Line: +1 310 578 8693

Mobile: +1 310 745 1517

E-mail: yuko.yokoyama@icann.org

www.icann.org _______________________________________________ GNSO-EPDPP2-SmallTeam mailing list GNSO-EPDPP2-SmallTeam@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdpp2-smallteam

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

Sebastien, Thank you for your detailed reply to my note. I'll try to expand a bit. My note was triggered by a possible misunderstanding that once the RDRS experiment is complete, the full SSAD will be rolled out without further consideration of the architecture. I think this would be a very large mistake. But in order to keep this discussion to a manageable scope, I'll focus on the RDRS. We can come back to post-RDRS issues later. On Tue, Sep 5, 2023 at 10:07 AM Sebastien@registry.godaddy <Sebastien@registry.godaddy> wrote:

Hi Steve,

I fully understand the approach the group has agreed upon for the RDRS is not your preferred path. I believe the point has been clearly made on a number of occasion and yet the group has agreed to proceed with it. We collectively note your assessment that it is a mistake.

To be clear, in my view there is no foregone conclusion and no one benefits from temporising for 2-3 years. If either were the case we’d be wasting our time and ICANN’s investment. I hope we collectively remain responsible enough to avoid both.

To your key points:

1. *Users (requesters) of the system need to know whether their requests will be fulfilled and what data they will receive. As part of this, they need to know what they have to do to be qualified to make those requests, and they need to know what their obligations are after they receive the requested data.* The template originally provided by the Registrars, which we are using on the Request side is both meant as a tool to gather the required elements, and a checklist to ensure the Requestor does not miss any key information. This in itself doesn’t guarantee “qualifying” for the data as it will depend on the assessment of the Sponsoring Registrar not only based on the data provided, but also on the jurisdiction they operate from and the local DPA’s own thresholds for what does or not qualify. There are efforts to harmonize these things within the EU and we are already experiencing wide differences; in our case we are building an international tool that will need to cater for entirely different legislations. I assume we will cover the Requestor’s obligations when we review the T&C’s, but here too, responding Registrars may need to cover additional requirements to ensure adherence to their local law. The creation of the form is indeed a step forward. It could have and should have been done quite a while ago. Everyone could have been using it to submit requests directly to registrars. But since the form is supposed to be available this month and the system available in November, we can proceed from here. While an orderly form is necessary, it's not sufficient. The point I've been making about Requesters knowing whether their requests will be honored requires more discussion. One way or another, both requesters and registrars are going to develop a sense of what requests will be honored. After a requester has made one or more requests, he will know which ones succeeded and which ones failed. Based on that, his subsequent requests will likely be patterned after the ones that succeeded previously. Similarly, registrars will gain similar experience and use that experience to streamline their internal processes. Tucows has been running their own system, Tucows Tiered Access Compliance and Operations (TACO) System https://tieredaccess.com . Perhaps they can comment on how they have evolved their system and internal processes based on their experience. The reaction whenever I've raised this point is that it's up to each registrar to evaluate each request. Well, yes, but that's just a starting point, not the end of the discussion. A couple of thoughts arise immediately: - How is a registrar supposed to make its determination? Simply saying it's up to them and they need to get legal advice isn't much help. What will the attorney do? It would surely help to have some guidance, worked example, shared experience, etc. It's not a matter of imposing rules from above. Rather, it's a matter of facilitating the learning process. - As noted above, repeated requests are likely to be patterned after prior successful requests. This form of learning can be left to each party without any coordination, but further improvements are possible if the parties communicate. For example: - Making requests and answering them is probably not a point of competition among either requesters or registrars. The requesters might choose to share their experiences, thereby providing useful clues to each other. The same is true for registrars. - One can even imagine that after there's been a bit of experience, certain types of requests can be formalized in a way that makes it possible for each registrar to process them automatically. - There's no force implied in the above. What is implied, however, is that we anticipate both the likelihood and utility of this learning curve. And by "anticipating" I mean we not only expect but also facilitate it. We have not had any of these discussions. ICANN Org has taken the narrow position that its role is to avoid getting involved in any of the substantive issues, it has not encouraged the requesters and registrars to do so, and it has not included support for these discussions in its design of the RDRS. 2. *Holders of the data, usually the registrars, need to know they will not incur significant risk if they provide responses in accordance with the rules.* The difficulty here is that it is neither for us nor for ICANN to guarantee that. Registrars will not incur risks if they adhere to their local legislation. I’ll let ICANN Org speak for itself, but I don’t see it offering a blanket protection to respondents in its T&C’s, if fact it has made clear from Day1 that it leaves the responsibility squarely in the Registrar’s camp. I'm not suggesting ICANN offer blanket protection. I'm not even suggesting ICANN offer *any* protection. What I am suggesting is that casting the discussion in terms of blanket protection closes off the potential for meaningful discussion. The path that's been chosen for the RDRS is strongly oriented against making useful, practical distinctions. This casts a lot of doubt on whether the data gathered by the RDRS will provide a meaningful sense of what the demand, cost, etc. would be in a well designed system. *3. The vast majority of the requests and responses should be handled automatically. This is the only way to keep costs under control and to make the system usable for the majority of cases.* We have had this conversation before: it is unfeasible, someone needs will own the responsibility for every answer and we cannot demand that this decision be taken blindly. See the above discussion. Automation is essential for reducing cost and delay. That said, I agree that it will take some experience and some work to determine which requests can be handled automatically. As you say, the decision cannot be taken blindly. But with experience, at least some of the requests can be handled automatically. The process will necessarily be incremental, i.e. "salami slicing." 4. *There needs to be a way to perform searches and correlations. These may need to be done via trusted intermediary processes.* I am not sure what is involved here. Can you please elaborate as long as we are not discussing doing research on specific requests and their responses, this has already been assessed and refused both by ICANN Org and the Respondent. There are legitimate uses for searches across the registration data. We can defer discussion of this for another time, but we can't make it go away. 5. *The quality/accuracy of the data has to be addressed. Allowing privacy/proxy services without control vitiates the entire notion of accurate registration data.* The issue of Privacy/Proxy has been addressed: it will not be tackled here, but we have engaged the Board to ask that the work on PPSAI be restarted. RDRS may need to be adapted in consequence, but we are not pre-empting the outcomes of that work which may be months/years away. This is another issue that has been kicked down the road. It won't go away. *6. Privacy laws and general privacy principles have to be observed.* It’s a given. *7. The system should be designed and operated to apply to and be for the benefit of the entire Internet community, not just the ICANN contracted parties.* We are in full agreement. To be clear if it wasn’t for the benefit of the Community, I believe ICANN (and I assume you mean Org) would probably want to stay away from any involvement at all. I don’t believe we can reduce taking in account the risk incurred by the contracted parties for potentially inappropriately handling the PII entrusted in them, as working “just” for the contracted parties. I agree that focusing on just the contracted parties won't change the risks involved with PII. That wasn't the point of this bullet. Rather, I was referring to the idea that this system has been designed with only the contracted parties involved. The ccTLDs and RIRs have similar needs.

I remain available to discuss this further.

Thanks. I too remain available for further discussion. Steve Crocker

Kindly,

*Sebastien Ducos*

GoDaddy Registry | Senior Client Services Manager

[image: signature_2363518853]

+33612284445

France & Australia

sebastien@registry.godaddy

*From: *Steve Crocker <steve@shinkuro.com> *Date: *Thursday, 24 August 2023 at 3:03 pm *To: *Sebastien Ducos <Sebastien@registry.godaddy> *Cc: *gnso-epdpp2-smallteam@icann.org <gnso-epdpp2-smallteam@icann.org>, Steve Crocker <steve@shinkuro.com> *Subject: *Re: [GNSO-EPDPP2-SmallTeam] EPDPP2-SmallTeam - Next steps

Caution: This email is from an external sender. Please do not click links or open attachments unless you recognize the sender and know the content is safe. Forward suspicious emails to isitbad@.

Sebastian, et al,

Thanks. As best I can tell, the proposed revised charter is to proceed with the old SSAD. To say this another way, the implementation and deployment of RDRS is a two to three year temporizing step, and then the plan is to return to the previously proposed SSAD concept. I think this is a major mistake. At the very least, it deserves a careful assessment of the purpose and whether the design will accomplish the purpose.

Here are the key points. (This is not necessarily complete; there may be other key points.)

1. Users (requesters) of the system need to know whether their requests will be fulfilled and what data they will receive. As part of this, they need to know what they have to do to be qualified to make those requests, and they need to know what their obligations are after they receive the requested data. 2. Holders of the data, usually the registrars, need to know they will not incur significant risk if they provide responses in accordance with the rules. 3. The vast majority of the requests and responses should be handled automatically. This is the only way to keep costs under control and to make the system usable for the majority of cases. 4. There needs to be a way to perform searches and correlations. These may need to be done via trusted intermediary processes. 5. The quality/accuracy of the data has to be addressed. Allowing privacy/proxy services without control vitiates the entire notion of accurate registration data. 6. Privacy laws and general privacy principles have to be observed. 7. The system should be designed and operated to apply to and be for the benefit of the entire Internet community, not just the ICANN contracted parties.

I'll try to say more going forward. For the present, this note signals an objection to the proposed charter as it is currently written.

Thanks,

Steve

On Thu, Aug 24, 2023 at 8:46 AM Sebastien@registry.godaddy <Sebastien@registry.godaddy> wrote:

Dear Small Team,

As we will all be back at our desks in the next week or two I wanted to get us back into thinking about what is ahead of us with the RDRS.

1/ Thank you to those who contributed to the documents shared by Yuko last month. I am including her 27 July email below if anyone needs a refresher.

We agreed that there was no immediate need to pivot this into presentations, brochures or any other support you might need to promote the service, but as we are now able to look at our calendars for the next few months, it would be good to raise possible requests and deadlines if you are attending relevant events and would want Staff support in producing material.

2/ Marika sent 2 days ago a reminder to review and confirm the proposed charter for the Standing Committee to continue our good work after launch (see https://docs.google.com/document/d/1IFmCY1xEtWy7IoyM-uSYiRkzFkc0jLdM/edit). Thank you to those who confirmed it works. Thumbs up also from the Requestor side would be great.

3/ We will need to get into reviewing T&Cs before launch. I understand these have been in the working and we can look forward to drafts soon.

4/ We have not scheduled our next meeting yet. A number of us haven’t yet returned from their break.

Next week (28 July) looks early and the following Monday is Labor Day in the US. Unless anyone is itching to get back to it earlier, can I suggest for prepare our next call for Monday 11 September at our regular schedule, for a call every second week thereafter? I will ask Staff to send us invite to block the time slot. We can always agree to augment the cadence in the lead to launch if we find we need more time to get ready for it.

Kindly,

*Sebastien Ducos*

GoDaddy Registry | Senior Client Services Manager

[image: signature_3256585056]

+33612284445

France & Australia

sebastien@registry.godaddy

*From: *GNSO-EPDPP2-SmallTeam <gnso-epdpp2-smallteam-bounces@icann.org> on behalf of Yuko Yokoyama <yuko.yokoyama@icann.org> *Date: *Thursday, 27 July 2023 at 11:43 pm *To: *gnso-epdpp2-smallteam@icann.org <gnso-epdpp2-smallteam@icann.org> *Subject: *[GNSO-EPDPP2-SmallTeam] RDRS Talking Points - 3 clean documents

Caution: This email is from an external sender. Please do not click links or open attachments unless you recognize the sender and know the content is safe. Forward suspicious emails to isitbad@.

Dear GNSO Small Team,

Thank you again for all your valuable input on the RDRS Talking Points document <https://docs.google.com/document/d/1UmDhymtc4kOrHjEEDmeLikwBP5X908DS/edit>. Due to the nature of the cleaning up process, I have opted to preserve all redline/comments in the original document, but created 3 clean documents based on that. These 3 documents incorporated all of you feedback and comments as appropriate.

- Cybersecurity Professionals <https://docs.google.com/document/d/1OxE2oiwwVuHu9mkmS82enMRPH7aD4ur20c1VYgtf...> - Law Enforcement Agencies <https://docs.google.com/document/d/1lR8R2BdbKYcy2YStdwGBDMzsVhzx1cRgIdc68q3p...> - Commercial and Consumer Protection <https://docs.google.com/document/d/1ugKLUQ5bsbnaiiGlxRKXnkNopb35KFmF5Ja4APDf...>

If you see something glaring, please do let me know. Otherwise, please consider these final in principle, and are ready for your use.

Please also be reminded that ICANN now has a one-page flyer, that will complement the talking point documents. They are translated into 6 UN languages + Portuguese:

- English <https://www.icann.org/en/system/files/files/new-service-request-access-nonpu...> - Arabic <https://www.icann.org/ar/system/files/files/new-service-request-access-nonpu...> - Spanish <https://www.icann.org/es/system/files/files/new-service-request-access-nonpu...> - French <https://www.icann.org/fr/system/files/files/new-service-request-access-nonpu...> - Portuguese <https://www.icann.org/pt/system/files/files/new-service-request-access-nonpu...> - Russian <https://www.icann.org/ru/system/files/files/new-service-request-access-nonpu...> - Chinese <https://www.icann.org/zh/system/files/files/new-service-request-access-nonpu...>

Thank you,

Yuko Yokoyama

Program Director

Strategic Initiatives, Global Domains & Strategy

Internet Corporation for Assigned Names and Numbers (ICANN)

Direct Line: +1 310 578 8693

Mobile: +1 310 745 1517

E-mail: yuko.yokoyama@icann.org

www.icann.org

_______________________________________________ GNSO-EPDPP2-SmallTeam mailing list GNSO-EPDPP2-SmallTeam@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdpp2-smallteam

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

Becky, Thanks. (It looks like you responded to the entire small group. I don't think any of your message was off list.) Today was busy for me. Tomorrow will be as well. I'll try to respond more completely as soon as I can. I'm thinking it may be helpful to reformat slightly and add identifiers for each of us. Steve On Mon, Sep 11, 2023 at 3:49 AM Becky Burr <becky.burr@board.icann.org> wrote:

*Steve and Seb, also off-list, I offer further views on Steve's proposed requirement list follow (in italics). These are my views alone - the Board has not taken any position on these issues.*

*In an ideal world, the requirements Steve identifies are entirely sensible. But in almost all cases - including in the case of the dozen US State data protection laws adopted in recent years - data protection law consists of a set of principles. While there is some similarity in the fair information principles underpinning data protection law, interpretation (and enforcement) varies from sovereign to sovereign and from regulator to regulator, even in a single sovereign space. But, with rare exception, all of the following things are true:*

- *Data protection laws require a data Controller (for purposes of this discussion, the registrar) to apply a set of high-level principles to a specific situation, on a case-by-case basis. * - *The data Controller is on the regulatory/judicial hook for applying those principles, in each case, in accordance with the views of the relative regulator in the first instance and, ultimately, the relevant judicial authority.* - *There is not enough relevant case law, whether at the local/regulatory level or at the broader judicial level (e.g., ECJ), to enable the level of regulatory/judicial predictability needed to support Steve's requirements.* - *Absent regulatory clarity, a registrar's response to a request for registration data will necessarily turn on a combination of: (i) its interpretation of how the principles should apply to a particular situation; (ii) its best guess as to how a relevant regulator would apply those principles; and (iii) its risk appetite. * - *The absence of on-point precedent incentivizes Controllers to take a conservative approach to disclosure - in the eyes of lawmakers and regulators, that is a feature, not a bug. This, in turn, reduces the likelihood that clarifying precedent will emerge.* - *ICANN has no authority or ability to impose its views on (i)-(iii) above on a registrar/controller that is liable for compliance with applicable law.* - *A very broad indemnification from ICANN might address a registrar's financial exposure for disclosure, but will not protect the disclosing registrar against reputational and operational risk. As a result, even indemnification by ICANN might not change outcomes, i.e., output will continue to vary from request to request based on the specific use case, the relevant jurisdictions (both the data subject's and the registrars), and the specific registrar. * - *Data protection laws disfavor - and in some cases specifically prohibit - automated decision-making where resulting decisions will have a legal or other material impact on data subjects. *

Steve, off list, I offer some observations on your comments in blue *(Becky's additional thoughts in green italics)*

1. Users (requesters) of the system need to know whether their requests will be fulfilled and what data they will receive. As part of this, they need to know what they have to do to be qualified to make those requests, and they need to know what their obligations are after they receive the requested data. Under relevant data protection laws, each request must be evaluated based on the relevant standard on a case by case basis. In the EEA/UK/Switzerland, for example, registrars will need to decide on a case by case basis whether: (i) the requestor has a legitimate interest in the data and (ii) whether the privacy rights of the individual should take precedence over those interests. *Agree, see above.* 2. Holders of the data, usually the registrars, need to know they will not incur significant risk if they provide responses in accordance with the rules. *There is, at present, no way for registrars to be assured this is the case. * 3. The vast majority of the requests and responses should be handled automatically. This is the only way to keep costs under control and to make the system usable for the majority of cases. Automated processing with legal/similar/serious impact on individual rights is affirmatively prohibited under GDPR. *Note that we specifically sought a legal opinion on this issue and Bird & Bird opined that regulators were likely to conclude that a decision to release registration data rose to the legal/similar/serious level. Please note that this concern about automated decision making is NOT limited to GDPR. Most of the 12 US* states that have adopted data protection laws in the last couple of years impose higher standards with respect to automated decision making. E.g., under §59.1-573(A)(5) of the Virginia CDPA, consumers have the right to opt out of the processing of their personal data for purposes of profiling in furtherance of decisions that produce legal or similarly significant effects concerning the consumer. 4. There needs to be a way to perform searches and correlations. These may need to be done via trusted intermediary processes. This functionality was not present in the old whois system and I don't think it was a requirement coming out of the policy development process. Can the small team, or even the GNSO Council, obligate registrars to provide new services in the absence of a PDP? *Agree, further policy development is required to impose this obligation on registrars. But in the context of bona fide cyber security research, couldn't searches and correlations be done without personal data or using pseudonymized data, at which point personal data could be requested? The necessity prong of the legitimate interest test requires a finding that there is no less intrusive way to serve the legitimate interest(s) of those conducting searches and correlations. * 5. The quality/accuracy of the data has to be addressed. Allowing privacy/proxy services without control vitiates the entire notion of accurate registration data. I don't disagree, although once again I don't think either the GNSO Council or the Board has authority under the bylaws. *Agree, further policy development is required to impose this obligation on registrars.* 6. Privacy laws and general privacy principles have to be observed. *Agree* 7. The system should be designed and operated to apply to and be for the benefit of the entire Internet community, not just the ICANN contracted parties. *Agree*

I'll try to say more going forward. For the present, this note signals an objection to the proposed charter as it is currently written.

Thanks,

On Tue, Sep 5, 2023 at 5:07 PM Sebastien@registry.godaddy <Sebastien@registry.godaddy> wrote:

...

Hi Steve,

I fully understand the approach the group has agreed upon for the RDRS is not your preferred path. I believe the point has been clearly made on a number of occasion and yet the group has agreed to proceed with it. We collectively note your assessment that it is a mistake.

To be clear, in my view there is no foregone conclusion and no one benefits from temporising for 2-3 years. If either were the case we’d be wasting our time and ICANN’s investment. I hope we collectively remain responsible enough to avoid both.

To your key points:

1. *Users (requesters) of the system need to know whether their requests will be fulfilled and what data they will receive. As part of this, they need to know what they have to do to be qualified to make those requests, and they need to know what their obligations are after they receive the requested data. * The template originally provided by the Registrars, which we are using on the Request side is both meant as a tool to gather the required elements, and a checklist to ensure the Requestor does not miss any key information. This in itself doesn’t guarantee “qualifying” for the data as it will depend on the assessment of the Sponsoring Registrar not only based on the data provided, but also on the jurisdiction they operate from and the local DPA’s own thresholds for what does or not qualify. There are efforts to harmonize these things within the EU and we are already experiencing wide differences; in our case we are building an international tool that will need to cater for entirely different legislations. I assume we will cover the Requestor’s obligations when we review the T&C’s, but here too, responding Registrars may need to cover additional requirements to ensure adherence to their local law.

2. *Holders of the data, usually the registrars, need to know they will not incur significant risk if they provide responses in accordance with the rules. * The difficulty here is that it is neither for us nor for ICANN to guarantee that. Registrars will not incur risks if they adhere to their local legislation. I’ll let ICANN Org speak for itself, but I don’t see it offering a blanket protection to respondents in its T&C’s, if fact it has made clear from Day1 that it leaves the responsibility squarely in the Registrar’s camp.

3. *The vast majority of the requests and responses should be handled automatically. This is the only way to keep costs under control and to make the system usable for the majority of cases. * We have had this conversation before: it is unfeasible, someone needs will own the responsibility for every answer and we cannot demand that this decision be taken blindly.

4. *There needs to be a way to perform searches and correlations. These may need to be done via trusted intermediary processes. * I am not sure what is involved here. Can you please elaborate as long as we are not discussing doing research on specific requests and their responses, this has already been assessed and refused both by ICANN Org and the Respondents.

5. *The quality/accuracy of the data has to be addressed. Allowing privacy/proxy services without control vitiates the entire notion of accurate registration data. * The issue of Privacy/Proxy has been addressed: it will not be tackled here, but we have engaged the Board to ask that the work on PPSAI be restarted. RDRS may need to be adapted in consequence, but we are not pre-empting the outcomes of that work which may be months/years away.

6. *Privacy laws and general privacy principles have to be observed. * It’s a given.

7. *The system should be designed and operated to apply to and be for the benefit of the entire Internet community, not just the ICANN contracted parties. * We are in full agreement. To be clear if it wasn’t for the benefit of the Community, I believe ICANN (and I assume you mean Org) would probably want to stay away from any involvement at all. I don’t believe we can reduce taking in account the risk incurred by the contracted parties for potentially inappropriately handling the PII entrusted in them, as working “just” for the contracted parties.

I remain available to discuss this further.

Kindly,

*Sebastien Ducos*

GoDaddy Registry | Senior Client Services Manager

[image: signature_2363518853]

+33612284445

France & Australia

sebastien@registry.godaddy

*From: *Steve Crocker <steve@shinkuro.com> *Date: *Thursday, 24 August 2023 at 3:03 pm *To: *Sebastien Ducos <Sebastien@registry.godaddy> *Cc: *gnso-epdpp2-smallteam@icann.org <gnso-epdpp2-smallteam@icann.org>, Steve Crocker <steve@shinkuro.com> *Subject: *Re: [GNSO-EPDPP2-SmallTeam] EPDPP2-SmallTeam - Next steps

Caution: This email is from an external sender. Please do not click links or open attachments unless you recognize the sender and know the content is safe. Forward suspicious emails to isitbad@.

Sebastian, et al,

Thanks. As best I can tell, the proposed revised charter is to proceed with the old SSAD. To say this another way, the implementation and deployment of RDRS is a two to three year temporizing step, and then the plan is to return to the previously proposed SSAD concept. I think this is a major mistake. At the very least, it deserves a careful assessment of the purpose and whether the design will accomplish the purpose.

Here are the key points. (This is not necessarily complete; there may be other key points.)

1. Users (requesters) of the system need to know whether their requests will be fulfilled and what data they will receive. As part of this, they need to know what they have to do to be qualified to make those requests, and they need to know what their obligations are after they receive the requested data. 2. Holders of the data, usually the registrars, need to know they will not incur significant risk if they provide responses in accordance with the rules. 3. The vast majority of the requests and responses should be handled automatically. This is the only way to keep costs under control and to make the system usable for the majority of cases. 4. There needs to be a way to perform searches and correlations. These may need to be done via trusted intermediary processes. 5. The quality/accuracy of the data has to be addressed. Allowing privacy/proxy services without control vitiates the entire notion of accurate registration data. 6. Privacy laws and general privacy principles have to be observed. 7. The system should be designed and operated to apply to and be for the benefit of the entire Internet community, not just the ICANN contracted parties.

I'll try to say more going forward. For the present, this note signals an objection to the proposed charter as it is currently written.

Thanks,

Steve

On Thu, Aug 24, 2023 at 8:46 AM Sebastien@registry.godaddy <Sebastien@registry.godaddy> wrote:

Dear Small Team,

As we will all be back at our desks in the next week or two I wanted to get us back into thinking about what is ahead of us with the RDRS.

1/ Thank you to those who contributed to the documents shared by Yuko last month. I am including her 27 July email below if anyone needs a refresher.

We agreed that there was no immediate need to pivot this into presentations, brochures or any other support you might need to promote the service, but as we are now able to look at our calendars for the next few months, it would be good to raise possible requests and deadlines if you are attending relevant events and would want Staff support in producing material.

2/ Marika sent 2 days ago a reminder to review and confirm the proposed charter for the Standing Committee to continue our good work after launch (see https://docs.google.com/document/d/1IFmCY1xEtWy7IoyM-uSYiRkzFkc0jLdM/edit). Thank you to those who confirmed it works. Thumbs up also from the Requestor side would be great.

3/ We will need to get into reviewing T&Cs before launch. I understand these have been in the working and we can look forward to drafts soon.

4/ We have not scheduled our next meeting yet. A number of us haven’t yet returned from their break.

Next week (28 July) looks early and the following Monday is Labor Day in the US. Unless anyone is itching to get back to it earlier, can I suggest for prepare our next call for Monday 11 September at our regular schedule, for a call every second week thereafter? I will ask Staff to send us invite to block the time slot. We can always agree to augment the cadence in the lead to launch if we find we need more time to get ready for it.

Kindly,

*Sebastien Ducos*

GoDaddy Registry | Senior Client Services Manager

[image: signature_3256585056]

+33612284445

France & Australia

sebastien@registry.godaddy

*From: *GNSO-EPDPP2-SmallTeam <gnso-epdpp2-smallteam-bounces@icann.org> on behalf of Yuko Yokoyama <yuko.yokoyama@icann.org> *Date: *Thursday, 27 July 2023 at 11:43 pm *To: *gnso-epdpp2-smallteam@icann.org <gnso-epdpp2-smallteam@icann.org> *Subject: *[GNSO-EPDPP2-SmallTeam] RDRS Talking Points - 3 clean documents

Caution: This email is from an external sender. Please do not click links or open attachments unless you recognize the sender and know the content is safe. Forward suspicious emails to isitbad@.

Dear GNSO Small Team,

Thank you again for all your valuable input on the RDRS Talking Points document <https://docs.google.com/document/d/1UmDhymtc4kOrHjEEDmeLikwBP5X908DS/edit>. Due to the nature of the cleaning up process, I have opted to preserve all redline/comments in the original document, but created 3 clean documents based on that. These 3 documents incorporated all of you feedback and comments as appropriate.

- Cybersecurity Professionals <https://docs.google.com/document/d/1OxE2oiwwVuHu9mkmS82enMRPH7aD4ur20c1VYgtf...> - Law Enforcement Agencies <https://docs.google.com/document/d/1lR8R2BdbKYcy2YStdwGBDMzsVhzx1cRgIdc68q3p...> - Commercial and Consumer Protection <https://docs.google.com/document/d/1ugKLUQ5bsbnaiiGlxRKXnkNopb35KFmF5Ja4APDf...>

If you see something glaring, please do let me know. Otherwise, please consider these final in principle, and are ready for your use.

Please also be reminded that ICANN now has a one-page flyer, that will complement the talking point documents. They are translated into 6 UN languages + Portuguese:

- English <https://www.icann.org/en/system/files/files/new-service-request-access-nonpu...> - Arabic <https://www.icann.org/ar/system/files/files/new-service-request-access-nonpu...> - Spanish <https://www.icann.org/es/system/files/files/new-service-request-access-nonpu...> - French <https://www.icann.org/fr/system/files/files/new-service-request-access-nonpu...> - Portuguese <https://www.icann.org/pt/system/files/files/new-service-request-access-nonpu...> - Russian <https://www.icann.org/ru/system/files/files/new-service-request-access-nonpu...> - Chinese <https://www.icann.org/zh/system/files/files/new-service-request-access-nonpu...>

Thank you,

Yuko Yokoyama

Program Director

Strategic Initiatives, Global Domains & Strategy

Internet Corporation for Assigned Names and Numbers (ICANN)

Direct Line: +1 310 578 8693

Mobile: +1 310 745 1517

E-mail: yuko.yokoyama@icann.org

www.icann.org

_______________________________________________ GNSO-EPDPP2-SmallTeam mailing list GNSO-EPDPP2-SmallTeam@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdpp2-smallteam

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

_______________________________________________ GNSO-EPDPP2-SmallTeam mailing list GNSO-EPDPP2-SmallTeam@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdpp2-smallteam

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