[IRT.RegDataPolicy] One Doc follow up on Escrow

Thu Aug 6 23:06:38 UTC 2020

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
+1.415.488.6009

On Wed, Aug 5, 2020 at 8:36 PM Anderson, Marc via IRT.RegDataPolicy <
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
> 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/20200806/ad90a47f/attachment.html>