[Gnso-epdp-legal] Notes and action items from Phase 2 Legal Committee Meeting #2

Fri Jul 26 18:59:53 UTC 2019

Dear all,

This is a friendly reminder for the deadline we have for today.

Kind regards,

León

> El 23 jul 2019, a las 17:24, mail at berrycobb.com escribió:
> 
> Dear EPDP Phase 2 Legal Committee,
>  
> Below, please find the notes and action items from today’s call.
>  
> As a reminder, the next Phase 2 Legal Committee call is scheduled for Tuesday, 06 August at 14:00 UTC.
>  
> Best regards,
>  
> Marika, Berry, and Caitlin
>  
> --
>  
> EPDP Phase 2 Legal Committee Meeting #2
> 
> Proposed Agenda
> 
> Tuesday, 23 July 14:00 UTC
> 
> Action Items/Conclusions
> 
> Brian King to continue work on Action Item #3 from Meeting #1
> Brian King to collaborate with Georgios to fine tune Q6 by incorporating suggestions (e.g., 1. the requestee performs the evaluation, 2. some third party performs the evaluation?), factoring in the point regarding the controllership assumption. 
> Margie Milam to refine Q7, Q9, Q10, Q11, Q12, and Q13 in consultation with the BC and then share the redrafted questions with LC.
> LC to put Q8 on hold pending the outcome of the Board/GNSO consultation process on Purpose 2. 
> LC to review all the questions after their refinement and categorize them to tie to the work in the EPDP Team. 
> LC to close off all the follow up by the end of this week, review redrafted questions and provide further input/comments. 
>  
>  
> Notes & Action Items
> 
> 1. Roll Call & SOI Updates 
> 
> Review of action items from last week 
> Action Item #3: on hold 
> Action Item #4: Berry to follow up with Thomas on this item [COMPLETE]
> Q5 has been put on hold pending further deliberation
> 2. Continued Substantive Review of Priority 1 (SSAD) Legal Questions Submitted to Date
>  
> a) Substantive review of SSAD questions (beginning where LC left off last week)
>  
> Q6. Within the context of an SSAD, in addition to determining its own lawful basis for disclosing data, does the requestee (entity that houses the requested data) need to assess the lawful basis of the third-party requestor? (Question from ICANN65 from GAC/IPC)
>  
> It gets to the liability of the contracted part/third party that is doing the disclosing of the data. It is an important question to have. 
> Have issue with this question. It is all about the balancing test. 
> The question includes the assumption that the entity that houses the data is the entity that does the request. It may or may not be valid. The LC should review this assumption and see whether it is correct. 
> The second half is vague, ie., “Need to assess…” If the answer is yes, what the legal consequences would be? The question right now is incomplete. 
> Insert “or” between “requestee” and “entity”. 
> Someone needs to assess the lawful basis. To what extent the party/system that weighs the request needs to affirmably investigate the requestee’s lawful basis. How much does the entity evaluate the requests needs to do it on its own. How much can be automated based on the accreditation scheme. 
> This question was put in a wider context regarding whether the requestee holds any liability, and if the requestor is not acting in compliance with GDPR requirement. 
> The question is aimed at different objectives. Perhaps set it out more generally. Assuming there is a following structure, clarify who the potential participants could be, and develop follow up questions. 
> Perhaps the question could be amended to include both options? 1) The requestee performs the evaluation and 2) some third party performs the evaluation?
> 
> A requestor may ask for disclosure, and a requestor may mishandle information after it is provided. What is the liability for the requestee who discloses the information?
> In the context of SSAC, assuming ICANN would be the requestor, we should add some element speaking about the control issue. Requestee should exercise the role as processor. Need to build in controllership into the question. 
> The EPDP Team hasn’t completed the work about the controllership question, unknown how the arrangement would playout, so the question should not include any preset assumptions regarding who the controller/joint controller is. Perhaps wait to build this element in after the question is refined based on Berry and Kristina’s suggestions? 
> If build in controllership, urge against making assumptions that are ahead of policy making results. 
> It might be helpful to collaborate with Georgios too, as they (GAC) were also an author of this question?
> ACTION ITEM: Brian King to collaborate with Georgios to fine tune Q6 by incorporating Berry and Kristina’s suggestions (e.g., 1. the requestee performs the evaluation, 2. some third party performs the evaluation?), factoring in Tatiana’s point regarding controllership assumption. 
>  
> Q7. To what extent, if any, are contracted parties accountable when a third party misrepresents their intended processing, and how can this accountability be reduced? (BC)
> Uncomfortable with the phrase “accountability being reduced”. Need to ask about what steps should be taken to address accountability issue and risks about accountability. Should “liability” be used instead of “accountability”? Yes, it should be liability instead. 
> The question needs more detail for clarity to actually receive useful answers. Clarification on third party, processing of what, etc. The proponent needs to fine tune and clarify it first before the LC processes it. 
> Would it help if the question provides an almost real world example?
> 
> ACTION Item: Margie Milam to refine Q7 in consultation with the BC. 
>  
> 
>                             Q8. BC Proposes that the EPDP split Purpose 2 into two separate purposes:
>  
> ·        Enabling ICANN to maintain the security, stability, and resiliency of the Domain Name System in accordance with ICANN’s mission and Bylaws though the controlling and processing of gTLD registration data. 
>  
> ·        Enabling third parties to address consumer protection, cybersecurity, intellectual property, cybercrime, and DNS abuse involving the use or registration of domain names. counsel be consulted to determine if the restated purpose 2 (as stated above) 
>  
> Can legal counsel be consulted to determine if the restated purpose 2 (as stated above) is possible under GDPR?   If the above language is not possible, are there suggestions that counsel can make to improve this language? (BC)
>  
> Should not conflate the 3rd party purposes with ICANN’s purpose. Regarding the last part of the question, what if the concept is not impossible? We are making an assumption that the problem can be fixed by fine tuning the language. 
> Purpose 2 is the result of hundreds of hours of heated negotiation and discussion. LC is not the appropriate place to relitigate Purpose 2. 
> The genesis of the question is what happens to Purpose 2 in terms of Board resolution. Purpose 2 hasn’t been resolved. Defer this question after the Board resolves Purpose 2 after the consultation with the GNSO Council. 
> Won’t mind tabling this question. As long as it’s not a ticking bomb and we agree that there might be no question at all at the end.
>  We have to revisit this in a full WG instead of the shortcuts via legal counsel. 
> The LC should not analyze the positions of individual groups. The second part of the question is problematic. 
> It is a legal question that came from the EC letter 
> on how Purpose 2 should be rewritten to comply with GDPR. Present it that way and get the full EPDP to sign off on presenting it as a legal question. 
> ACTION ITEM: LC to put Q8 on hold pending the outcome of the Board/GNSO consultation process on Purpose 2. 
>  
> Q9. Can legal analysis be provided on how the balancing test under 6(1)(f) is to be conducted, and under which circumstances 6(1)(f) might require a manual review of a request? (BC)
> Can the balancing test be automated? Under what circumstances it may require a manual review? The question needs to clarify these points. 
> ACTION ITEM: Margie Milam to refine Q9 in consultation with the BC. 
>  
> Q10. If not all requests benefit from manual review, is there a legal methodology to define categories of requests (e.g. rapid response to a malware attack or contacting a non-responsive IP infringer) which can be structured to reduce the need for manual review? (BC)
> It can be consolidated with Q9? 
> There are certain number of cases that the EPDP Team has been working on. Certain manual review is not necessary. Put down those examples for the Legal Counsel to review. The question is phrased too generally, better framed with certain examples the EPDP Team has been working on. 
> Replace “benefit from” with “require”?
> 
> ACTION ITEM: Margie Milam to refine Q10 in consultation with the BC. 
>  
> Q11. Can legal counsel be consulted to determine whether GDPR prevents higher volume access for properly credentialed cybersecurity professionals, who have agreed on appropriate safeguards?  If such access is not prohibited, can counsel provide examples of safeguards (such as pseudonymization) that should be considered? (BC)
> The question has the same concept not limited to cyber security, but also expanded to other user groups. 
> Why did we not define “properly credentialed cyber security professionals”? The question is very vague and broad, hard to answer. 
> Also need to clarify what it means by “higher volume access”. 
> ACTION ITEM: Margie Milam to refine Q11 in consultation with the BC.
>  
> Q12. To identify 6(1)(b) as purpose for processing registration data, we should follow up on the B & B advice that- “it will be necessary to require that the specific third party or at least the processing by the third party is, at least abstractly, already known to the data subject at the time the contract is concluded and that the controller, as the contractual partner, informs the data subject of this prior to the transfer to the third party”
>  
> B&B should clarify why it believes that the only basis for providing WHOIS is for the prevention of DNS abuse.  Its conclusion in Paragraph 10 does not consider the other purposes identified by the EPDP in Rec 1, and, in any event should consider the recent EC recognition that ICANN has a broad purpose to:
>  
> ‘contribute to the maintenance of the security, stability, and resiliency of the Domain Name System in accordance with ICANN's mission’, which is at the core of the role of ICANN as the “guardian” of the Domain Name System.”
>  
> This question can be a follow up relating to previous advice from B&B. See legal memos here: https://community.icann.org/x/thFIBg <https://community.icann.org/x/thFIBg>. Legal advice. 6.1.b was one of the first from B&B.
>  It might be helpful to identify all clarifications of prior memos to consider as a single submission?
> Identify more specifically about the B&B advice in this question before following up. 
> More helpful to turn the 2nd and 3rd paragraph into questions. 
> Q12 and Q13 need to be redrafted and rescoped. 
> ACTION ITEM: Margie Milam to refine Q12 in consultation with the BC. 
>  
> Q13.  B&B should advise on the extent to which GDPR’s public interest basis 6(1)e is applicable, in light of the EC’s recognition that:
> “With regard to the formulation of purpose two, the European Commission acknowledges ICANN’s central role and responsibility for ensuring the security, stability and resilience of the Internet Domain Name System and that in doing so it acts in the public interest.”
> All questions should be tied to the work in the EPDP Team. 
> ACTION ITEM: Margie Milam to refine Q13 in consultation with the BC.
> ACTION ITEM: LC to review all the questions after their refinement and categorize them to tie to the work in the EPDP Team. 
>  
> 
> b) Revisit previous week’s questions if edited versions are available and time allows
>  
> 
> c) Agree on next steps
> ACTION ITEM: LC to close off all the follow up by the end of this week, review redrafted questions and provide further input/comments. 
>  
> 
> 3. Wrap and confirm next meeting to be scheduled 
> a) Confirm action items
> b) The next LC Meeting will take place on Tuesday, 6 August at 14:00 UTC.
>  
> _______________________________________________
> Gnso-epdp-legal mailing list
> Gnso-epdp-legal at icann.org <mailto:Gnso-epdp-legal at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-epdp-legal <https://mm.icann.org/mailman/listinfo/gnso-epdp-legal>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://www.icann.org/privacy/tos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-legal/attachments/20190726/592c5ac9/attachment-0001.html>