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

Wed Jan 30 18:57:23 UTC 2019

 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 3rd sentence.
>>>
>>>
>>>
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190130/ae59d59b/attachment-0001.html>