[IRT.RegDataPolicy] One Doc follow up on Escrow

Sun Aug 9 17:43:42 UTC 2020

Good Afternoon,

Thanks Marc and Alex!

I concur with Marc's comments on the Data Escrow language and agree that we need to update this section to fit the policy language and data privacy intent.

As Marc and Alex both suggested, it would be great to get an update on the status of each of these DPAs. And I would also add support to Alex's multiple comments on waiting to go to public comment with our language until we have at least a grasp at what these DPAs are looking like (preferable to have the DPAs completed but understand the timing constraints and good drafts may be workable).

I look forward to Alex's side by side review and his comments.

Thanks
Roger

________________________________
From: IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org> on behalf of Alex Deacon <alex at colevalleyconsulting.com>
Sent: Thursday, August 6, 2020 6:06 PM
To: Anderson, Marc <mcanderson at verisign.com>
Cc: irt.regdatapolicy at icann.org <irt.regdatapolicy at icann.org>
Subject: Re: [IRT.RegDataPolicy] One Doc follow up on Escrow

Notice: This email is from an external sender.

Thanks Marc, All,

First, I agree that Section 8 of the OneDoc needs work to bring the language in line with the policy.  I guess the question is what is the best way to make that happen?

FWIW in preparation for an eventual "last call" I've started to go through the policy and OneDoc side by side....my initial review shows there are many areas (beyond Section 8) where there is a mismatch/inconsistency between policy and implementation language.   I will continue to work through the doc, and will try to distill and share the issues I find.

Second, I'm glad Marc raised the issue of the data processing agreements as this was an issue that caught my attention.  From what I understand the policy indicates that 4 separate DPAs (or data protection terms) will need to be drafted.

  1.  DPA between ICANN org and the CPs.   This DPA will include policy defined in Rec #1, Rec #19 and Rec #20.
  2.  DPA between ICANN org and the DRPs.  This DPA covers Rec #22 and Rec #23.
  3.  DPA between ICANN org and Data Escrow and EBERO providers.  This DPA covers Rec #8 and Rec #26.

I assume that the DPA between ICANN org and the CPs is the one being worked on by Beth and others and I look forward to reviewing that soon (??).    But can someone (Dennis maybe?) give us an update on the status of the 2nd and 3rd DPA?   Who is drafting these and when will we see a draft?

I'll note that there is a 4th DPA between Registries and Registrars that will cover Rec #7 - but we can put that aside until we hear back from Sebastien.

And finally - I'll repeat my view that given the importance of these 4 DPAs (they represent ~25% of the recommendations in the report) we shouldn't be asking the community to review the One Doc language until all DPAs are completed and, I assume, incorporated by reference into the One Doc. (Section #5).

Thanks.

Alex
___________
Alex Deacon
Cole Valley Consulting
alex at colevalleyconsulting.com<mailto:alex at colevalleyconsulting.com>
+1.415.488.6009

On Wed, Aug 5, 2020 at 8:36 PM Anderson, Marc via IRT.RegDataPolicy <irt.regdatapolicy at icann.org<mailto:irt.regdatapolicy at icann.org>> wrote:
Dennis and IRT/IPT members,

A couple meetings ago we discussed Section 9 in the One Doc covering Rec 8 (escrow).  We don't seem to have finished that discussion and the One Doc currently contains two different versions.  The first section in Rec #8 covers the important recommendation that ICANN Org enter into legally-compliant data protection agreements with the data escrow providers.  Can you provide an update on the status of that recommendation?  Implementation of that recommendations is important for all parties in complying with GDPR.

In looking at the different proposed versions of the policy language, I note inconsistencies with the policy recommendations.  The new version in particular takes the approach of if the data is collected, it MUST be escrowed.  This is not what the policy recommendations say.  For context, the working group took into account the GDPR principles of privacy by design and data minimization.  For each processing activity, the working group carefully considered what data (elements) is necessary to achieve the purpose.  In the case of escrow, the processing activity is the transfer of data from registry/registrar to the escrow provider (and if conditions are met, disclosure of that data).  The purpose is captured in Rec #1 section 4) "Provide mechanisms for safeguarding Registered Name Holders' Registration Data in the event of a business or technical failure of a Registrar or Registry Operator, or unavailability of a Registrar or Registry Operator, as described in the RAA and RA, respectiv
 ely".  The if you collect the data, you MUST escrow it approach, does not reflect the work of phase 1 EPDP to update policies and contractual requirements to help enable compliance with GDPR.

To provide a specific example, the new section 9.1 (9.1.13, 9.1.14 and 9.1.15) and the previous section 9.2 (9.2.1, 9.2.2 and 9.2.3) state that the Registrar MUST escrow the Tech Name, Phone and Email fields IF collected or generated.  The table in Rec 8 on pages 10 and 11 of the final report lists each of those fields as optional.  The working group did not determine that processing those 3 fields is necessary to achieve the purpose.

As noted in the recommendations, the workbooks in Annex D provide additional information.  The table on page 122 is specific to this example.  For the Tech Name, Phone and Email fields, the "collection" of each of those data elements is O-RNH (Registered Name Holder) meaning it is up to the Registered Name Holder to decide if they want to supply data for those fields.  For "transmission" each of those data elements is O-CP (Contracted Party) meaning it is up to the Contracted Party to decide if data for those fields will be transmitted to the escrow provider.

I hope that context helps in drafting policy language consistent with the policy recommendations.

Best,
Marc
_______________________________________________
IRT.RegDataPolicy mailing list
IRT.RegDataPolicy at icann.org<mailto: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: <http://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20200809/a9e52d69/attachment.html>