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

Sun Feb 10 09:31:24 UTC 2019

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 at 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 at godaddy.com> wrote:
>
> Hi Kurt,
>
> Following deliberations with the SSAC concerning cluster 1 (Purposes),
> please find below the SSAC comments.  We approve as written Purposes 1,
> 3-7, seeing no significant security or stability concerns.
>
> Regarding Purpose 2 (and by extension Recommendation 2), the SSAC provides
> the following comment:
>
> SSAC supports the sentiment behind Recommendation 2, but not the
> language.  The language is flawed and does not provide a clear and
> actionable recommendation to the GNSO Council and the ICANN Board.  SSAC
> takes this opportunity to clarify intent and urge that the problems with
> the language be fixed.
>
> SSAC believes that the ePDP team shared a common sentiment: that
> policy-making regarding lawful access of non-public data should definitely
> proceed now that the gating factors have been addressed. SSAC supports that
> sentiment.
>
> There are three problems with Recommendation 2's language:
>
>    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 at icann.org> on behalf of
> Kurt Pritz <kurt at kjpritz.com>
> *Date: *Friday, February 8, 2019 at 11:27 AM
> *To: *GNSO EPDP <gnso-epdp-team at icann.org>
> *Subject: *Re: [Gnso-epdp-team] Recommendation 13 - Responsibilities of
> the Parties - email list discussion
>
> Hi Everyone:
>
> To summarize this discussion:
>
> We have read Trang’s intervention carefully and recognize the wording
> referenced in the GDPR. In this email chain, we also recognized the
> research that Thomas (with Farzaneh) conducted in forming their advice to
> this team and Alan’s reference to local laws and authoritative GDPR
> guidance.  After considering that,
>
> 1) I have not seen any team member representing a Stakeholder Group or
> Advisory Committee recommend a departure from the use of the word
> “agreement’ in the recommendation.  I.e., I have not seen support for
> changing “agreement” to “arrangement.”  Kavouss has made a good faith offer
> of compromise in suggesting “mutually agreed upon…” but I don’t see the
> purpose of compromise at this juncture. Without describing the rationale
> for staying with “agreement,” I can easily see reasons why each SO/AC here
> would appreciate that level of specificity.
>
> 2) While I agree with the conclusions Thomas has reached regarding the
> requirement for JCAs, I think the wording currently proposed (by the
> contracted parities and supported by the GAC) is acceptable in order to
> provide the parties negotiating the ability to determine which processing
> steps are best addressed with the parties as Joint Controllers, Controllers
> and Processors.
>
> 3) With regard to concerns about the clause,  “Indemnification clauses
> shall ensure that the risk for certain data processing is borne by either
> one or multiple parties that determine the purpose and means of the
> processing," as raised by Chris, I don’t read this as meaning that all
> liability is borne by the Controller, or as Chris states the ICANN Board
> concern, “by ICANN.” For example, negligence on the part of a processor
> should not raise liability in the Controller absent some specific
> circumstances.
>
> On this last topic, I think we ae waiting to hear more from the Board or
> elsewhere in ICANN. Itaking Chris recommendation into account and doing
> some type of mashup: “Indemnification clauses shall ensure that the risk
> for certain data processing is borne, *to the extent appropriate*, by
> either one or multiple parties that determine the purpose and means of the
> processing."
>
>
> In total:
>
> The EPDP Team recommends that ICANN Org negotiates and enters into
> required data protection agreements, as appropriate, with the
> Contracted Parties. In addition to the legally required components of such
> agreement, the agreement shall specify the responsibilities of the
> respective parties for the processing activities as described
> therein. Indemnification clauses should ensure that the risk for certain
> data processing is borne, to the extent appropriate, by either one
> or multiple parties that determine the purpose and means of the processing.
> Due consideration should be given to the analysis carried out by the
> EPDP Team in its Final Report.
>
>
> Please respond and let me know whether you believe this to be an
> appropriate solution.
>
> Best regards,
>
> Kurt
>
>
>
> On Feb 8, 2019, at 5:05 AM, Emily Taylor <emily.taylor at oxil.co.uk> wrote:
>
> Hi all
>
> I support Alan's point of view. While I understand the need to retain
> flexibility, and to avoid overly restrictive language that will cause
> problems later on, the word 'arrangement' could mean almost anything - from
> something that imposes legal benefits and responsibilities to something
> that's very informal, undocumented and just a way of working.
>
> So, I support use of the word 'agreement' instead of 'arrangement'.
>
> Best wishes
>
> Emily
>
> On Fri, Feb 8, 2019 at 1:02 PM Alan Woods <alan at donuts.email> wrote:
>
> Just to be exceptionally clear and although I do not wish to belabor the
> point any farther, I still submit, on the record, that the correct term to
> be used in the recommendation is 'AGREEMENT'
>
> Whereas I appreciate that ICANN have mirrored the GDPR language of Art 26
> in their use of the word of 'arrangement' I believe it would make more
> sense to consider the subsequent interpretation of their lead DPA (i.e
> Belgium, as confirmed by the Belgian Autorité de Protection des Données
> (APD) letter of 15th January 2019
> <https://www.icann.org/en/system/files/correspondence/debeuckelaere-to-marby-15jan19-en.pdf> and
> the therein referenced letter of September 26th, 2018
> <https://www.icann.org/en/system/files/correspondence/debeuckelaere-to-marby-26sep18-en.pdf>
>  ).
>
> 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&chercher=t&choix1=ET&fr=f&choix2=ET&numero=12&table_name=LOI&fromtab=loi_all&imgcn.x=32&DETAIL=2018073046/F&nm=2018040581&imgcn.y=3&ddda=2018&sql=dt+contains++%27LOI%27+and+dd+=+date%272018-07-30%27and+actif+=+%27Y%27&rech=12&tri=dd+AS+RANK+&trier=promulgation&dddj=30&cn=2018073046&row_id=1&caller=image_a1&dddm=07&la=F&pdf_page=10&pdf_file=http://www.ejustice.just.fgov.be/mopdf/2018/09/05_1.pdf> (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/documents/Notions_RT_ST.pdf>,
> 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 at gmail.com>
> wrote:
>
> Dear Kurt
> I have indicated at several occasions that when we refer to an action to
> be performed by two parties / entities ,we need to indicated " as mutually
> agreed" The proposed text to be amended to read as below
> The EPDP Team recommends that ICANN Org negotiates and enters into
> required data protection agreements such as a Data Processing Agreement
> (GDPR Art. 28) or Joint Controller Agreement (Art. 26), as appropriate,
> with the Contracted Parties. In addition to the legally required components
> of such agreement, the agreement shall specify the responsibilities of the
> respective parties for the processing activities as described therein.
> Indemnification clauses shall ensure that the risk for certain data
> processing is borne by either one or multiple parties, "AS MUTUALLY AGREED
> "  that determine the purpose and means of the processing. [*Due
> consideration should be given to the analysis carried out by the EPDP Team
> in its Final Report.*]
> *Action:*
> Please indicate on the mailing list whether you have any concerns about
> these modifications and/or what other aspects of this recommendation should
> be discussed.
> Deadline: Monday, 28 January, additional email discussion might follow
> depending on responses.
> Please kindly insert that in the text
> Regards
> Kavouss
>
> On Thu, Jan 24, 2019 at 12:23 AM Kurt Pritz <kurt at kjpritz.com> wrote:
>
> Hi Everyone:
> With the goal of progressing on issues via email, the leadership team has
> considered the discussion provided during the Toronto meeting and suggests
> the following compromise language to address the different positions
> expressed. (This is a resend of an earlier email with only the subject line
> of the email updated.)
> *Discussion*
> The language below is the same language proposed by the small team that
> reviewed the comments, but modified:
>
>    - as suggested by Diane during the meeting to reflect that GDPR Art 28
>    is unlikely to apply in this situation, and
>    - by an addition (bracketed & bolded below) to reference the analysis
>    in the Final Report that this team recommends the creation of Joint
>    Controller Agreements, to appropriately influence the negotiation of
>    GDPR-compliant agreements.
>
>
> This language is intended to strike a balance between those preferring to
> leave some flexibility for ICANN Org and Contracted Parties to consider the
> appropriate agreements and those preferring to be specific about the type
> of agreement to be pursued.
> I understand this is a complex topic that might require additional
> discussion but it is also possible that we cannot be dispositive on this
> issue prior to a lengthy contract formation discussion that extends well
> beyond our time frames. For that reason, we are taking the liberty of
> making this recommendation and hope you accept it in the spirit it is
> offered.
> *Proposed Recommendation #13 Language*
> The EPDP Team recommends that ICANN Org negotiates and enters into
> required data protection agreements such as a Data Processing Agreement
> (GDPR Art. 28) or Joint Controller Agreement (Art. 26), as appropriate,
> with the Contracted Parties. In addition to the legally required components
> of such agreement, the agreement shall specify the responsibilities of the
> respective parties for the processing activities as described therein.
> Indemnification clauses shall ensure that the risk for certain data
> processing is borne by either one or multiple parties that determine the
> purpose and means of the processing. [*Due consideration should be given
> to the analysis carried out by the EPDP Team in its Final Report.*]
> *Action:*
> Please indicate on the mailing list whether you have any concerns about
> these modifications and/or what other aspects of this recommendation should
> be discussed.
> Deadline: Monday, 28 January, additional email discussion might follow
> depending on responses.
> Sincerely,
> Kurt
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>
>
>
> --
> *Emily Taylor*
> CEO, Oxford Information Labs
> *MA (Cantab), Solicitor (non-practising), MBA, *
> *Associate Fellow, Chatham House; Editor, Journal of Cyber Policy*
>
> Lincoln House, Pony Road, Oxford OX4 2RD | T: 01865 582885
> E: emily.taylor at oxil.co.uk | D: 01865 582811 | M: +44 7540 049322
>
>
> [image:
> https://drive.google.com/a/oxil.co.uk/uc?id=1-3eDLYPfLpkj30Jc34NcbkD1xt8NQpU8&export=download]
> <http://explore.tandfonline.com/cfp/pgas/rcyb-cfp-2017>[image:
> 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 at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190210/bff9e562/attachment-0001.html>