[IRT.RegDataPolicy] Data Retention requirements

Fri Feb 18 21:01:33 UTC 2022

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 at tucows.com  <mailto:swyld at tucows.com>
>
> *From: *Dennis Chang (Google Docs) 
> <mailto:comments-noreply at docs.google.com>
> *Sent: *February 16, 2022 7:09 PM
> *To: *swyld at 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
>
> 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]
>
> 	
>
>
>       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.
>
> 	
>
>
>       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.
>
> 	
>
>
> _______________________________________________
> IRT.RegDataPolicy mailing list
> IRT.RegDataPolicy at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20220218/98539ca4/attachment-0001.html>