Dear IRT, As promised, we are providing an alternate language for this note for Data Retention I converted this email discussion to an IRT task to ensure I get your attention. You’ll also note the due date being set to next week Tuesday, 29 March 2022, so that we can close this item at the next IRT meeting. The original note was not inaccurate nor misaligned with the policy requirement. However, we’ve reworded the language to remove reference to RAA per suggestions/. 201 Review Implementation Note F.c. Retention of Registration Data - revised<https://docs.google.com/document/d/1SVFkoI6RmrVVz--RrVLSOj1bmz1qLb7_JTuvt7At4Uo/edit> 20220329 With this item closed, we should be able to close out Phase 1 Rec 15 and Phase 2 Rec 21 both. I look forward to the Task Map color changes at our meeting next week. Thank 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: Thursday, March 3, 2022 at 12:37 To: Theo Geurts <gtheo@xs4all.nl>, "irt.regdatapolicy@icann.org" <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] Data Retention requirements Thanks Theo and IRT, We discussed this yesterday and I think we made progress. We agreed to 1. will keep a note for clarity 2. not add data examples in that note I took the action to come back with alternative language. This one is especially challenging because we agreed on the policy language already (Section 13) Disagreement on the note, however, indicates that we see the requirement differently. While, it’s tempting to ignore this and leave for others in the future to deal with, I thank the IRT for the hard work it takes to untangle. Please do offer your insights and suggestions to move forward. Thanks Dennis Chang From: "IRT.RegDataPolicy" <irt.regdatapolicy-bounces@icann.org> on behalf of "Theo Geurts via IRT.RegDataPolicy" <irt.regdatapolicy@icann.org> Reply-To: Theo Geurts <gtheo@xs4all.nl> Date: Friday, February 18, 2022 at 13:02 To: "irt.regdatapolicy@icann.org" <irt.regdatapolicy@icann.org> Subject: Re: [IRT.RegDataPolicy] Data Retention requirements So I am trying to untangle this. The EPDP rec was on transfer data retention. A specific purpose, I cannot recall why we went there. I agree the clarification of the rec can trigger some questions on what is in the RAA. And we need to be clear as some registrars can do the wrong things based on just reading a policy. I would suggest to put the clarification as a foot note for registars for implementation, as in guidance. Best, Theo Op 17/02/2022 om 14:57 schreef Sarah Wyld via IRT.RegDataPolicy: Hello IRT team, Looking forward to finalizing this question related to data retention requirements. Specifically, I am looking at Implementation Note F(c) which I will copy here for reference: For purposes of clarity, unless specifically addressed and modified by this Policy, all other data retention requirements and obligations within Registrar’s Registrar Accreditation Agreement remain applicable and in force. For example, this Policy does not supersede or replace additional existing data retention requirements not applying to RDDS data elements that Registrars are subject to under the Registrar Accreditation Agreement. For clarity, this does not prevent Requestors, including ICANN Compliance, from requesting disclosure of these retained data elements for purposes other than TDRP. [P2P2R21] This implementation note will raise a question in the reader’s mind: “What other data retention requirements and obligations exist within the RAA?”. If the answer to this question is unclear, then the note will cause more confusion than clarity. The Recommendation we’re implementing says: The EPDP Team confirms its recommendation from phase 1 that registrars MUST retain only those data elements deemed necessary for the purposes of the TDRP, for a period of fifteen months following the life of the registration plus three months to implement the deletion, i.e., 18 months. This retention is grounded on the stated policy stipulation within the TDRP that claims under the policy may only be raised for a period of 12 months after the alleged breach (FN: see TDRP section 2.2) of the Transfer Policy (FN: see Section 1.15 of TDRP). For clarity, this does not prevent Requestors, including ICANN Compliance, from requesting disclosure of these retained data elements for purposes other than TDRP, but disclosure of those will be subject to relevant data protection laws, e.g., does a lawful basis for disclosure exist. For the avoidance of doubt, this retention period does not restrict the ability of registries and registrars to retain data elements for longer periods. So, the Recommendation says registrars “MUST retain only those data elements deemed necessary for the purposes of the TDRP” but the OneDoc says “ALSO the other data mentioned in the RAA”. Those are clearly not aligned. We could resolve this by simply removing the note F(c); our Policy requirement remains the same, and aligns with the Recommendation. Alternatively, we could go through the "Non-exhaustive list of examples of information/data/evidence that is not covered by the TDRP<https://docs.google.com/document/d/1x_DC_X3acfMuuwjiuCpxSihE_fR3Ok2KEZ3A2DzuVvg/edit>” document that the Staff team put together of data they think should be retained outside this TDRP retention requirements. I have looked at every data element in that list and with the exception of the abuse reports (which have their own retention period clearly listed in 3.18.3) they all should be retained either only for the lifetime of the domain or are necessary for the TDRP. So, unless someone can point to data which should be retained differently than described in the Recommendation, I still find that the Implementation Note F(c) is confusing and does not help the implementer, because it makes them think there are retention requirements which there are not. If we must keep the note, we should update it to specifically indicate that only the Abuse Reports mentioned in RAA 3.18.3 are retained in this way. -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com<mailto:swyld@tucows.com> [cid:image003.png@01D823DC.57DA4810] From: Dennis Chang (Google Docs)<mailto:comments-noreply@docs.google.com> Sent: February 16, 2022 7:09 PM To: swyld@tucowsinc.com<mailto:swyld@tucowsinc.com> Subject: IRT.OneDoc RegDat... - There was a comment on this which I n... Dennis Chang replied to a comment in the following document [Image removed by sender.]IRT.OneDoc RegDataPolicy20201005<https://docs.google.com/document/d/1SVFkoI6RmrVVz--RrVLSOj1bmz1qLb7_JTuvt7At4Uo/edit?disco=AAAAVmqHkI4&usp=comment_email_document&ts=620d9221&usp_dm=false> For purposes of clarity, unless specifically addressed and modified by this Policy, all other data retention requirements and obligations within Registrar’s Registrar Accreditation Agreement remain applicable and in force. For example, this Policy does not supersede or replace additional existing data retention requirements not applying to RDDS data elements that Registrars are subject to under the Registrar Accreditation Agreement. For clarity, this does not prevent Requestors, including ICANN Compliance, from requesting disclosure of these retained data elements for purposes other than TDRP. [P2P2R21] [Image removed by sender.] Sarah Wyld There was a comment on this which I now cannot find in the comment history. This point c is confusing and should be removed, thank you. [Image removed by sender.] Dennis Chang New Hi Sarah, if you are referring to the comments that said that this policy replaces all retention requirements in RAA, that was closed since it is out-of-scope. This note is particularly important due to the Rec21 from Phase 2. Per the IRT call today, I'd like to close out the Recommendations related to retention. Would appreciate a reply here that it's ok to resolve this comment or point to specific language that is misaligned with the recommendation. thanks. Open<https://docs.google.com/document/d/1SVFkoI6RmrVVz--RrVLSOj1bmz1qLb7_JTuvt7At4Uo/edit?disco=AAAAVmqHkI4&usp=comment_email_discussion&ts=620d9221&usp_dm=false> Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA You have received this email because you are a participant in this thread. Change what Google Docs sends you.<https://docs.google.com/document/u/103140320049987970298/docos/notify?ouid=103140320049987970298&id=1SVFkoI6RmrVVz--RrVLSOj1bmz1qLb7_JTuvt7At4Uo&title=IRT.OneDoc+RegDataPolicy20201005&resourcekey> You can reply to this email to reply to the discussion. [Image removed by sender.] _______________________________________________ IRT.RegDataPolicy mailing list IRT.RegDataPolicy@icann.org<mailto:IRT.RegDataPolicy@icann.org> https://mm.icann.org/mailman/listinfo/irt.regdatapolicy _______________________________________________ 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.