<div dir="ltr">Dear all, <div><br></div><div><b>Recommendation 12 (removal of the word 'REQUESTS')</b></div><div><br></div><div>Whereas I appreciate Ashley's reasoning, I so not support removal of the reference to "requests". The process and the recommendation are linked wholly to the making of the request, and ensuring that those person who wish to rely on such requests have some form of assurance that the contracted parties will not 'ignore' such requests.  The way it is currently read, poses a worry that it suggests that the policy may interfere in the actual decision relating to disclosure or not. This decision will be a decision of the contracted party alone, and should that decision be incorrect, or someone feels aggrieved by the substantive decision, their recourse will never be to ICANN, only to a DPA, or the courts, to complain about failing to meet a legal obligation contained with a EEA regulation.  Our purpose here is to ensure that a requester has certain guarantees about the procedural, how to make, where to make, how long generally, and the reasoning a decision is made that does not favor release. </div><div><br></div><div><br></div><div><b>Civil claim requests only</b></div><div><b><br></b></div><div>Regarding Thomas' addition, I would support what he has stated and is trying to achieve. </div><div><br></div><div>Law Enforcement dealing with matters of criminal cases should never feel like they need to rely on the process as outlined in Recommendation 12. The CPs (again noting the Good actors in the space --- the others are beyond my reach) will always engage with LEAs and discuss access for lawful reasons and the process by which we need to figure this figuring this out - also this is already a requirement of the RAs under Spec 11 for the most part. I find that this conversation is huge overreach for the ePDP. </div><div><br></div><div>With that I would make the following statements in support of Thomas' assertion (i.e. LEA's may make requests as the law allows / requires): </div><div><br></div><div>1) Any law enforcement official, in the course of their duties as an officer of the law, is acting in the public interest, and the paragraph proceeding Art 6(1)f is very clear </div><div>"<i>Point (f) of the first subparagraph shall not apply to processing carried out by public authorities in the performance of their tasks.</i>" Therefore any request from a LEA based on 6(1)(f) for EEA data will be automatically deemed as not having a legal basis. <br></div><div><br></div><div>2)LEAs who wish access to data, and where such a LEA does not have jurisdiction then it is for them to go through the proper legal channels to request access. As LEAs, such requests will ALWAYS be considered a public authority exercising their interest under either  6(1)(c) , (d) or (e) as the remaining basis for such requests:</div><div><br></div><div><b>a) 6(1)(c)</b> - <i><b>processing is necessary for compliance with a legal obligation to which the controller is subject</b></i> - legal basis will have to be established (this related to EEA data only, however jurisdiction of both the LEA and the CP are necessary considerations here) (recommendation 12 process is unnecessary) </div><div><b>b) 6(1)(d) </b>- <b><i>processing is necessary in order to protect the vital interests of the data subject or of another natural person;</i></b> again only applicable to EEA data, but again I do urge law enforcement who are making such access requests to consider that in order to justify 'vital interest protection' we are looking at time sensitive matters and a very high bar, and surely in such urgent situations LEA should be reliant on other mechanisms that don't rely on the process of recommendation 12.</div><div><b>c) 6(1)(e)<i> Public interest - as per Art 6(3)</i></b> this interest must be based on EU or Member State law - To be frank, in this instance properly establish Public Interest Requests under 6(1)(e) should never have to go through the recommendation 12 process. LEAs should be ringing the front doorbell with such requests, and any CP should be jumping through hoops to see to them. We also don't require ICANN to tell us to do this. If we fail to meet such requests, censure from ICANN compliance will be the least of our worries. </div><div><br></div><div>So frankly, recommendation 12 is aimed at providing process for civil claims. I understand the apparent feeling that LEA's are 'left out in the cold' by this; however, this could not be farther from the truth. LEAs should be making the CPs jump through the hoops, not vice versa. And if the LEA does not have the legal basis, or authority to make us jump through said hoops, then the LEA should be wondering about the basis for their request, and far more 'non-epdp' matters such as the admissibility of their evidence and the fruits of the poison tree.<br></div><div><br></div><div>Alan </div><div><br></div><div><br></div><div>PS and optional to the extreme, but where non-EEA data may not be 'protected' by the GDPR, and we are stating that a LEA may assert their 'authority' to access that data under recommendation 12, we are encroaching onto a very unstable ground. To be clear, CPs are not guardians of the privacy rights of their registrant, nor am I saying should we second guess the laws of other nations; however, I would urge the ePDP team to think of the unintended consequences here. We do not wish to make this process difficult, however not all LEAs are 'good' players, and a CP should be mindful that the effect that our releases may have, to all data subjects, regardless whether or not the GDPR or similar law applies. I would suspect that this is something that the ALAC and the NCSG would be very supportive of. e.g. As a registry operator, should I provide a representative of certain Law Enforcement Authority of a certain African nation with the redacted data of registrant who is has a TLD associated with fighting for LGBT rights in that particular African nation? Or should we insist upon a Subpoena from an authority who can compel me to do so - or feel free to not respond until we approached through 'formal channels',  which the expansion of recommendation 12 would not allow us to do? Should we make this part of our recommendation that ICANN can see fit to compel us to answer such requests simply because they come from a LEA? I leave this as a post script only, speaking in a personal capacity, as this area is far too much of a minefield, and is a huge area of global concern for us regardless of the GDPR reach, and for a separate forum! We should ensure and be stead fast in requiring strict legal procedures for LEA requests (which the CPs are exceptionally willing to discuss and sort out), and therefore not allow recommendation 12 to unnecessarily side step such a discussion. </div><div><br></div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><table style="padding:0px;margin:10px 0;border:none"><tbody><tr><td style="vertical-align:middle;padding:0px 7px 0px 0px"><a href="http://donuts.domains" rel="nofollow" target="_blank"><img alt="Donuts Inc." height="75" src="https://storage.googleapis.com/signaturesatori/customer-C02zzlf7k/images/-54f9d8ac97e7f575bf497d10ac1f1aafafddf8afceab5f269d49034f01b3217b.png" width="75"></a></td><td style="vertical-align:middle;padding:0px 7px 0px 0px;text-align:left">
                        <div style="font-family:'tahoma',sans-serif;font-size:14px;line-height:17px;font-weight:bold;color:black"><span style="font-size:12px"><span style="font-family:'arial','helvetica',sans-serif"><span style="color:rgb(51,51,51)">Alan Woods</span></span></span></div>

                        <div><span style="font-size:12px"><span style="font-family:'arial','helvetica',sans-serif"><span style="color:#333333">Senior Compliance & Policy Manager, Donuts Inc.</span></span></span>

                        <hr><span style="font-size:11px"><span style="font-family:'arial','helvetica',sans-serif"><span style="color:#333333">The Victorians, </span></span></span></div><div><font color="#333333" face="arial, helvetica, sans-serif"><span style="font-size:11px">15-18 Earlsfort Terrace<br style="background-color:rgb(34,34,34)">
                        Dublin 2, County Dublin</span></font><br style="color:rgb(214,214,214);font-family:'open sans';font-size:12px;background-color:rgb(34,34,34)"><font color="#333333" face="arial, helvetica, sans-serif"><span style="font-size:11px">
                        Ireland</span></font><br>
                        <span style="font-size:11px"><span style="font-family:'arial','helvetica',sans-serif"></span></span><br>
                        <span style="line-height:36px"><a href="https://www.facebook.com/donutstlds" rel="nofollow" target="_blank"><img src="http://storage.googleapis.com/signaturesatori/icons/facebook.png"></a>  <a href="https://twitter.com/DonutsInc" rel="nofollow" target="_blank"><img src="http://storage.googleapis.com/signaturesatori/icons/twitter.png"></a>  </span><a href="https://www.linkedin.com/company/donuts-inc" rel="nofollow" target="_blank"><span style="font-size:14px"><img src="http://storage.googleapis.com/signaturesatori/icons/linkedin.png"></span></a></div>
                        </td></tr></tbody></table><br>
</div><div><span style="font-size:12pt;font-family:Cambria,serif">Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . </span><span style="font-size:12pt;font-family:Cambria,serif">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.</span><br></div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 10, 2019 at 8:56 PM Thomas Rickert <epdp@gdpr.ninja> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Hi Kurt, Ashley, all,<div>thanks in particular to Kurt and Ashley for their analysis and suggestions. </div><div><br></div><div>To be clear, It was not my intention to rule out LEA disclosures or establish hurdles for those. The opposite is true: We should not give the impression that contracted parties would only honor disclosure requests if the requirements in our recommendation 12 are met even if LEA requirements for requesting data would be lower. It would be inappropriate for us even to give the impression that we would ask LEAs to give more or other data than they are required to by law for their disclosure requests. </div><div><br></div><div>Let me suggest language that I hope meets Ashley’s requirements while not going into too much details on the legal rationales that I have offered during our call.</div><div><br></div><div>"Whilst the EPDP Team is confident that the criteria enumerated in this recommendation work for data disclosure requests relating to civil claims, the EPDP Team did not yet have an opportunity work on policy for LEA disclosure requests. It may well be that LEA disclosure requests can be honored following the criteria in this recommendation, but there may be different criteria or processes that need to be followed depending on the jurisdiction of the requesting LEA, the alleged crimes involved and the location of the contracted party as a condition for the contracted party to be entitled to or be required to disclose data."</div><div><br></div><div>We could either put this into the text of the recommendation or make it a footnote, but I think that a disclaimer of some sort is warranted for the sake of transparency with respect to the status of our recommendation and our work.</div><div><br></div><div>I hope you find this helpful,</div><div>Thomas</div><div><br><div><div><div><br><blockquote type="cite"><div>Am 08.02.2019 um 17:04 schrieb Kurt Pritz <<a href="mailto:kurt@kjpritz.com" target="_blank">kurt@kjpritz.com</a>>:</div><br class="gmail-m_-698077310791482284Apple-interchange-newline"><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">Thanks for this additional input on Recommendation 13.  Please forgive these observations and consider this recommendation for closing off this remaining issue. </span><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">During our meeting Thomas was given the floor to explain his edits. During that, there was the usual chat going on: first some non-substantive commentary, then a different discussion. Partially through Thomas’ intervention, I shook myself out of watching the chat to listen to Thomas, who was making a careful, studied explanation of his addition. I kicked myself (figuratively) for missing part his explanation when, in a few months, any of us would probably give a lot to have Thomas available to answer questions such as these. It made we wonder how many of us were watching the chat instead of listening. </div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">Understanding Thomas point, I made the suggestion to the group that we retain it in some form (a more complete explanation of the issue) but move it down into the body of the recommendation as an item to be considered. At that point, my sense was that the team wanted to leave it first and foremost and I withdrew my suggestion to move it. </div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">Having said that, I understand Ashley’s comment that we don’t have a full handle on the effect of the GDPR sections Thomas cited on out recommendations. </div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">I recommend that we: </div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><ul class="gmail-m_-698077310791482284MailOutline"><li>respectfully ask Thomas to augment the issue somewhat with a couple / few sentences. </li><li>move that issue to the annotation describing the recommendation with a notation that this issue be sorted out during the implementation discussion. </li></ul><div><br></div><div>Let me know what you think. </div><div><br></div><div>Best regards,</div><div><br></div><div>Kurt</div><div><br></div><div><br><blockquote type="cite"><div><br></div><div><div><br>At 07/02/2019 03:52 PM, Heineman, Ashley wrote:<br><br><blockquote type="cite" class="gmail-m_-698077310791482284cite">Thanks for this and hello colleagues,<br> <br>After further reflection on today’s discussion of Recommendation 12 and the new text proposed by Thomas, I believe this language should be deleted.   Specifically –“ â€œThese criteria are applicable to disclosure requests relating to civil claims. LEA requests will be handled according to applicable laws.† <span class="gmail-m_-698077310791482284Apple-converted-space"> </span><br> <br>While I am extremely pleased with the state of the Recommendation overall, this new insertion has not been fully considered and I believe is misplaced. <span class="gmail-m_-698077310791482284Apple-converted-space"> </span><br> <br>I understand and am sympathetic to Thomas’ concerns, but that being said, I believe those concerns are best addressed elsewhere. The singular intent of Recommendation 12 is to provide clarity around the process and expectations of reasonable lawful disclosure in terms of making requests.  The recommendation attempts to ensure that expectations are set for how to submit requests and in what fashion those requests will be handled once received.  The Recommendation does NOT assume that disclosure will be made and, further, it isn’t even contemplated how and on what basis a decision for disclosing (or not) will be made. Those issues are to be dealt with in Phase 2 and/or otherwise in a specific access discussion.<br> <br>I’m thus concerned that by explicitly limiting this recommendation to civil requests will unfairly and unnecessarily remove the benefits of process clarity for LEA.  <span class="gmail-m_-698077310791482284Apple-converted-space"> </span><br> <br>In light of these concerns, I strongly recommend the deletion of this text.  Thomas’ legitimate concerns should then be taken up and addressed in our Phase 2 work.<br> <br>Thanks!<br> <br>Ashley<br>202 482 0298<br> <br><b>From:</b><span class="gmail-m_-698077310791482284Apple-converted-space"> </span>Gnso-epdp-team <<a href="mailto:gnso-epdp-team-bounces@icann.org" target="_blank">gnso-epdp-team-bounces@icann.org</a>><span class="gmail-m_-698077310791482284Apple-converted-space"> </span><b>On Behalf Of<span class="gmail-m_-698077310791482284Apple-converted-space"> </span></b>Caitlin Tubergen<br><b>Sent:</b><span class="gmail-m_-698077310791482284Apple-converted-space"> </span>Thursday, February 7, 2019 3:26 PM<br><b>To:</b><span class="gmail-m_-698077310791482284Apple-converted-space"> </span><a href="mailto:gnso-epdp-team@icann.org" target="_blank">gnso-epdp-team@icann.org</a><br><b>Subject:</b><span class="gmail-m_-698077310791482284Apple-converted-space"> </span>[Gnso-epdp-team] For your review: updated recommendations 10, 11, 12<br> <br>Dear EPDP Team:<br> <br>Attached, please find the updated recommendations. The updates are the result of today’s EPDP Team discussion<br> <br>As always, please feel free to flag any text that you believe does not represent what the Team agreed to.<br> <br>Best regards,<br> <br>Marika, Berry, and Caitlin<br> <br> <br> <br>_______________________________________________<br>Gnso-epdp-team mailing list<br><a href="mailto:Gnso-epdp-team@icann.org" target="_blank">Gnso-epdp-team@icann.org</a><br><a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a></blockquote></div>_______________________________________________<br>Gnso-epdp-team mailing list<br><a href="mailto:Gnso-epdp-team@icann.org" target="_blank">Gnso-epdp-team@icann.org</a><br><a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a></div></blockquote></div><br></div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">Gnso-epdp-team mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><a href="mailto:Gnso-epdp-team@icann.org" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">Gnso-epdp-team@icann.org</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a></div></blockquote></div><br></div></div></div></div>_______________________________________________<br>
Gnso-epdp-team mailing list<br>
<a href="mailto:Gnso-epdp-team@icann.org" target="_blank">Gnso-epdp-team@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a></blockquote></div>