<div dir="ltr">I don't support the "No Thick Registries" approach and don't think that a one size fits all approach should become the view of all Non-Commercial Stakeholders. <div><br></div><div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div></div></div></div></div></div>
<br><div class="gmail_quote">On Mon, Jun 25, 2018 at 7:48 PM, Tomslin Samme-Nlar <span dir="ltr"><<a href="mailto:mesumbeslin@gmail.com" target="_blank">mesumbeslin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>It is significantly different from the Unified Access Model put forward by ICANN org especially with regards to accreditation and legitimate purpose definitions. I also love the idea of confederated servers.</div><div dir="auto">I support its adoption.<br><br><div data-smartmail="gmail_signature" dir="auto">Cheers,<br>Tomslin<br><a href="https://www.linkedin.com/in/tomslin/" target="_blank">https://www.linkedin.com/in/<wbr>tomslin/</a></div><div><div class="h5"><br><div class="gmail_quote" dir="auto"><div dir="ltr">On Mon., 25 Jun. 2018, 12:29 farzaneh badii, <<a href="mailto:farzaneh.badii@gmail.com" target="_blank">farzaneh.badii@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-family:verdana,sans-serif">Dear all,</div><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif">This is an access model to WHOIS personal data which Internet Governance Project put forward and now it is getting support from some part of the community. I am sharing it here for discussion now and tomorrow at the NCSG Policy Committee session. </div><div style="font-family:verdana,sans-serif" dir="auto"><br></div><div style="font-family:verdana,sans-serif" dir="auto">It is good to adopt it as NCSG access model and advance it in our discussions during ICANN 62 </div><div style="font-family:verdana,sans-serif" dir="auto"><br></div><div style="font-family:verdana,sans-serif" dir="auto">Here is the link for more background and the conditions are set out below:<div><a href="https://www.internetgovernance.org/2018/06/22/an-access-model-for-whois-data-that-respects-registrants-rights/" rel="noreferrer" target="_blank">https://www.<wbr>internetgovernance.org/2018/<wbr>06/22/an-access-model-for-<wbr>whois-data-that-respects-<wbr>registrants-rights/</a></div><div dir="auto"><br></div></div><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif"><p style="box-sizing:inherit;margin-bottom:1.5em;font-family:"Istok Web",sans-serif;font-size:16px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></p><p style="box-sizing:inherit;margin-bottom:1.5em;font-family:"Istok Web",sans-serif;font-size:16px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><br></p><p style="box-sizing:inherit;margin-bottom:1.5em;font-family:"Istok Web",sans-serif;font-size:16px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Access to personal information of domain name registration WHOIS directory should take place under the following conditions:</p><h2 style="box-sizing:inherit;font-family:Hind,sans-serif;line-height:1.2;font-size:2.25em;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><strong style="box-sizing:inherit;font-weight:bold">A confederated RDAP</strong></h2><p style="box-sizing:inherit;margin-bottom:1.5em;font-family:"Istok Web",sans-serif;font-size:16px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">ICANN’s Temporary Specification requires registries implement RDAP. We think that is good. We also believe that the RDAP servers should be confederated so that queries can go to one source, which can hand it off to the Registrar that handles the domain.</p><h2 style="box-sizing:inherit;font-family:Hind,sans-serif;line-height:1.2;font-size:2.25em;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><strong style="box-sizing:inherit;font-weight:bold">No thick registries</strong></h2><p style="box-sizing:inherit;margin-bottom:1.5em;font-family:"Istok Web",sans-serif;font-size:16px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">All Registries should be thin registries. There is no justification to require registries to hold the personal data of domain name registrants. Registries do not need that information to perform their function, and therefore thick registries are presumptively noncompliant with GDPR and data protection/privacy principles more generally.</p><h2 style="box-sizing:inherit;font-family:Hind,sans-serif;line-height:1.2;font-size:2.25em;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><strong style="box-sizing:inherit;font-weight:bold">Registrars in charge of granting access</strong></h2><p style="box-sizing:inherit;margin-bottom:1.5em;font-family:"Istok Web",sans-serif;font-size:16px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Registrars, not registries, should be the parties to whom requests are made and who provide the private data to requestors. Registrars are the organizations who have the direct relationship with the registrant. No other agency should be able to authorize or deliver access nor there should be any other organization that can approve third parties as legitimate interest holders except Law Enforcement. Registrars will not be held liable for not granting access based on valid reasons.</p><h2 style="box-sizing:inherit;font-family:Hind,sans-serif;line-height:1.2;font-size:2.25em;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><strong style="box-sizing:inherit;font-weight:bold">Law Enforcement Agencies develop their own accreditation </strong></h2><p style="box-sizing:inherit;margin-bottom:1.5em;font-family:"Istok Web",sans-serif;font-size:16px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Criteria and methods for accrediting entities as bona fide law enforcement agencies (LEAs) should be developed by LEAs themselves. It can be done through GAC, Interpol, or any other LEA nexus. The ICANN community should be able to comment on it before it is adopted.</p><h2 style="box-sizing:inherit;font-family:Hind,sans-serif;line-height:1.2;font-size:2.25em;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><strong style="box-sizing:inherit;font-weight:bold">Narrow legitimate interest in line with ICANN’s mission</strong></h2><p style="box-sizing:inherit;margin-bottom:1.5em;font-family:"Istok Web",sans-serif;font-size:16px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">As long as access procedures are being led by ICANN,  it has to be in line with ICANN’s mission. There are various interpretations of ICANN mission and some prefer to interpret them broadly. ICANN mission should be interpreted narrowly by ICANN, if registrars recognize that there are other legitimate interests and third parties, they can in accordance with GDPR and their local laws allow for access on a case by case basis. We believe that legitimate interest must be defined in a narrow way consistent with ICANN’s mission. The release of the data must be needed to:</p><ul style="box-sizing:inherit;margin:0px 0px 1.5em;list-style:disc;font-family:"Istok Web",sans-serif;font-size:16px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><li style="box-sizing:inherit">Solve a crime or track down a criminal using the domain</li><li style="box-sizing:inherit">Respond to threats to DNS operations</li><li style="box-sizing:inherit">Respond to attacks on the confidentiality, integrity or availability of Internet services that use the DNS as part of the attack infrastructure</li></ul><h2 style="box-sizing:inherit;font-family:Hind,sans-serif;line-height:1.2;font-size:2.25em;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><strong style="box-sizing:inherit;font-weight:bold">Access restricted to individual queries</strong></h2><p style="box-sizing:inherit;margin-bottom:1.5em;font-family:"Istok Web",sans-serif;font-size:16px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Access must be granted on an individual query basis, and based on a specific incident. Requests must be made for a particular domain – not a general license to search registration records. There is no need to ask for clarification on this point from the European Data Protection Board. ICANN has to apply this principle because it must respect the privacy of domain name registrants and also not interfere with the technical operation of DNS. Moreover, it can shield itself from liability, should access to the full database not be in compliance with GDPR.</p><h2 style="box-sizing:inherit;font-family:Hind,sans-serif;line-height:1.2;font-size:2.25em;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><strong style="box-sizing:inherit;font-weight:bold">Secondary queries</strong></h2><p style="box-sizing:inherit;margin-bottom:1.5em;font-family:"Istok Web",sans-serif;font-size:16px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">There should be an ability to run secondary queries based on identity characteristics uncovered in an initial query, but such queries must be limited to legitimate interests listed above.</p><h2 style="box-sizing:inherit;font-family:Hind,sans-serif;line-height:1.2;font-size:2.25em;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><strong style="box-sizing:inherit;font-weight:bold">Requestor’s accountability</strong></h2><p style="box-sizing:inherit;margin-bottom:1.5em;font-family:"Istok Web",sans-serif;font-size:16px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial">Requestors must be held accountable for their use of special access. Requestor’s identity must be known and recorded. Requestors must provide a specific legitimate reason for the query, which shall be recorded at the time of the query. Domain name registrants should have recourse against abuse in queries. If the requestor exceeds the scope of access, domain name registrants should be able to file a complaint against requestors who abuse access on the grounds laid out by law and policy.</p><ul style="box-sizing:inherit;margin:0px 0px 1.5em;list-style:disc;font-family:"Istok Web",sans-serif;font-size:16px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><li style="box-sizing:inherit">There should be an Alternative Dispute Resolution mechanism in place to file the complaint.</li><li style="box-sizing:inherit">The outcome will be binding on the defendant</li><li style="box-sizing:inherit">Those who abuse their access can be held accountable by having to pay a fine.</li><li style="box-sizing:inherit">The fine can be enforced by having an escrow mechanism in place, which requires the requestor to deposit an amount in the escrow prior to access</li><li style="box-sizing:inherit">Domain registrants shall not surrender their right to go to court for privacy violations</li></ul><br></div></div><div><div><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif"><br></div><div><div class="m_-8673609368550609179m_-1637605633628063359m_-8001485221945471039gmail_signature" data-smartmail="gmail_signature"><div><div><font face="verdana, sans-serif">Farzaneh </font></div></div></div></div></div></div>-- <br><div dir="ltr" class="m_-8673609368550609179m_-1637605633628063359gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><font face="verdana, sans-serif">Farzaneh </font></div></div></div>
</blockquote></div></div></div></div></div>
</blockquote></div><br></div></div></div>