<html><head></head><body>Hi,<div class=""><br class=""/></div><div class="">Farzaneh’s thoughts below seem to correctly reflect where we are on these issues to me. One clarification on the issue of implementing “thick” WHOIS may be that the EPDP Team’s final report isn’t recommending that the implementation of the “thick” WHOIS Consensus Policy is halted. However, two of the EPDP Team’s recommendations do address this policy.</div><div class=""><br class=""/></div><div class="">Recommendation 5 addresses which data elements need to be transferred from a registrar to a registry. These pretty much include all the “thick” data. However, the draft final report also states that registrars, in their role as data controllers for this processing activity, need to assess whether or not there is a lawful basis to transfer this data to registry operators, or not. It has been argued that in most cases there is no lawful basis to do so. The lawful basis identified for transferring data from registrars to registries is GDPR Article 61b, meaning that if transferring this data is required in order to fulfill the contract between registrants and registrars, there is a legal basis to do so. In some cases, this might be true (such as specific gTLDs in which there is an eligibility criteria to fulfill in order to register a domain name under the gTLD). However, the most significant gTLD being operated using a “thin” registry is obviously .com. It is difficult to argue that transfer of the data is necessary to perform the contract between registrars and registrants, since .com registrations have been taking place for decades without the need to make these data transfers.</div><div class=""><br class=""/></div><div class="">Recommendation 5 is supplemented by recommendation 22, which identifies the “thick” WHOIS Consensus Policy as one that will need to take into consideration some of the findings of the EPDP. Changes to this policy will need to be made to make it consistent with the recommendations of the EPDP Team, if they are adopted by the GNSO Council and the ICANN Board (big IF), and the GNSO Council and the “thick” WHOIS Implementation Review Team will need to consider GDPR compliance issues themselves anyway.</div><div class=""><br class=""/></div><div class="">As Farzaneh says, it is likely that the “thick” WHOIS Consensus Policy will not be implemented has been foreseen. To what extent it will be abandoned, I am not yet certain. I am quite confident that the policy is not an appealing one at this point to contracted parties that need to implement it (from both a legal and a cost perspective), particularly those dealing with .com registrations.</div><div class=""><br class=""/></div><div class="">Thanks.</div><div class=""><br class=""/></div><div class="">Amr<br class=""/><div><br class=""/><blockquote type="cite" class=""><div class=""><br class=""/></div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">
<blockquote type="cite" class="">
<div class="">On 3 Feb 2019, at 09:45, farzaneh badii <<a href="mailto:farzaneh.badii@gmail.com" class="">farzaneh.badii@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline"/>
<div class="">
<div dir="ltr" class="">
<div class="gmail_default" style="font-family:verdana,sans-serif">Our update on EPDP work is overdue, so I thought I write my thoughts and report a bit on the developments, and others from EPDP team can chime in if they think I got something wrong. </div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""/>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><b class="">where we are at:</b></div>
<div class="gmail_default" style="font-family:verdana,sans-serif">we are now finalizing the preliminary report and need to come to a consensus quickly and send the report off to the council for approval. So pressure is high. We have to come up with an interim
policy plan to cover the gap between implementation and approval of the recs. </div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""/>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><b class="">Our principles: </b></div>
<div class="gmail_default" style="font-family:verdana,sans-serif">- Maximum data protection for domain name registrants globally</div>
<div class="gmail_default" style="font-family:verdana,sans-serif">- Accountable disclosure and accountable receipt of domain name registrants personal info</div>
<div class="gmail_default" style="font-family:verdana,sans-serif">- Side with providing data protection when in doubt whether GDPR applies</div>
<div class="gmail_default" style="font-family:verdana,sans-serif">- Keep ICANN's mission limited </div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""/>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif">I have attached a PDF with markation of what we have problems with or doubts for the moment. I am still working on it but it's attached. </div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""/>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"> <b class="">Purposes for domain name registrants data processing -</b></div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""/>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""/>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif">
<ol class="">
<li class="">Purpose 1. To establish registrants rights (generally is a good purpose, in favor of registrants). Note that some would like to add the word obligation of domain name registrants to this purpose which we have resisted and argued that if they want
to do that they need a standalone purpose. </li><li class="">Contributing to the maintenance of SSR through disclosure to lawful requests: we initially opposed this purpose because it's not a purpose for data processing. you don't collect data to disclose it later to third parties. Now the purpose has canged
to: "Contributing to the maintenance of the security, stability, and <span style="color:rgb(182,8,46);font-family:Helvetica;font-size:9px" class="">
resiliency of the</span>Domain Name System in accordance with ICANN’s mission through enabling responses to lawful data disclosure requests." This is not a bad compromise. But the footnotes are not very helpful. The first footnote says that this purpose does
not preclude IP based requests. Though this was a compromise makes me very worried. We have always said that SSR does not include IP issues and this footnote can make it easier to include IP in SSR in the future. My solution would be to re-word this and say:
This purpose does not preclude lawful disclosure for non-SSR issues i.e. trademark infringement (in accordance with ICANN bylaws). The details of the disclosure will be discussed in phase two. </li></ol>
<div class="">What we have achieved so far (relatively):</div>
<div class="">1. there might be no differentiation between legal and natural persons </div>
<div class="">2.Tech admin contact might become optional </div>
<div class="">3. There might be no differentiation in treating domain name registrants based on their geographical location</div>
<div class="">4. Thin registries might not have to implement thick registries policy (unsure about that, please correct me if I am wrong)</div>
<div class=""><br class=""/>
</div>
<div class=""><br class=""/>
</div>
<div class=""><br class=""/>
</div>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""/>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""/>
</div>
<div class="gmail_default" style="font-family:verdana,sans-serif"><br class=""/>
</div>
<div class="">
<div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr" class="">
<div class=""><font face="verdana, sans-serif" class="">Farzaneh </font></div>
</div>
</div>
</div>
</div>
<span id="cid:f_jrons96y0" class=""><EPDP Team Draft Final Report - Annotated.pdf></span></div>
</blockquote>
</div>
<br class=""/>
</div>
</div></blockquote></div><br class=""/></div></body></html>