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: 1. 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. 2. 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. 3. 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@icann.org> on behalf of Kurt Pritz <kurt@kjpritz.com> Date: Friday, February 8, 2019 at 11:27 AM To: GNSO EPDP <gnso-epdp-team@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@oxil.co.uk<mailto:emily.taylor@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@donuts.email<mailto:alan@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 <https://www.icann.org/en/system/files/correspondence/debeuckelaere-to-marby-...> and the therein referenced letter of September 26th, 2018<https://www.icann.org/en/system/files/correspondence/debeuckelaere-to-marby-...> ). 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)<http://www.ejustice.just.fgov.be/cgi_loi/loi_a.pl?language=fr&dt=LOI&cherche...> (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<https://www.autoriteprotectiondonnees.be/sites/privacycommission/files/docum...>, 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 [Donuts Inc.]<http://donuts.domains/> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ________________________________ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland [http://storage.googleapis.com/signaturesatori/icons/facebook.png]<https://www.facebook.com/donutstlds> [http://storage.googleapis.com/signaturesatori/icons/twitter.png] <https://twitter.com/DonutsInc> [http://storage.googleapis.com/signaturesatori/icons/linkedin.png] <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 Fri, Feb 8, 2019 at 11:28 AM Kavouss Arasteh <kavouss.arasteh@gmail.com<mailto:kavouss.arasteh@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@kjpritz.com<mailto:kurt@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@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@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@oxil.co.uk<mailto:emily.taylor@oxil.co.uk> | D: 01865 582811 | M: +44 7540 049322 [https://drive.google.com/a/oxil.co.uk/uc?id=1-3eDLYPfLpkj30Jc34NcbkD1xt8NQpU8&export=download]<http://explore.tandfonline.com/cfp/pgas/rcyb-cfp-2017>[https://docs.google.com/a/oxil.co.uk/uc?id=0B7sS_6djDxsHNm92d21jM21HMDQ&export=download]<http://explore.tandfonline.com/cfp/pgas/rcyb-cfp-2017> 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@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
Question for Ben and SSAC – Does the Council need to authorize another ePDP (expedited)? Or could it simply authorize a subsequent PDP (standard)? Background – As Staff has pointed out, the most significant difference between and ePDP and PDP is that the former does not include an Issues Report, and therefore has a slightly shorter minimum timeline. But once up an running, an ePDP and a standard PDP should operate the same. However, given the time-sensitivities around the expiring Temporary Specification, this ePDP has been given a higher resource priority by ICANN Org and the Community to finish its work. But there’s nothing that says the this couldn’t also be true of a standard PDP. Sorry if my questions make this less clear, but I’m trying to take onboard the other SSAC comments regarding precision of our recommendation language. Thanks— J. ------------- James Bladel GoDaddy From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Ben Butler <bbutler@godaddy.com> Date: Friday, February 8, 2019 at 13:04 To: Kurt Pritz <kurt@kjpritz.com> Cc: GNSO EPDP <gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Consensus Calls - Cluster 1 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: 1. 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. 2. 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. 3. 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@icann.org> on behalf of Kurt Pritz <kurt@kjpritz.com> Date: Friday, February 8, 2019 at 11:27 AM To: GNSO EPDP <gnso-epdp-team@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@oxil.co.uk<mailto:emily.taylor@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@donuts.email<mailto:alan@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 <https://www.icann.org/en/system/files/correspondence/debeuckelaere-to-marby-...> and the therein referenced letter of September 26th, 2018<https://www.icann.org/en/system/files/correspondence/debeuckelaere-to-marby-...> ). 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)<http://www.ejustice.just.fgov.be/cgi_loi/loi_a.pl?language=fr&dt=LOI&cherche...> (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<https://www.autoriteprotectiondonnees.be/sites/privacycommission/files/docum...>, 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 [Donuts Inc.]<http://donuts.domains/> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ________________________________ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland [http://storage.googleapis.com/signaturesatori/icons/facebook.png]<https://www.facebook.com/donutstlds> [http://storage.googleapis.com/signaturesatori/icons/twitter.png] <https://twitter.com/DonutsInc> [http://storage.googleapis.com/signaturesatori/icons/linkedin.png] <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 Fri, Feb 8, 2019 at 11:28 AM Kavouss Arasteh <kavouss.arasteh@gmail.com<mailto:kavouss.arasteh@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@kjpritz.com<mailto:kurt@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@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@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@oxil.co.uk<mailto:emily.taylor@oxil.co.uk> | D: 01865 582811 | M: +44 7540 049322 [https://drive.google.com/a/oxil.co.uk/uc?id=1-3eDLYPfLpkj30Jc34NcbkD1xt8NQpU8&export=download]<http://explore.tandfonline.com/cfp/pgas/rcyb-cfp-2017>[https://docs.google.com/a/oxil.co.uk/uc?id=0B7sS_6djDxsHNm92d21jM21HMDQ&export=download]<http://explore.tandfonline.com/cfp/pgas/rcyb-cfp-2017> 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@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
Dear James This is matter within the remit of the GNSO Council Regards Kavouss On Fri, Feb 8, 2019 at 8:29 PM James M. Bladel <jbladel@godaddy.com> wrote:
Question for Ben and SSAC –
Does the Council need to authorize another *e*PDP (expedited)? Or could it simply authorize a subsequent PDP (standard)?
Background – As Staff has pointed out, the most significant difference between and ePDP and PDP is that the former does not include an Issues Report, and therefore has a slightly shorter minimum timeline. But once up an running, an ePDP and a standard PDP should operate the same.
However, given the time-sensitivities around the expiring Temporary Specification, this ePDP has been given a higher resource priority by ICANN Org and the Community to finish its work. But there’s nothing that says the this couldn’t also be true of a standard PDP.
Sorry if my questions make this less clear, but I’m trying to take onboard the other SSAC comments regarding precision of our recommendation language.
Thanks—
J.
-------------
*James Bladel*
GoDaddy
*From: *Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Ben Butler <bbutler@godaddy.com> *Date: *Friday, February 8, 2019 at 13:04 *To: *Kurt Pritz <kurt@kjpritz.com> *Cc: *GNSO EPDP <gnso-epdp-team@icann.org> *Subject: *[Gnso-epdp-team] Consensus Calls - Cluster 1
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:
1. 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. 2. 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. 3. 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@icann.org> on behalf of Kurt Pritz <kurt@kjpritz.com> *Date: *Friday, February 8, 2019 at 11:27 AM *To: *GNSO EPDP <gnso-epdp-team@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@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@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 <https://www.icann.org/en/system/files/correspondence/debeuckelaere-to-marby-...> and the therein referenced letter of September 26th, 2018 <https://www.icann.org/en/system/files/correspondence/debeuckelaere-to-marby-...> ).
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) <http://www.ejustice.just.fgov.be/cgi_loi/loi_a.pl?language=fr&dt=LOI&cherche...> (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 <https://www.autoriteprotectiondonnees.be/sites/privacycommission/files/docum...>, 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
[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
[image: http://storage.googleapis.com/signaturesatori/icons/facebook.png] <https://www.facebook.com/donutstlds> [image: http://storage.googleapis.com/signaturesatori/icons/twitter.png] <https://twitter.com/DonutsInc> [image: http://storage.googleapis.com/signaturesatori/icons/linkedin.png] <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 Fri, Feb 8, 2019 at 11:28 AM Kavouss Arasteh <kavouss.arasteh@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@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@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@oxil.co.uk | D: 01865 582811 | M: +44 7540 049322
[image: https://drive.google.com/a/oxil.co.uk/uc?id=1-3eDLYPfLpkj30Jc34NcbkD1xt8NQpU...] <http://explore.tandfonline.com/cfp/pgas/rcyb-cfp-2017>[image: https://docs.google.com/a/oxil.co.uk/uc?id=0B7sS_6djDxsHNm92d21jM21HMDQ&expo...] <http://explore.tandfonline.com/cfp/pgas/rcyb-cfp-2017>
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@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
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@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@icann.org> on behalf of Kurt Pritz <kurt@kjpritz.com> Date: Friday, February 8, 2019 at 11:27 AM To: GNSO EPDP <gnso-epdp-team@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@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@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@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@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@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@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
Hi Ben: I have read the SSAC comments carefully. “Flawed language” is often the result of compromise, especially on difficult issues. History is replete with examples of agreements with flawed or vague language that managed to preserve peace or allow significant initiatives benefiting humankind to go forward. This Purpose 2, the wording to which you object, is essentially the crux of the EPDP, a Purpose without which the work of our group fails. The wording was the result of significant compromise and concession by nearly each group in the room. Significantly, the NCSG made the original offer in compromise. Contracted parties first negotiated the wording, then stepped back, then came back to constructively negotiate alternative wording. The CSG, GAC and ALAC agreed to wording that fell short of their goals but established a go forward plan. I think the language here is a remarkable achievement. In the report on the level of consensus to the GNSO, I will note the SSAC agreement to the “sentiment” of Purpose 2 and the objection to the wording. Reopening the wording to group discussion at this time would cause the EPDP work to significantly miss its deadline - along with the consequences attendant to that. I don’t think the SSAC comments have appropriately balanced the risks associated with a re-review of this language as opposed to the benefits of being able to move onto Phase 2 before the Temporary Specification expires. I cannot avoid stating there was significant opportunity for negotiations in Los Angeles, on email lists, and in Toronto where the language was developed and where ample time was provided for alternative views. As I said in the email introducing the consensus calls, this is not intended to be a de novo review of our previous work but an assessment of the level of agreement in our Team when we came to conclusions in Toronto or in our calls. With regard to next steps, the EPDP in not expiring. The Charter clearly provides for Phase 2 where the “standardized access discussion,” is to be discussed. Contingent on some final discussions, we have mostly fulfilled the objectives stated in the first phase of the EPDP work and, in accordance with the Charter, left the access topic to the second phase. The Initial Report was and the Final Report will be clear about the access model that is to be discussed in the next phase. I do not see a need for an additional PDP. Best regards, Kurt
On Feb 8, 2019, at 11:02 AM, Ben Butler <bbutler@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@icann.org <mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Kurt Pritz <kurt@kjpritz.com <mailto:kurt@kjpritz.com>> Date: Friday, February 8, 2019 at 11:27 AM To: GNSO EPDP <gnso-epdp-team@icann.org <mailto:gnso-epdp-team@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@oxil.co.uk <mailto:emily.taylor@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@donuts.email <mailto:alan@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 <https://www.icann.org/en/system/files/correspondence/debeuckelaere-to-marby-...> and the therein referenced letter of September 26th, 2018 <https://www.icann.org/en/system/files/correspondence/debeuckelaere-to-marby-...> ).
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) <http://www.ejustice.just.fgov.be/cgi_loi/loi_a.pl?language=fr&dt=LOI&cherche...> (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 <https://www.autoriteprotectiondonnees.be/sites/privacycommission/files/docum...>, 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
<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 Fri, Feb 8, 2019 at 11:28 AM Kavouss Arasteh <kavouss.arasteh@gmail.com <mailto:kavouss.arasteh@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@kjpritz.com <mailto:kurt@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@icann.org <mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://mm.icann.org/mailman/listinfo/gnso-epdp-team>
Gnso-epdp-team mailing list Gnso-epdp-team@icann.org <mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://mm.icann.org/mailman/listinfo/gnso-epdp-team>
Gnso-epdp-team mailing list Gnso-epdp-team@icann.org <mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team <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@oxil.co.uk <mailto:emily.taylor@oxil.co.uk> | D: 01865 582811 | M: +44 7540 049322
<http://explore.tandfonline.com/cfp/pgas/rcyb-cfp-2017> <http://explore.tandfonline.com/cfp/pgas/rcyb-cfp-2017>
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@icann.org <mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team <https://mm.icann.org/mailman/listinfo/gnso-epdp-team>
Dear Kurt Having read your argument that reaching consensus may results some ambiguity which could be accepted by all as the only available option. As I mentioned I tend to agree with SSAC but if you reflect what you stated in the Report to GNSO "*I will note the SSAC agreement to the “sentiment” of Purpose 2 and the objection to the wording" * I would be happy to go along with the purpose 2 as well ,taking into account comments already made by GAC Regards Kavouss On Fri, Feb 8, 2019 at 11:37 PM Kurt Pritz <kurt@kjpritz.com> wrote:
Hi Ben:
I have read the SSAC comments carefully.
“Flawed language” is often the result of compromise, especially on difficult issues. History is replete with examples of agreements with flawed or vague language that managed to preserve peace or allow significant initiatives benefiting humankind to go forward.
This Purpose 2, the wording to which you object, is essentially the crux of the EPDP, a Purpose without which the work of our group fails. The wording was the result of significant compromise and concession by nearly each group in the room. Significantly, the NCSG made the original offer in compromise. Contracted parties first negotiated the wording, then stepped back, then came back to constructively negotiate alternative wording. The CSG, GAC and ALAC agreed to wording that fell short of their goals but established a go forward plan. I think the language here is a remarkable achievement.
In the report on the level of consensus to the GNSO, I will note the SSAC agreement to the “sentiment” of Purpose 2 and the objection to the wording. Reopening the wording to group discussion at this time would cause the EPDP work to significantly miss its deadline - along with the consequences attendant to that. I don’t think the SSAC comments have appropriately balanced the risks associated with a re-review of this language as opposed to the benefits of being able to move onto Phase 2 before the Temporary Specification expires.
I cannot avoid stating there was significant opportunity for negotiations in Los Angeles, on email lists, and in Toronto where the language was developed and where ample time was provided for alternative views. As I said in the email introducing the consensus calls, this is not intended to be a de novo review of our previous work but an assessment of the level of agreement in our Team when we came to conclusions in Toronto or in our calls.
With regard to next steps, the EPDP in not expiring. The Charter clearly provides for Phase 2 where the “standardized access discussion,” is to be discussed. Contingent on some final discussions, we have mostly fulfilled the objectives stated in the first phase of the EPDP work and, in accordance with the Charter, left the access topic to the second phase. The Initial Report was and the Final Report will be clear about the access model that is to be discussed in the next phase. I do not see a need for an additional PDP.
Best regards,
Kurt
On Feb 8, 2019, at 11:02 AM, Ben Butler <bbutler@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:
1. 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. 2. 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. 3. 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@icann.org> on behalf of Kurt Pritz <kurt@kjpritz.com> *Date: *Friday, February 8, 2019 at 11:27 AM *To: *GNSO EPDP <gnso-epdp-team@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@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@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 <https://www.icann.org/en/system/files/correspondence/debeuckelaere-to-marby-...> and the therein referenced letter of September 26th, 2018 <https://www.icann.org/en/system/files/correspondence/debeuckelaere-to-marby-...> ).
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) <http://www.ejustice.just.fgov.be/cgi_loi/loi_a.pl?language=fr&dt=LOI&cherche...> (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 <https://www.autoriteprotectiondonnees.be/sites/privacycommission/files/docum...>, 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
[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
[image: http://storage.googleapis.com/signaturesatori/icons/facebook.png] <https://www.facebook.com/donutstlds> [image: http://storage.googleapis.com/signaturesatori/icons/twitter.png] <https://twitter.com/DonutsInc> [image: http://storage.googleapis.com/signaturesatori/icons/linkedin.png] <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 Fri, Feb 8, 2019 at 11:28 AM Kavouss Arasteh <kavouss.arasteh@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@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@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@oxil.co.uk | D: 01865 582811 | M: +44 7540 049322
[image: https://drive.google.com/a/oxil.co.uk/uc?id=1-3eDLYPfLpkj30Jc34NcbkD1xt8NQpU...] <http://explore.tandfonline.com/cfp/pgas/rcyb-cfp-2017>[image: https://docs.google.com/a/oxil.co.uk/uc?id=0B7sS_6djDxsHNm92d21jM21HMDQ&expo...] <http://explore.tandfonline.com/cfp/pgas/rcyb-cfp-2017>
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@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
participants (5)
-
Arasteh -
Ben Butler -
James M. Bladel -
Kavouss Arasteh
-
Kurt Pritz