[Gnso-epdp-team] Consensus Calls - Cluster 1

Arasteh kavouss.arasteh at gmail.com
Fri Feb 8 19:49:32 UTC 2019


Dear All
Thus point was raised by GAC at various o stances 
But some stakeholder aggressively opposed to that
This is an important issue and needs to be adequately addressed
Regards
Kavouss 

Sent from my iPhone

> On 8 Feb 2019, at 20:02, Ben Butler <bbutler at godaddy.com> wrote:
> 
> Hi Kurt,
>  
> Following deliberations with the SSAC concerning cluster 1 (Purposes), please find below the SSAC comments.  We approve as written Purposes 1, 3-7, seeing no significant security or stability concerns.
>  
> Regarding Purpose 2 (and by extension Recommendation 2), the SSAC provides the following comment:
>  
> SSAC supports the sentiment behind Recommendation 2, but not the language.  The language is flawed and does not provide a clear and actionable recommendation to the GNSO Council and the ICANN Board.  SSAC takes this opportunity to clarify intent and urge that the problems with the language be fixed.
>  
> SSAC believes that the ePDP team shared a common sentiment: that policy-making regarding lawful access of non-public data should definitely proceed now that the gating factors have been addressed. SSAC supports that sentiment.
>  
> There are three problems with Recommendation 2's language:
> It says the group makes a recommendation but then does not say what the recommendation is.  It should clearly recommend that further policy development on the topic take place. The current ambiguity leaves open the prospect that the Recommendation will be misunderstood.
> Recommendation 2 says that "the EPDP team will consider amongst other issues, disclosure in the course of intellectual property infringement and DNS abuse cases."  But that is technically not possible, because the current ePDP is expiring and this ePDP team cannot consider further issues.  Council will need to authorize a new or add-on policy process to complete the unfinished work from the current ePDP.
> It does not address timing or urgency.  The issues were included in the current ePDP’s charter and were supposed to be addressed already but remain unfinished.  The open issue is vital to security and stability, and in SAC104 the SSAC has urged the Council to adopt an ambitious deadline to complete this work.
>  
> We therefore suggest that the first part of the recommendation be something more clear and actionable, such as:
> “The EPDP Team recommends that the Council immediately authorize an additional ePDP to consider a system for Standardized Access to non-public Registration Data (referred to in the Charter as ’Standardised Access’).  This should be designed to fulfill undelivered work items contained in the present EPDP Team Charter.  It will be in line with Purpose #2, and is possible to begin because the gating questions in the charter have been answered.” [footnote to below:]
>  
> [Staff can place the following in the footnote:]
> The above comments are based on statements endorsed by the entire  SSAC, found in:
> * SAC101 Recommendation 1A: "ICANN policy-making should result in a domain registration data policy, including statements of purposes for the collection and publication of the data."
> * SAC101 Recommendation 1D: "The ICANN Board should support the creation of an accredited RDDS access program, with the ICANN Organization ensuring the creation, support of, and oversight of the supporting technical access mechanism. This program will identify qualified users, enable their access under appropriate data protection measures, and will allow RDDS server operators to manage those users’ access accordingly. The technical access mechanism should include a credential management system so that users do not need to negotiate and set up access with RDDS operators individually."
> * SAC101 Recommendation 3: "The ICANN Board and EPDP policy-makers should ensure that security practitioners and law enforcement authorities have access to domain name contact data, via RDDS, to the full extent allowed by applicable law."
> * SAC104: "The SSAC urges the GNSO to begin planning further efforts now, to complete the policy-making that has been started. It is vital to keep momentum. Driven by the GDPR, the EPDP is finally addressing some long-delayed issues. It will not serve the Internet community, or ICANN as a multistakeholder organization, if the work is allowed to drift. We urge the GNSO to begin planning next steps, with specific deliverables and ambitious deadlines for completion." (Section 2.3)
>  
>  
>  
>  
>  
> Thanks,
>  
> -Ben
>  
>  
> From: Gnso-epdp-team <gnso-epdp-team-bounces at icann.org> on behalf of Kurt Pritz <kurt at kjpritz.com>
> Date: Friday, February 8, 2019 at 11:27 AM
> To: GNSO EPDP <gnso-epdp-team at icann.org>
> Subject: Re: [Gnso-epdp-team] Recommendation 13 - Responsibilities of the Parties - email list discussion
>  
> Hi Everyone: 
>  
> To summarize this discussion:
>  
> We have read Trang’s intervention carefully and recognize the wording referenced in the GDPR. In this email chain, we also recognized the research that Thomas (with Farzaneh) conducted in forming their advice to this team and Alan’s reference to local laws and authoritative GDPR guidance.  After considering that, 
>  
> 1) I have not seen any team member representing a Stakeholder Group or Advisory Committee recommend a departure from the use of the word “agreement’ in the recommendation.  I.e., I have not seen support for changing “agreement” to “arrangement.”  Kavouss has made a good faith offer of compromise in suggesting “mutually agreed upon…” but I don’t see the purpose of compromise at this juncture. Without describing the rationale for staying with “agreement,” I can easily see reasons why each SO/AC here  would appreciate that level of specificity. 
>  
> 2) While I agree with the conclusions Thomas has reached regarding the requirement for JCAs, I think the wording currently proposed (by the contracted parities and supported by the GAC) is acceptable in order to provide the parties negotiating the ability to determine which processing steps are best addressed with the parties as Joint Controllers, Controllers and Processors. 
>  
> 3) With regard to concerns about the clause,  “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," as raised by Chris, I don’t read this as meaning that all liability is borne by the Controller, or as Chris states the ICANN Board concern, “by ICANN.” For example, negligence on the part of a processor should not raise liability in the Controller absent some specific circumstances. 
>  
> On this last topic, I think we ae waiting to hear more from the Board or elsewhere in ICANN. Itaking Chris recommendation into account and doing some type of mashup: “Indemnification clauses shall ensure that the risk for certain data processing is borne, to the extent appropriate, by either one or multiple parties that determine the purpose and means of the processing."
>  
>  
> In total:
>  
> 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, to the extent appropriate, 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.
>  
>  
> Please respond and let me know whether you believe this to be an appropriate solution. 
>  
> Best regards,
>  
> Kurt
>  
> 
> 
> On Feb 8, 2019, at 5:05 AM, Emily Taylor <emily.taylor at oxil.co.uk> wrote:
>  
> Hi all
>  
> I support Alan's point of view. While I understand the need to retain flexibility, and to avoid overly restrictive language that will cause problems later on, the word 'arrangement' could mean almost anything - from something that imposes legal benefits and responsibilities to something that's very informal, undocumented and just a way of working.
> 
> So, I support use of the word 'agreement' instead of 'arrangement'.
>  
> Best wishes
> 
> Emily
>  
> On Fri, Feb 8, 2019 at 1:02 PM Alan Woods <alan at donuts.email> wrote:
> Just to be exceptionally clear and although I do not wish to belabor the point any farther, I still submit, on the record, that the correct term to be used in the recommendation is 'AGREEMENT' 
>  
> Whereas I appreciate that ICANN have mirrored the GDPR language of Art 26 in their use of the word of 'arrangement' I believe it would make more sense to consider the subsequent interpretation of their lead DPA (i.e Belgium, as confirmed by the Belgian Autorité de Protection des Données (APD) letter of 15th January 2019  and the therein referenced letter of September 26th, 2018 ).
>  
> I would therefore respectfully submit that it remains more proper for our recommendation to therefore consider and mirror the Belgian legislatures and the APD's interpretation of the GDPR as being our  guiding, if not determinative factor: 
>  
> 1)  Article 52 of the  Loi relative à la protection des personnes physiques à l’égard des traitements de données à caractère personnel (30 July 2018) (see page 27 of the Gazette as linked) requires
>  
>  " Un accord définit de manière transparente les obligations respectives des responsables conjoints de traitement, " [emphasis added], 
>  
> Which translates to "an agreement which defines the respective obligations of the joint controllers" [emphasis added]
>  
> 2) The  APD have also released a legal notation of the July 2018 law, and they note the joint controller requirement as being "par voie d’accord' (see page three under heading   or again to translate, is an "by agreement". (see page 3 under the heading "Responsables conjoints de traitment")
>  
> Therefore I still believe and submit that the ePDP teams original wording of "agreement" should stand, and I don't believe that ICANN's reference to their past statement i.e.  "arrangement” could take the form of an agreement, a policy, or a specification" is sufficient as it dilutes the expectation of the APD. This is not sufficiently specific in the circumstances; nor does it provide the comfort that the ePDP team is seeking in this recommendation from ICANN.
>  
> Kind regards,
>  
> Alan 
>  
>  
>  
>  
>  
>   
>  
>  
> 
> 
> Alan Woods
> 
> Senior Compliance & Policy Manager, Donuts Inc. 
> 
> The Victorians, 
> 
> 15-18 Earlsfort Terrace
> Dublin 2, County Dublin
> Ireland
> 
>     
> 
>  
> 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 Fri, Feb 8, 2019 at 11:28 AM Kavouss Arasteh <kavouss.arasteh at gmail.com> wrote:
> Dear Kurt
> I have indicated at several occasions that when we refer to an action to be performed by two parties / entities ,we need to indicated " as mutually agreed" The proposed text to be amended to read as below
> 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, "AS MUTUALLY AGREED "  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. 
> Please kindly insert that in the text
> Regards
> Kavouss 
>  
> On Thu, Jan 24, 2019 at 12:23 AM Kurt Pritz <kurt at kjpritz.com> 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
> 
>  
> --
> Emily Taylor
> CEO, Oxford Information Labs
> MA (Cantab), Solicitor (non-practising), MBA, 
> 
> Associate Fellow, Chatham House; Editor, Journal of Cyber Policy
> 
> Lincoln House, Pony Road, Oxford OX4 2RD | T: 01865 582885 
> E: emily.taylor at oxil.co.uk | D: 01865 582811 | M: +44 7540 049322
> 
>  
> 
> 
>  
> 
> Registered office: Lincoln House, 4 Pony Road, Oxford OX4 2RD. Registered in England and Wales No. 4520925. VAT No. 799526263
> 
> .
> 
> 
> 
> 
> _______________________________________________
> 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/20190208/e2a11919/attachment-0001.html>


More information about the Gnso-epdp-team mailing list