Resending. Please see email below for explanation 221 Review OneDoc Section 5 Data Protection Agreement<https://docs.google.com/document/d/1SVFkoI6RmrVVz--RrVLSOj1bmz1qLb7_JTuvt7At4Uo/edit#heading=h.8uxhg4ad741p> 20220718 20220801 Thanks Dennis Chang From: Dennis Chang <dennis.chang@icann.org> Date: Friday, July 29, 2022 at 14:35 To: Sarah Wyld <swyld@tucows.com>, "Dennis Chang via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] IRT Task 221 Review OneDoc Section5DataProtection Agreement 20220718; RDAP Profile status Hi Sarah and IRT, Thanks again for your input with rationale for us to better understand the reason for your language. Now that we understand better, we can accept the suggested language with added statements which is explained below. You may find the new language in IRT OneDoc also. New baseline 20220729 ICANN, gTLD Registry Operators, and accredited Registrars MUST enter into required data protection agreements with each other and with relevant third party providers contemplated under this Policy where applicable law requires. The terms may include legal bases for processing Registration Data. Where such agreements between Registry Operator or Registrar and ICANN are required to comply with applicable law, ICANN MUST upon request and without undue delay, enter into data protection agreement or agreements with Registry Operator or Registrar as implemented pursuant to this Policy. If Registry Operator or Registrar determines that such agreements are required by applicable law, Registry Operator and Registrar MUST make the request without undue delay pursuant to this policy. The data protection agreements MAY also be modified and updated from time-to-time based on additional guidance from relevant data protection authorities as provided for by applicable law. Rationale: Rationale: 1. We can accept the suggested language “ICANN MUST upon request and without undue delay enter into the data protection agreement or agreements with Registry Operator or Registrar as implemented pursuant to this Policy” with the additional statement to address cases where RO or RR determines that applicable law requires a data protection agreement with ICANN, but fails to initiate a request with ICANN to enter into the agreement or agreements implemented pursuant to the policy. 2. Also, the additional statement “If Registry Operator or Registrar determines that such agreements are required by applicable law, Registry Operator and Registrar MUST make the request without undue delay pursuant to this policy” makes it clear that RO and RR determine whether applicable law requires the data protection agreement, not ICANN org. 3. The last statement accepts the suggested “provided for by applicable law” language and further elaborates that there may be other guidance from EU or other authorities that we would need to respond to. Of course, all updates must be agreed upon by the parties involved in the agreement. I am pleased that we worked together to make this way better than where we started from. Please note that this is the Public Comment version and after the PC, we’ll need to review the entire policy language again before we finally publish it for implementation. On the RDAP Profile side, I receive a report that the WG will need one more meeting next week to complete. Thanks to the RDAP WG and IRT for continued support to this Implementation Project like no other. Dennis Chang From: "IRT.RegDataPolicy" <irt.regdatapolicy-bounces@icann.org> on behalf of "Sarah Wyld via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org> Reply-To: Sarah Wyld <swyld@tucows.com> Date: Wednesday, July 27, 2022 at 12:42 To: "Dennis Chang via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] IRT Task 221 Review OneDoc Section5DataProtection Agreement 20220718; RDAP Profile status Hi Dennis, Thanks for the response. Your suggested language for Change #1 does line up nicely with the earlier sentence in the section, but it does not accurately implement the recommendation. Rec 19 starts with "The EPDP Team recommends that ICANN Org negotiates and enters into required data protection agreements, as appropriate, with the Contracted Parties." The new language would allow ICANN to deny a DPA request from a CP, saying that they don't think a DPA is required by applicable law. What would happen in that situation? Either the CP shares data without the protection they think they legally need, or they don't share data and we're right back at the beginning of this whole conversation. When ICANN is requesting data, the CP must be the party to decide if a DPA is required. In this circumstance, if the CP requests a DPA, then ICANN must sign it in order to access this data. So, I think we should keep it as how I had originally suggested: "Where such agreements between a Registry Operator or Registrar and ICANN are required to comply with applicable law, ICANN MUST upon request and without undue delay enter into the data protection agreement or agreements with Registry Operator or Registrar as implemented pursuant to this Policy..." Re the change #3, adding "or as provided for by applicable law." The current draft says that the DPA must be entered into where required by applicable law. It does not say that it must be updated when the relevant law changes, and I still think it should. Thanks, Sarah -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com<mailto:swyld@tucows.com> [cid:image001.png@01D8A359.FFAC7A20] From: Dennis Chang<mailto:dennis.chang@icann.org> Sent: July 22, 2022 4:49 PM To: Elizabeth Bacon<mailto:beth@pir.org>; Sarah Wyld<mailto:swyld@tucows.com>; Dennis Chang via IRT.RegDataPolicy<mailto:irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] IRT Task 221 Review OneDoc Section5DataProtection Agreement 20220718; RDAP Profile status Dear IRT, Glad to hear that you found the new language more readable and understandable. Thank you for your review and suggested changes with rationales. The way that Sarah had laid them out was very helpful in our evaluation and revision in establishing a new baseline language. We’ve tracked 3 changes and will address each. Change #1: swapping around ICANN and the Registry operator or Registrar Change #2: add “upon request and without undue delay Change #3: add “or as provided for by applicable law. Suggested Change #2 was accepted. Suggested Change #1 was modified. If the suggested change was accepted as it was suggested, it would read “ICANN MUST … upon request ….” We’ve modified this to use “the parties” collectively, to indicate that we all have the shared obligation as intended by the recommendation. This follows and is consistent with the first sentence in this section “ICANN, gTLD Registry Operators, and accredited Registrars MUST enter into required data protection agreements with each other and with relevant third party providers contemplated under this Policy where applicable law requires. “ Suggested Change #3, was not accepted. We understand the desire to accommodate the future actions of EC and that future is already covered with the “applicable law requires’ in the first sentence and again “comply with applicable law” in the second. Here is the new baseline language for Section 5 OneDoc. Where such agreements between a Registry Operator or Registrar and ICANN are required to comply with applicable law, the parties MUST upon request and without undue delay enter into the data protection agreement or agreements implemented pursuant to this Policy, as may be updated from time-to-time. On the RDAP profile side, I’ve heard good progress is being made the WG which raises the confidence level of their deliver to us this month. My sincere gratitude to all those driving and supporting to get us to the public comment next month. Looking again on the scope of this project, it is unquestionably an accomplishment for this implementation team. I don’t know if you’ve heard but I keep hearing “implementation like no other.” Thanks Dennis Chang From: "IRT.RegDataPolicy" <irt.regdatapolicy-bounces@icann.org> on behalf of "Elizabeth Bacon via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org> Reply-To: Elizabeth Bacon <beth@pir.org> Date: Wednesday, July 20, 2022 at 13:59 To: Sarah Wyld <swyld@tucows.com>, "Dennis Chang via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] IRT Task 221 Review OneDoc Section 5DataProtection Agreement 20220718; RDAP Profile status Hello all, Sarah, I think this looks good. Thank you for pulling together some edits for all of us to consider. Best, Beth From: IRT.RegDataPolicy <irt.regdatapolicy-bounces@icann.org> on behalf of Sarah Wyld via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> Date: Wednesday, July 20, 2022 at 2:46 PM To: Dennis Chang via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> Subject: [EXTERNAL] Re: [IRT.RegDataPolicy] IRT Task 221 Review OneDoc Section 5DataProtection Agreement 20220718; RDAP Profile status CAUTION: This email came from outside your organization. Don’t trust emails, links, or attachments from senders that seem suspicious or you are not expecting. Hello all Thanks Dennis & team for the updated Section 5 text. I do find it more readable and understandable, and I appreciate that! I would like to propose a few changes, with redline here and some notes below the text. I have not (yet) put this into the OneDoc, was hoping to discuss it on the list here. ICANN, gTLD Registry Operators, and accredited Registrars MUST enter into required data protection agreements with each other and with relevant third party providers contemplated under this Policy where applicable law requires. The terms may include legal bases for processing Registration Data. Where such agreements between a Registry Operator or Registrar and ICANN are required to comply with applicable law, ICANN Registry Operator or Registrar MUST upon request and without undue delay enter into the data protection agreement or agreements with ICANN Registry Operator or Registrar as implemented pursuant to this Policy, as may be updated from time-to-time, or as provided for by applicable law. The first change (swapping around ICANN and the Registry operator or Registrar) matches Recommendation 19 (“The EPDP Team recommends that ICANN Org negotiates and enters into required data protection agreements, as appropriate, with the Contracted Parties.”) The addition of “upon request and without undue delay” is to indicate that ICANN must enter into that agreement at the request of the Registry Operator or Registrar. Adding “or as provided for by applicable law” is suggested to accommodate a potential standard/templated DPA provided by the relevant authority; I’m thinking about a future where the EC provides a base DPA for use just like how they provide base SCCs now. I think that these changes are in keeping with the text and intent of the recommendation, and look forward to the group’s feedback. Thanks, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com<mailto:swyld@tucows.com> [cid:image001.png@01D89DD1.DF4B9D70] From: Dennis Chang via IRT.RegDataPolicy<mailto:irt.regdatapolicy@icann.org> Sent: July 18, 2022 2:07 PM To: Roger D Carney<mailto:rcarney@godaddy.com>; Dennis Chang via IRT.RegDataPolicy<mailto:irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] IRT Task 221 Review OneDoc Section 5DataProtection Agreement 20220718; RDAP Profile status Dear IRT, Thanks for supporting the IRT meeting last week. Roger and Marc reported that the RDAP WG is adding an extra meeting to ensure their delivery in July. Based on their rigorous review including 3 IRT members, I shared that we expected us to move quickly to Public Comment upon receipt of the two RDAP RedDocs. We are, henceforth, working towards a Public Comment opening date of 17 August 2022. For this one remaining OneDoc section, we received helpful inputs from the IRT including a revised language at the meeting. Based on the suggestion that we merge the proposed languages rather than debating one vs another, we came up with a new baseline language for your review. You’ll see it in the IRT OneDoc and I post it here for your convenience. ICANN, gTLD Registry Operators, and accredited Registrars MUST enter into required data protection agreements with each other and with relevant third party providers contemplated under this Policy where applicable law requires. The terms may include legal bases for processing Registration Data. Where such agreements between a Registry Operator or Registrar and ICANN are required to comply with applicable law, Registry Operator or Registrar MUST enter into the data protection agreement or agreements with ICANN implemented pursuant to this Policy, as may be updated from time-to-time. https://docs.google.com/document/d/1SVFkoI6RmrVVz--RrVLSOj1bmz1qLb7_JTuvt7At4Uo/edit#heading=h.nblpucm6vwnq<https://protect-us.mimecast.com/s/Pz-6COYzm8CAExoUEB_CH?domain=docs.google.com> You’ll note that I did not change the due date and ask for your review by next Monday, 2022.07.18. Thank you for your continued support. Dennis Chang From: "IRT.RegDataPolicy" <irt.regdatapolicy-bounces@icann.org> on behalf of "Dennis Chang via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org> Reply-To: Dennis Chang <dennis.chang@icann.org> Date: Friday, July 8, 2022 at 11:26 To: Roger D Carney <rcarney@godaddy.com>, "Dennis Chang via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] IRT Task 221 Review OneDoc Section 5 DataProtection Agreement 20220718; RDAP Profile status Thanks Roger and Sarah for the suggestion. I see that the language proposed is basically the Recommendation language repeated. For implementation, shouldn’t we come up with requirements language? For example, the baseline language in OneDoc implements recommendations language such as “as appropriate” and “where applicable” Also, it connects the policy to the outcome of the work that negotiation team is doing. It would be good to know why CPH is not finding the OneDoc language unacceptable as is. Here it is duplicated for your convenience. “This Policy does not require Registry Operators and Registrars to enter into data protection agreements with ICANN unless applicable law requires a Registry Operator or Registrar to enter into a data protection agreement with ICANN in order for the Processing of Personal Data in Registration Data to comply with applicable law. Where such agreements are required to comply with applicable law, Registry Operator or Registrar MUST enter into the data protection agreement or agreements with ICANN implemented pursuant to this Policy, as may be updated from time-to-time.” We have an IRT meeting scheduled next week Wednesday. The only agenda item I have is this for now. If we can resolve this before then, we can cancel the meeting but happy to discuss this at the meeting too. Thanks Dennis Chang From: "IRT.RegDataPolicy" <irt.regdatapolicy-bounces@icann.org> on behalf of "Roger D Carney via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org> Reply-To: Roger D Carney <rcarney@godaddy.com> Date: Wednesday, July 6, 2022 at 07:32 To: "Dennis Chang via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] IRT Task 221 Review OneDoc Section 5 DataProtection Agreement 20220718; RDAP Profile status Good Morning, +1, the text Sarah recommends seems to be easier to read and then current proposed text in the OneDoc. Thanks Roger From: IRT.RegDataPolicy <irt.regdatapolicy-bounces@icann.org> on behalf of Sarah Wyld via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> Sent: Wednesday, July 6, 2022 9:10 AM To: Dennis Chang <dennis.chang@icann.org>; Dennis Chang via IRT.RegDataPolicy <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] IRT Task 221 Review OneDoc Section 5 DataProtection Agreement 20220718; RDAP Profile status 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@. Hello team, Back in June of 2020, the proposed language from the Staff team was:

ICANN, gTLD Registry Operators and accredited Registrars MUST enter into and maintain in effect data processing terms and conditions concerning personal data in Registration Data with each other and relevant third party providers, where applicable. The terms include legal bases for processing Registration Data

We had suggested a minor update:

ICANN, gTLD Registry Operators, and accredited Registrars MUST enter into required data protection agreements, as appropriate, with each other and with relevant third party providers, where applicable. The terms may include legal bases for processing Registration Data as applicable.

Can we consider using this text for this section, rather than the new proposed version? I think it faithfully implements the recommendation, covers the necessary items, and is straightforward. Thanks, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com<mailto:swyld@tucows.com> [cid:image001.png@01D89A96.80D58B40] From: Dennis Chang via IRT.RegDataPolicy<mailto:irt.regdatapolicy@icann.org> Sent: July 6, 2022 9:06 AM To: Dennis Chang via IRT.RegDataPolicy<mailto:irt.regdatapolicy@icann.org> Subject: [IRT.RegDataPolicy] IRT Task 221 Review OneDoc Section 5 DataProtection Agreement 20220718; RDAP Profile status Dear IRT, Please review the revised version for Section 5 of OneDoc. 221 Review OneDoc Section 5 Data Protection Agreement<https://protect-us.mimecast.com/s/uDPRCPNAnQS4JXqi09hGF?domain=nam10.safelinks.protection.outlook.com> 20220718 As we prepare for the upcoming public comment, we are nearing completion of OneDoc as you see and the RDAP Profile documents remain as the only deliverables. Roger advised that while the WG was not able to complete the documents in June, they will deliver in July. In fact, the WG scheduled an extra meeting to ensure their delivery to support our August opening of the Public Comment. Stay tuned. I’ll let you all know as soon as they are ready. -- Kind Regards, Dennis S. Chang GDD Programs Director Phone: +1 213 293 7889 Sykpe: dennisSchang www.icann.org<https://protect-us.mimecast.com/s/7Qh7CQWBo7h6JPmIMv_pr?domain=nam10.safelinks.protection.outlook.com> One World – One Internet