[Gnso-epdp-team] Recommendation 13 - Responsibilities of the Parties - email list discussion

Mon Feb 4 11:41:59 UTC 2019

Deasr Chfris
Thanks for replyx asnd comments
I have had problems with the qualifider such as " as appropriate " due to
the fact that swe do not know who and how it swill be deciddd to be or nmot
to be appropaiate .
I sughgest tzhat thde language in the Kurt^s edit is good if we add by
either party or both parties as mutually agreed
Regards
Kavouss

On Mon, Feb 4, 2019 at 10:58 AM Chris Disspain <
chris.disspain at board.icann.org> wrote:

> Hi Kurt,
>
> I think your suggested language below brings together all of the points of
> view.
>
> I do have one concern regarding the indemnification language
> “Indemnification clauses shall ensure that the risk for certain data
> processing is borne by either one or multiple parties that determine the
> purpose and means of the processing”. This goes beyond my understanding of
> ICANN’s plan to explore ways to possibly reduce risk to the contracted
> parties with respect to providing access to non-public WHOIS data through a
> unified access model. As currently drafted, I think the language might
> prove challenging when it comes time for the Board to consider this
> recommendation.
>
> Trang also raised a related question about indemnification where she noted
> that it’s not clear that liability should necessarily always rest with the
> party or parties that determine the purposes and means of processing, for
> example in the case of a data breach.
>
> I think both of these points could be addressed if the sentence were
> edited to say something to the effect of: “Indemnification should be
> addressed as appropriate as part of the arrangements between ICANN,
> registries, and registrars.”
>
> I hope this makes sense. Happy to discuss as always.
>
>
> Cheers,
>
>
> CD
>
> On 30 Jan 2019, at 19:53, Kurt Pritz <kurt at kjpritz.com> wrote:
>
> Hi Everyone:
>
> To me, it seems as if we are in agreement with a set of principles and a
> variety of wordings will suit our purpose.
>
> I believe we need to point directly  to the thorough work done by several
> of our team that indicates that JCAs are an appropriate solution in many of
> the data processing cases. Before we made any recommendation, we started
> with this analysis of data, purposes, etc.
>
> I also have learned that the responsibilities of the parties (contracted
> parties and ICANN) will vary for each purpose even for each data processing
> step. There is analysis left to go.
>
> Taking into account the Initial Report Recommendation, the work of the
> small group subsequent to that, and the comments on this list,  I’d like to
> settle on the following wording:
>
> "The EPDP Team recommends that ICANN Org develop and implement any
> required data protection arrangements, as appropriate, with the Contracted
> Parties. In addition to the legally required components of such agreement,
> the agreement shall clearly specify the responsibilities of the respective
> parties for the processing activities as described therein. Indemnification
> clauses shall ensure that the risk for certain data processing is borne by
> either one or multiple parties that determine the purpose and means of the
> processing. Due consideration should be given to the analysis carried
> out by the EPDP Team ("Processors, Controllers, Co-Controllers and Joint
> Controllers," above in this Final Report).”
>
> In addition, if Thomas or others wish to augment the analysis in the
> Initial Report with his email that are part of this chain (about avoiding
> liability), we should include that as an individual contribution to the
> team analysis.
>
> It’s my hope we can accept this as a team.
>
> Thanks for letting me weigh in on this and thank for the energy that’s
> gone into this discussion and the others.
>
> Best regards,
>
> Kurt
>
>
>
> On Jan 30, 2019, at 11:22 AM, Heineman, Ashley <AHeineman at ntia.doc.gov>
> wrote:
>
> I won't belabor this, but just to correct the record, the USG does not ask
> that the recommendation be deleted.  It does however specifically express
> concern about the EPDP proposing a "specific legal vehicle (i.e., Joint
> Controller Agreement)."
>
>
> ------------------------------
> *From:* farzaneh badii <farzaneh.badii at gmail.com>
> *Sent:* Wednesday, January 30, 2019 1:57 PM
> *To:* Heineman, Ashley
> *Cc:* Thomas Rickert; gnso-epdp-team at icann.org
> *Subject:* Re: [Gnso-epdp-team] Recommendation 13 - Responsibilities of
> the Parties - email list discussion
>
>  it seems like USG has suggested deleting the whole recommendation. I do
> not see any other opposition against JCA.  h
> ttps://community.icann.org/display/EOTSFGRD/Public+Comment+Review+Tool?preview=/102139731/102139865/gnso-EPDP-pcrt-Initial-Report-REC13_20181228.docx
>
> Unless you agreed on something during the F2F, I don't think we should
> remove JCA because of a single entity opposition - maybe staff can tell us
> if there have been other public comments specifically against JCA.
>
> Farzaneh
>
>
> On Wed, Jan 30, 2019 at 1:48 PM Heineman, Ashley <AHeineman at ntia.doc.gov>
> wrote:
>
> Attaching the narrative version of the USG comments should it be of
> interest.
>
>
>
> Sent from my Verizon, Samsung Galaxy smartphone
>
>
> -------- Original message --------
> From: "Heineman, Ashley" <AHeineman at ntia.doc.gov>
> Date: 1/30/19 13:44 (GMT-05:00)
> To: farzaneh badii <farzaneh.badii at gmail.com>, Thomas Rickert <
> epdp at gdpr.ninja>
> Cc: gnso-epdp-team at icann.org
> Subject: Re: [Gnso-epdp-team] Recommendation 13 - Responsibilities of the
> Parties - email list discussion
>
> For what it is worth,  the USG comments caution against getting into legal
> specifics as they pertain to agreements.
>
>
>
> Sent from my Verizon, Samsung Galaxy smartphone
>
>
> -------- Original message --------
> From: farzaneh badii <farzaneh.badii at gmail.com>
> Date: 1/30/19 13:36 (GMT-05:00)
> To: Thomas Rickert <epdp at gdpr.ninja>
> Cc: gnso-epdp-team at icann.org
> Subject: Re: [Gnso-epdp-team] Recommendation 13 - Responsibilities of the
> Parties - email list discussion
>
> I agree with Thomas.
>
>  I do not agree that we should be after giving "flexibility" to ICANN org
> and CPs. But since some public comments asked for such flexibility, then I
> think we should provide them a framework, the framework should consider (
> as I gather from Alan and Thomas emails) legal, binding instruments that
> minimize the risk of fine and provides the appropriate and legal level of
> data protection for domain name registrants[ - sorry I am being sinful
> today].
> I can live with what Kristina has proposed [Personal opinion] But I also
> want to point out that no one in the public comments is against having JCA.
> So why we are changing that I do not know. I don't think JCA will take away
> flexibility (as .Chris suggests). If we want to give flexibility to org and
> CPs that is fine but we have to provide them with a set of criteria to work
> with. Otherwise, what is the point of this recommendation? They would have
> done agreements and contracts even without it. The law asks them to!
>
> As to Trang's point about indemnification, I am a little confused.  I
> didn't see any ICANN legal concern raised in the public comment, is this a
> new issue being raised now? Are we bringing new issues to the table?
>
>
>
>
>
>
>
>
>
>
>
> Farzaneh
>
>
> On Wed, Jan 30, 2019 at 12:41 PM Thomas Rickert <epdp at gdpr.ninja> wrote:
>
> All,
> I still think it is a mistake to dilute the language from where we were
> before we published the initial report. We are in in the process of
> analyzing public comment and establishing whether the comments received
> require us to amend our report / recommendations. What we heard and read
> were primarily implementation issues, which - as I hope we can agree by now
> - must not guide our decision, but the actually circumstances.
> Additionally, we heard and read about concerns, but no alternative has been
> suggested that would be a better solution to what we agreed on earlier. To
> me, that does not require a change of our recommendation. We are replacing
> a concrete recommendation with something vague without good reason.
>
> Also, the language in our initial report allows for a change of model as
> we had the language in there that our recommendation is subject to further
> legal analysis (or something to that effect).
>
> Thus, the JCA approach should be the starting point and only be deviated
> from if there is a sufficiently robust alternative.
>
> I trust what unites us is the interest in ensuring that no-one in the
> ICANN ecosystem will be fined. Let’s just imagine two scenarios:
>
> 1. We say joint controllers and in fact the parties are independent
> controllers
>
> In this scenario, there should not be any risk for the parties at all.
>
> The reason for this assumption is that the data flows between joint
> controllers need to be legally sound as between third parties (or
> independent controller for that matter). Also, JCAs provide probably the
> highest protection level for data subjects.
>
> 2. We go for independent controllers and in fact a joint controller
> scenario is present
>
> In this case, legal requirements would not be fulfilled. There would be a
> breach that could be sanctioned. In a proceeding with a supervisory
> authority, the authority will surely review the documents publicly
> available, which are eg.:
>
> - a letter from the Art 29 WP suggesting a joint controller scenario might
> be present
> - a memo from Wilson Sonsini pointing in the direction of joint controllers
> - a memo from Hamilton suggesting a joint controller scenario
> - a memo from ICANN quoting from the above and concluding that it should
> be independent controllers nonetheless.
>
> I am afraid that the authorities will then say that we could have known
> that joint controllers should be the way to go and that we increase the
> liability risk for everyone by not doing so.
>
> In other words, we would need to have very good reasons not to go for a
> joint controller scenario. The language in the initial report ensures that.
> The revised language not much so.
>
> Thanks for reading all this.
>
> Best,
> Thomas
>
> PS - In practical terms, I think joint controller agreements can be
> operationalized without insurmountable difficulties. In the long run, we
> should apply for a code of conduct anyway and we could present a different
> approach than joint controllers. If there is blessing for an alternative
> form the authorities via that route or by means of a guidance or other
> confirmation, we can certainly take a different and potentially more
> light-weight approach.
>
>
> Am 30.01.2019 um 14:40 schrieb Alan Woods <alan at donuts.email>:
>
> Dear all,
>
> I am perplexed, if not a little bit frustrated by continuous tendency to
> wordsmith matters out of existence here.
>
> So this end, and regardless of the ultimate settling of Roles and
> Responsibilities can we just go back to basic principles and remind
> ourselves of the GDPR's requirements:
>
> *Art 28:* (processor) "Processing by a processor shall be governed *by a
> contract or other legal act*"*[emphasis added] *
> *Art 26:* (Joint Controllers) "They shall in a transparent manner
> determine their respective responsibilities for compliance with the
> obligations under this Regulation, in particular as regards the exercising
> of the rights of the data subject and their respective duties to provide
> the information referred to in Articles 13 and 14, *by means of an
> arrangement between them*" *[emphasis added] *
>
> I appreciate this is likely where Trang's suggestion is deriving from and
> I have no real issue with the concept of 'Arrangement' - but can we please
> be very clear, that as a contracted party, who's lead DPA is clearly going
> to be Ireland (as will also be the case for a number of other CPs), my
> interpretation MUST be led by the laws which will be applicable to me,
> which is the Data Protection Act, 2018
> <http://www.irishstatutebook.ie/eli/2018/act/7/section/79/enacted/en/html#sec79>.
> Section 79. which states:
>
> "  Where 2 or more controllers jointly determine the purposes and means of
> the processing of personal data (in this Part referred to as “joint
> controllers”), they shall determine their respective responsibilities for
> compliance with this Part in a transparent manner* by means of an
> agreement in writing between them*, save in so far as the said
> responsibilities are determined by the law of the European Union or the law
> of the State. *[emphasis added] *
>
> So regardless of whether or not we are considered Processors, Controllers
> or Joint controllers   at some point in time, CPs will require a Contract
> (or more correctly an addendum to our existing contracts) with ICANN, in
> writing, that governs the processing of data.
>
> So long as it is clear, on the record, that whatever word is used, be it
> agreement, arrangement, or Ketubah, it means a legally binding instrument,
> then I'm fine with it.
>
>
> Kind regards,
>
> Alan
>
>
>
>
>
>
>
>
> [image: Donuts Inc.] <http://donuts.domains/>
> Alan Woods
> Senior Compliance & Policy Manager, Donuts Inc.
> ------------------------------
> The Victorians,
> 15-18 Earlsfort Terrace
> Dublin 2, County Dublin
> Ireland
>
> <https://www.facebook.com/donutstlds>   <https://twitter.com/DonutsInc>
> <https://www.linkedin.com/company/donuts-inc>
>
> Please NOTE: This electronic message, including any attachments, may
> include privileged, confidential and/or inside information owned by Donuts
> Inc. . Any distribution or use of this communication by anyone other than
> the intended recipient(s) is strictly prohibited and may be unlawful.  If
> you are not the intended recipient, please notify the sender by replying to
> this message and then delete it from your system. Thank you.
>
>
> On Tue, Jan 29, 2019 at 1:18 AM Trang Nguyen <trang.nguyen at icann.org>
> wrote:
>
> Thank you, Sarah and Kristina for circulating revised text for
> recommendation 13. We would like to make one additional suggestion: replace
> “…negotiates and enters into required data protection agreements…” with
> “…develop and implement any required data protection arrangements…”
> Referring to an “arrangement” instead of an “agreement” would provide
> greater flexibility during implementation, which might take the form of an
> agreement, a policy, or a specification. Accordingly, the following
> sentence should also refer to “arrangement” instead of “agreement.”
> Also, we would like to ask for clarity on the sentence regarding
> indemnification. Implementation discussions will work out the details of
> allocation of responsibility and liability and it’s not clear that
> liability should necessarily always rest with the party or parties that
> determine(s) the purposes and means of processing, for example in the case
> of a data breach. We look forward to additional discussions with the EPDP
> Team on this.
>
> Dan and Trang
> ICANN Org Liaisons
>
> *From: *Gnso-epdp-team <gnso-epdp-team-bounces at icann.org> on behalf of
> "Rosette, Kristina via Gnso-epdp-team" <gnso-epdp-team at icann.org>
> *Reply-To: *"Rosette, Kristina" <rosettek at amazon.com>
> *Date: *Monday, January 28, 2019 at 5:14 PM
> *To: *"gnso-epdp-team at icann.org" <gnso-epdp-team at icann.org>
> *Subject: *Re: [Gnso-epdp-team] Recommendation 13 - Responsibilities of
> the Parties - email list discussion
>
> All,
>
> Subject to a friendly amendment, RySG supports the RrSG proposed text for
> Recommendation 13.  Our friendly amendment is to change “shall” to “should”
> in the 3rdsentence.
>
> As revised, Recommendation 13 reads:
>
> The EPDP Team recommends that ICANN Org negotiates and enters into
> required data protection agreements, as appropriate, with the Contracted
> Parties. In addition to the legally required components of such agreement,
> the agreement shall specify the responsibilities of the respective parties
> for the processing activities as described therein. Indemnification clauses
> should ensure that the risk for certain data processing is borne by either
> one or multiple parties that determine the purpose and means of the
> processing. Due consideration should be given to the analysis carried out
> by the EPDP Team in its Final Report.
> Kristina
>
> *From:* Gnso-epdp-team [mailto:gnso-epdp-team-bounces at icann.org] *On
> Behalf Of *Sarah Wyld
> *Sent:* Monday, January 28, 2019 3:29 PM
> *To:* gnso-epdp-team at icann.org
> *Subject:* Re: [Gnso-epdp-team] Recommendation 13 - Responsibilities of
> the Parties - email list discussion
>
> Hello All,
> Here is the RrSG's proposed text for Rec 13:
>
> The EPDP Team recommends that ICANN Org negotiates and enters into
> required data protection agreements, as appropriate, with the Contracted
> Parties. In addition to the legally required components of such agreement,
> the agreement shall specify the responsibilities of the respective parties
> for the processing activities as described therein. Indemnification clauses
> shall ensure that the risk for certain data processing is borne by either
> one or multiple parties that determine the purpose and means of the
> processing. Due consideration should be given to the analysis carried out
> by the EPDP Team in its Final Report.
>
> The RrSG is aware that ICANN's status as controller, joint or independent,
> is not yet fully determined. As such, this proposed wording allows the
> flexibility to determine the appropriate type of data protection agreement
> following further input.
>
> --
>
> Sarah Wyld
>
> Domains Product Team
>
> Tucows
>
> +1.416 535 0123 Ext. 1392
>
>
>
>  On 1/23/2019 6:22 PM, Kurt Pritz wrote:
>
> Hi Everyone:
> With the goal of progressing on issues via email, the leadership team has
> considered the discussion provided during the Toronto meeting and suggests
> the following compromise language to address the different positions
> expressed. (This is a resend of an earlier email with only the subject line
> of the email updated.)
> *Discussion*
> The language below is the same language proposed by the small team that
> reviewed the comments, but modified:
>
>    - as suggested by Diane during the meeting to reflect that GDPR Art 28
>    is unlikely to apply in this situation, and
>    - by an addition (bracketed & bolded below) to reference the analysis
>    in the Final Report that this team recommends the creation of Joint
>    Controller Agreements, to appropriately influence the negotiation of
>    GDPR-compliant agreements.
>
>
> This language is intended to strike a balance between those preferring to
> leave some flexibility for ICANN Org and Contracted Parties to consider the
> appropriate agreements and those preferring to be specific about the type
> of agreement to be pursued.
> I understand this is a complex topic that might require additional
> discussion but it is also possible that we cannot be dispositive on this
> issue prior to a lengthy contract formation discussion that extends well
> beyond our time frames. For that reason, we are taking the liberty of
> making this recommendation and hope you accept it in the spirit it is
> offered.
> *Proposed Recommendation #13 Language*
> The EPDP Team recommends that ICANN Org negotiates and enters into
> required data protection agreements such as a Data Processing Agreement
> (GDPR Art. 28) or Joint Controller Agreement (Art. 26), as appropriate,
> with the Contracted Parties. In addition to the legally required components
> of such agreement, the agreement shall specify the responsibilities of the
> respective parties for the processing activities as described therein.
> Indemnification clauses shall ensure that the risk for certain data
> processing is borne by either one or multiple parties that determine the
> purpose and means of the processing. [*Due consideration should be given
> to the analysis carried out by the EPDP Team in its Final Report.*]
> *Action:*
> Please indicate on the mailing list whether you have any concerns about
> these modifications and/or what other aspects of this recommendation should
> be discussed.
> Deadline: Monday, 28 January, additional email discussion might follow
> depending on responses.
> Sincerely,
> Kurt
>
>
>
>
> _______________________________________________
>
> Gnso-epdp-team mailing list
>
> Gnso-epdp-team at icann.org
>
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190204/dacfbbc1/attachment-0001.html>