<html><head></head><body>Hi Kurt,<div class=""><br class=""/></div><div class="">Thanks for getting back to me on this. I appreciate your reasoning on the order of issues to be tackled, and agree that it is unlikely that this group reaches an easy consensus (if any at all) on the scope of ICANN’s mission and Bylaws concerning processing (collection, use and disclosure, as you put it) of gTLD Registration Data.</div><div class=""><br class=""/></div><div class="">For my part, I wasn’t suggesting we tackle sections 4.2 and 4.3 of the Temp Spec because I wanted you to lead us all into a hole we couldn’t crawl out of. Rather, I am concerned that the topic of ICANN’s remit will be spread out over multiple discussions concerning purposes of processing (again…, collection, use and disclosure) of gTLD Registration Data, basically with every single one of them. I suspect that this will delay progress on each and every one of these purposes, and a number of arguments on the scope of ICANN’s mission and Bylaws will need to be repeated at multiple points of the deliberations. In making my suggestion of tackling sections 4.2 and 4.3, I was hoping to avoid that in the same manner you are hoping to avoid a lack of consensus on nailing down an interpretation by this Team of ICANN’s remit. It’s a judgment call really, and absent support for a different direction among the EPDP Team members, it’s one that I will respect, whether I agree with it, or not.</div><div class=""><br class=""/></div><div class="">I suspect that most of us have already gone through most of the background documents relevant to this EPDP, but as a reminder, I’ve pasted a question sent by the GNSO Next Generation RDS PDP WG to EU Data Protection Experts, as well as the response received by the WG. The full set of questions and answers can be found on this <a href="https://community.icann.org/display/gTLDRDS/Responses+to+RDS+PDP+WG+Questions+on+Data+Protection+and+Privacy+Laws" class="">page</a>.</div><div class=""><br class=""/></div><div class="">Question by GNSO RDS PDP WG: <div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><br class=""/></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><blockquote type="cite" class=""><i class="">Our working group is now deliberating upon the purpose of domain name registration data and the registration directory system that provides public access to that data. Can you please help us understand what the data protection supervisors have meant over the years when they have told ICANN to specify the purpose of WHOIS?</i></blockquote></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><br class=""/></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class="">Response by EU Data Protection Experts:</div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><br class=""/></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""></div><blockquote type="cite" class=""><div style="margin: 0px; font-stretch: normal; line-height: normal; min-height: 14px;" class=""><i class="">Purpose has to be defined in advance of the data processing. Purposes have to have a legitimate aim and the processing has to be necessary and proportionate to the legitimate aim pursued. Translating this to ICANN means the WG would want to take a look into ICANN role and its mission statement and separate out the legitimate data processing purposes, and determine which data are necessary for which purpose. It is to be underlined that the compatibility of the processing to the original legitimate purpose should be also looked into at this point. You have also to bear in mind that according to all existing legal texts, the data controller has to be accountable for the data processing and that the purpose of the WHOIS directories cannot be extended to other purposes just because they are considered desirable by some potential users of the directories. </i></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><i class=""><br class=""/></i></div><div style="margin: 0px; font-stretch: normal; line-height: normal;" class=""><i class="">To illustrate it with an example if ICANN determines that it has a role in cyber-security,it will become accountable for these kinds of data processing (meaning accuracy of data, handling complaints, providing subject access etc…) but cannot give out data just because law enforcement authorities may find it useful.</i> </div></blockquote></div><div><br class=""/></div><div>I hope this helps.</div><div><br class=""/></div><div>Thanks.</div><div><br class=""/></div><div>Amr</div><div><br class=""/></div><div><br class=""/><blockquote type="cite" class=""><div class="">On Sep 6, 2018, at 8:31 AM, Kurt Pritz <<a href="mailto:kurt@kjpritz.com" class="">kurt@kjpritz.com</a>> wrote:</div><br class="Apple-interchange-newline"/><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""/><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hello Amr (and everyone): <div class=""><br class=""/></div><div class="">I am writing in response to your proposal that the team considers Temporary Specification <span style="color: rgb(69, 69, 69); font-family: "Helvetica Neue";" class="">§</span><font color="#454545" face="Helvetica Neue" class=""><span style="caret-color: rgb(69, 69, 69);" class="">§</span></font><span style="color: rgb(69, 69, 69); font-family: "Helvetica Neue";" class="">4.1-4.3 (with reference to the ICANN Bylaws and mission) prior to our discussion of data elements. </span></div><div class=""><span style="color: rgb(69, 69, 69); font-family: "Helvetica Neue";" class=""><br class=""/></span></div><div class=""><font color="#454545" face="Helvetica Neue" class="">I think understand the reasoning behind your request but still believe we should finish the <span style="caret-color: rgb(69, 69, 69);" class="">“</span>purposes” and “data elements” discussion before going into the reach of ICANN’s mission and Bylaws. Let me test out my reasons for this: </font></div><div class=""><span style="color: rgb(69, 69, 69); font-family: "Helvetica Neue";" class=""><br class=""/></span></div><div class=""><font color="#454545" face="Helvetica Neue" class="">With regard to the </font><span style="caret-color: rgb(69, 69, 69); color: rgb(69, 69, 69); font-family: "Helvetica Neue";" class="">ICANN mission and Bylaws </span><font color="#454545" face="Helvetica Neue" class="">I believe there is a range of opinions among the stakeholder groups on our team as to the extent that the ICANN mission and Bylaws enable the collection, use and disclosure of personal data, </font></div><div class=""><font color="#454545" face="Helvetica Neue" class=""><br class=""/></font></div><div class=""><font color="#454545" face="Helvetica Neue" class="">In the best case, which I view as unlikely, we would develop a consensus opinion on this issue. Thus would be a helpful but not dispositive guide for identifying which data elements are collected and how they are used / disclosed. We’d still have to undertake that.</font></div><div class=""><font color="#454545" face="Helvetica Neue" class=""><br class=""/></font></div><div class=""><font color="#454545" face="Helvetica Neue" class="">More likely, I believe there would be a discussion without a consensus result. Even in that case, we would next take up the task of identifying data elements to be collected by registrars and their subsequent processing. </font></div><div class=""><font color="#454545" face="Helvetica Neue" class=""><br class=""/></font></div><div class=""><font color="#454545" face="Helvetica Neue" class="">Given that we have existing data collection and processing practices that were adequate pre-GDPR, it seems better to weigh those practices against GDPR and see what remains. <span style="caret-color: rgb(69, 69, 69);" class="">Given the discussion at the end of the last meeting, it appears that the currently collected set of data is adequate for the currently identified needs of those seeking personal data disclosure. I can anticipate where there might be differences (we will see) but if an agreement is struck regarding the collection and disclosure od data elements, it seems accommodation on policy statements is more likely. </span></font></div><div class=""><font color="#454545" face="Helvetica Neue" class=""><br class=""/></font></div><div class=""><font color="#454545" face="Helvetica Neue" class="">Taking a slightly different approach to the same point: I think we should be discussing the section 4.4 elements, legitimate reasons for disclosure, and Appendix A against the GDPR and not against the ICANN Bylaws and mission. </font></div><div class=""><font color="#454545" face="Helvetica Neue" class=""><br class=""/></font></div><div class=""><font color="#454545" face="Helvetica Neue" class="">I understand that <span style="caret-color: rgb(69, 69, 69);" class="">§§</span>4.1 and 4.2 are </font><span style="color: rgb(69, 69, 69); font-family: "Helvetica Neue"; caret-color: rgb(69, 69, 69);" class="">elements</span><font color="#454545" face="Helvetica Neue" class=""> in the Temporary Specification and must be discussed (I am not sticking my head in the ground here - I don’t think), but it is more efficient to discuss these paragraphs later — and especially if we don’t agree on data elements collected and processed. </font></div><div class=""><span style="color: rgb(69, 69, 69); font-family: "Helvetica Neue";" class=""><br class=""/></span></div><div class=""><font color="#454545" face="Helvetica Neue" class="">I think Alan G. was on to something in his earlier email where he said we should focus on what’s needed for our policy. Our goal is to identify (as a matter of policy):</font></div><div class=""><ul class="MailOutline"><li class=""><font color="#454545" face="Helvetica Neue" class=""><span style="caret-color: rgb(69, 69, 69);" class="">The</span> legitimate purposes for processing registrant data</font></li><li class=""><font color="#454545" face="Helvetica Neue" class="">the set of data to be collected by registrars and </font></li><li class=""><font color="#454545" face="Helvetica Neue" class="">identifying the legitimate reasons (i.e., reasons with a legal basis) for disclosing that data to third parties.</font></li></ul></div><div class=""><span style="color: rgb(69, 69, 69); font-family: "Helvetica Neue";" class=""><br class=""/></span></div><div class=""><font color="#454545" face="Helvetica Neue" class="">This, of course is an oversimplification but it is where we should focus. (I know others have made these comments before. I think Amr’s inquiry is a good time to restate what some others have said.) </font></div><div class=""><font color="#454545" face="Helvetica Neue" class=""><br class=""/></font></div><div class=""><font color="#454545" face="Helvetica Neue" class="">I hope this was clear and helpful to the discussion. </font></div><div class=""><font color="#454545" face="Helvetica Neue" class=""><br class=""/></font></div><div class=""><font color="#454545" face="Helvetica Neue" class="">Best regards,</font></div><div class=""><font color="#454545" face="Helvetica Neue" class=""><br class=""/></font></div><div class=""><font color="#454545" face="Helvetica Neue" class="">Kurt</font></div><div class=""><font color="#454545" face="Helvetica Neue" class=""><br class=""/></font></div></div></div></blockquote></div><br class=""/></div></body></html>