<div dir="ltr"><div class="gmail_quote"><br><br><div dir="ltr"><div class="gmail_quote"><font face="georgia, serif" color="#444444">Dear James, dear GNSO colleagues - <br>
<br>
below is a draft approach to request a legal update from ICANN concerning the existing legal review</font><span class="gmail-"><div class="gmail_quote"><span class="gmail-m_6221274787009198767gmail-m_6486232300744104723gmail-"><font face="georgia, serif" color="#444444">memorandum which was submitted to the Thick WHOIS IRT on 8 June 2015.  We discussed this at our last call. I hope you may find the draft request below helpful. </font></span></div><div><span class="gmail-m_6221274787009198767gmail-m_6486232300744104723gmail-"><font face="georgia, serif" color="#444444"><br></font></span></div></span><font face="georgia, serif" color="#444444">First part (1) covers the reasoning. And, second part (2) highlights the relevant parts for this debate from the original 2015 legal memo.<br>
<br><br>
<br>
Thanks,<br>
Erika<br>
<br><u>
1) Draft text for request </u></font></div><div class="gmail_quote"><font face="georgia, serif" color="#444444"><br>GNSO request from ICANN legal an updated review  </font><font face="georgia, serif"><span style="color:rgb(68,68,68)">of the existing legal review </span><span style="color:rgb(68,68,68)">memorandum which was submitted to the Thick WHOIS IRT on 8 June 2015. </span></font></div><div class="gmail_quote"><font face="georgia, serif" color="#444444"><br></font></div><div class="gmail_quote"><font face="georgia, serif" color="#444444">We recommend to coordinate with appropriate subject matter experts and outside counsel to ensure the GNSO Council receives updated fact-based and independent advice, like this was done with the existing legal review memorandum from 2015.</font></div><div class="gmail_quote"><font face="georgia, serif" color="#444444"><span class="gmail-m_6221274787009198767gmail-m_6486232300744104723gmail-"><br></span></font></div><div class="gmail_quote"><font face="georgia, serif" color="#444444">We like to see a full review of applicable law(s) and a list of recommendations as to what extent existing policies the GNSO should consider changing.<span class="gmail-m_6221274787009198767gmail-m_6486232300744104723gmail-"><br>
<br>
</span>FOR EXAMPLE: Since June 2015 the legal data privacy/protection/retention landscape changed drastically in many countries but in In particular in the European Union. It is therefore key to understand how these changes might impact ICANN registries, registrars, users and contractual arrangements in general.<span class="gmail-"><br>
<br>
Certain national laws have additional extraterritorial implications. These impacts were not captured in the  2015 legal review memorandum.<br>
<br>
Why is such a review needed? A good example are the changes that were introduced in the European Union and between the EU and the US since June 2015.<br>
<br></span>
EXPLANATION:<span class="gmail-"><br>
The 'General Data Protection Regulation' in the European Union came into force May 2016 and will apply across Europe in May 2018. The core element of the data protection reform is a general data protection regulation that will replace and equal existing data protection laws across the European Union countries. This new regulation updates and modernises the principles of the 1995 Data Protection Directive that the existing ICANN legal review memorandum from 2015 covers.  It sets out the rights of the individual and establishes the obligations of those processing and those responsible for the processing of the data. It also establishes the methods for ensuring compliance as well as the scope of sanctions for those in breach of the rules. In addition, certain aspects of this law, will be interpreted by the European Data Protection Board (EDPB)<br>
in the near future. Law enforcement related aspects of this law are regulated in a separate legal framework.<br>
<br>
The GDRP is insofar unique as it's a law with far reaching extraterritorial implications, this aspect is not captured in ICANNs<br>
2015 legal memo neither.<br>
<br></span>
Since 2015 the transfer of personal data requirements from EU to the US changed as well. In 2015 the Safe Harbor Agreement (SHA) was in place, in 2016 a new Privacy Shield Agreement came into force, replacing the SHA, implementing new adequacy requirements for the transfer of date between EU and US. ICANNs legal memo from 2015 does not cover these developments.<div><div class="gmail-h5"><br>
<font color="#444444"><br>
In addition, we may see new legal challenges arising that might question the SHA because of President Donald Trump’s Executive Order on domestic safety, released on January 26th, 2017. "Agencies shall, to the extent consistent with applicable law, ensure that their privacy policies exclude persons who are not United States citizens or lawful permanent residents from the protections of the Privacy Act regarding personally identifiable information."</font><br>
<br>
<br><u>
2) Key exert from the e<span style="color:rgb(68,68,68)">xisting legal review </span><span style="color:rgb(68,68,68)">memorandum which was submitted to the Thick WHOIS IRT on 8 June 2015</span></u></div><div><br>
<br>
To the extent that a contracted party finds that it is unable to<br>
comply with the Thick Whois policy requirements due to a conflict with<br>
its obligations under local privacy laws, such conflicts may be dealt<br>
with by exception through use of the Whois Conflicts Procedure, or<br>
requests to ICANN for an amendment to or waiver of certain provisions<br>
in the Registry Agreement or Registrar Accreditation Agreement. (page<br>
1)<br>
<br>
As further detailed below, to address the concerns previously<br>
highlighted in the EWG Memo, this memorandum provides practical<br>
recommendations about the move to Thick Whois and also notes that<br>
ICANN’s Procedure for Handling WHOIS Conflicts with Privacy Law is<br>
available to contracted parties to address specific cases where Thick<br>
Whois requirements may be inconsistent with the parties’ obligations<br>
under local privacy laws. (page 2)<br>
<br>
 Additionally, contracted parties may consider requesting amendments<br>
to or waivers from specific Thick Whois requirements in agreements<br>
with ICANN that may be inconsistent with contracted parties'<br>
obligations under local privacy laws. (page 2)<br>
<br>
 The present analysis is neither a detailed nor complete analysis of<br>
data protection laws within any particular jurisdiction. Instead,<br>
ICANN performed a general survey of EU data protection laws as the<br>
Data Protection Directive 95/46/EC embodies international principles<br>
which serve as a basis for many data protection laws around the world.<br>
(page 3)<br>
<br>
As an example of the latter, see Russia’s Federal Law 242-FZ<br>
(“Localization Law”) which requires compliance by 1 September 2015,<br>
but is still the subject of significant uncertainty as to its scope,<br>
applicability and requirements.(page 4)<br>
<br>
It is true that in some countries there are some important and<br>
legitimate questions relating to data protection obligations under<br>
local law that must be addressed as implementation of Thick Whois<br>
across all gTLDs is considered. (page 5)<br>
<br>
ICANN recognizes that two of those principles trigger particular<br>
attention in relation to the transition to Thick Whois: the need for<br>
registrars in some countries to establish a 'lawful basis' (i) for the<br>
disclosure of registrants' personal data to the relevant registry and<br>
(ii) for the transfer of such data to another country (in this case,<br>
the U.S., where all three relevant registries are located). “Transfer”<br>
generally covers any sharing, transmission or disclosure of, providing<br>
access to, or otherwise making available, personal information to<br>
third parties. The EU Data Protection Directive (95/46/EC) (“EU<br>
Directive”), for example, requires that personal information may only<br>
be transferred to third countries outside the European Economic Area<br>
(EEA) if the receiving countries provide an “adequate” level of<br>
protection, as determined by the European Commission or the transfer<br>
satisfies one of the exceptions permitted by the EU Directive. One of<br>
the two most viable “exceptions” to permit lawful transfer is the<br>
consent of the data subjects. However, utilizing this “exception” does<br>
entail some challenge that the registrar and registry must ensure are<br>
addressed. (page 6/7)<br>
<br>
Consent in some form and degree is of significant importance across<br>
most jurisdictions as it relates to implementation of thick Whois. For<br>
example, consent is one way in which organisations can meet one of the<br>
‘conditions’ for processing of personal data throughout the EEA. It<br>
also serves to justify transfers outside the EEA - the EU Directive<br>
clearly specifies consent9 as a lawful ground for these purposes. In<br>
Russia, transfer is permitted provided that (1) consent of the data<br>
subject is properly obtained and (2) the transfer is as legally<br>
prescribed.10 If proper consent is obtained, such data may be<br>
collected, stored, published and/or transferred in the manner<br>
consistent with the specific consent provided. Other data protection<br>
requirements will still need to be met– for example, proportionality,<br>
data quality and security considerations still apply even where<br>
consent has been obtained. (page 7)<br>
<br>
However, in certain jurisdictions there exists the right to revoke<br>
consent. In such instance, the registry or registrar must determine<br>
the effect on the registration and the corresponding registration<br>
data. The EU Directive does not contain any procedural guidance around<br>
withdrawal of consent (e.g. time periods for acting on this). The<br>
Article 29 Working Party11 requires that consent should be possible to<br>
be withdrawn at any time with effect for the future. It regards<br>
consent to be deficient if no effective withdrawal is provided.12 The<br>
Article 29 Working Party itself has made clear that withdrawal of<br>
consent is not retroactive13. Accordingly, if a registrant withdrew<br>
consent, this would not affect the lawfulness of data which had<br>
already been transferred from an EU registrar to a relevant registry.<br>
(page 8)<br>
<br>
Apart from the possibility to revoke consent, there may also be doubts<br>
as to whether the consent of registrants granted as a condition for<br>
the transfer of the registrant data to the registry under the thick<br>
Whois should be regarded as “freely given,” in particular if all<br>
registrars "require" registrants to grant consent in a similar form.<br>
However, ICANN notes that this concern can actually be addressed via<br>
the provision of privacy/proxy services by the relevant registrars, as<br>
these do provide effective choice to the registrant. (page 8)<br>
<br>
In any case and especially for the application of the thick Whois in<br>
the EU, ICANN considers it is important that the data processing under<br>
thick Whois and the transition thereto can also be based upon the<br>
legitimate interests of a party (including ICANN, registries, and<br>
registrants). Legitimate interests can be an alternative basis for EU<br>
registrars to justify processing of personal data, as long as the<br>
processing is not unwarranted because of the (privacy) interests of<br>
the individuals whose data is processed. Acknowledged legitimate<br>
interests include increased security, stability and resiliency in the<br>
Internet. However, from an EU perspective, if the data processing<br>
under thick Whois is based upon legitimate interests, instruments to<br>
provide for an adequate level of data protection on part of the data<br>
recipient located outside of the EEA will also become relevant (e.g.,<br>
Standard Contract Clauses, Safe Harbor, approval from the relevant<br>
data protection authorities, etc.14). This is because while sharing of<br>
data within the EEA may be justified on this basis, there are<br>
additional restrictions on transfers of data outside the EEA. Those<br>
instruments contain restrictions on onward transfers (to be imposed on<br>
third parties wishing to look up EU Whois data) and contracted parties<br>
will need to assess whether and in which form it is practically<br>
feasible to implement those restrictions; these restrictions are<br>
likely to mean that consent is the most suitable approach,<br>
notwithstanding the difficulties outlined above. Furthermore, in<br>
addition to consent, (i) privacy/proxy services, and perhaps (ii)<br>
thick Whois services where the data stays in the region subject to<br>
restrictions to avoid data transfer limitations remain as options<br>
available to address transfer of the data. (page 9)<br>
<br>
The Whois Conflicts Procedure is the implementation of GNSO consensus<br>
policy adopted “in order to facilitate reconciliation of any conflicts<br>
between local/national mandatory privacy laws or regulations and<br>
applicable provisions of the ICANN contract regarding the collection,<br>
display and distribution of personal data via the gTLD Whois service.”<br>
The Whois Conflicts Procedure is designed to ensure regulatory<br>
obstacles on the collection, processing, transfer and display of gTLD<br>
registration data can be dealt with by exception in instances where a<br>
registry or registrar can demonstrate that it is legally prevented by<br>
local/national data protection laws or regulations from fully<br>
complying with applicable provisions of its contract. ICANN has<br>
commenced a review of the Whois Conflicts Procedure to determine<br>
whether modifications to that procedure might be considered. (page 10)<br>
<br>
The most common complaint of ICANN contracted parties is that the<br>
Whois Conflicts Procedure requires 15<br>
<a href="http://www.icann.org/en/resources/registrars/whois-privacy-conflictsprocedure-17jan08-en.htm" rel="noreferrer" target="_blank">http://www.icann.org/en/resour<wbr>ces/registrars/whois-privacy-c<wbr>onflictsprocedure-17jan08-<br>
en.htm</a> 11 “notification of an investigation, litigation, regulatory<br>
proceeding or other government or civil action . . .” as its trigger.<br>
To the extent any proposed changes to implementation of the Whois<br>
Conflicts Procedure are recommended, they would be presented to the<br>
GNSO Council, which would determine next steps. (page 10/11)<br>
<br>
In other cases, ICANN has granted limited waivers from compliance with<br>
specific terms and conditions in the 2013 Registrar Accreditation<br>
Agreement regarding data retention requirements in cases where<br>
registrars requests such change because they believe the requirements<br>
violate their countries’ data retention laws. (page 12)<br>
<br>
Additionally, contracted parties may wish to consider requesting<br>
amendments to or waivers from specific contractual requirements in<br>
connection with the transition from a thin to a thick Whois model to<br>
the extent the contracted parties’ obligations conflict with its local<br>
laws. Historically, ICANN has granted amendments to specific Whois<br>
provisions in the Registry Agreement when requested by registry<br>
operators with support of relevant Data Protection Authorities to<br>
comply local privacy laws. (page 11)<br>
<br>
Where a conflict is proven to exist by a registrar or registry by way<br>
of the Whois Conflicts Procedure, or an amendment or waiver from<br>
certain Whois requirements is granted by ICANN, the Registration Data<br>
Access Protocol, or RDAP, could be a means to mitigating such conflict<br>
without eliminating entirely the benefits of thick WHOIS (e.g. an<br>
end-user looking up Whois data would see “thick” data, even though the<br>
underlying data is not be stored with the registry). Because RDAP<br>
would only permit registry-level access to thick Whois output by<br>
redirect to the registrar’s own portal, meaning such data would not be<br>
“thick” in the sense of existing also at the registry level, there are<br>
questions as to whether its implementation would be consistent with<br>
policy recommendation #1 and the identified benefits of the thick<br>
Whois model outlined in the Thick Whois Final Report. (page 12)<br>
<br>
<br>
(To assist with the legal analysis reflected in this Section, ICANN<br>
engaged Bird & Bird, a leading international law firm with over 1100<br>
lawyers in 27 offices across Europe, the Middle East and Asia with a<br>
highly regarded International Privacy & Data Protection Group that<br>
advises clients throughout the world. (page 6)<br>
</div></div></font><div><div class="gmail-h5"><div class="gmail-m_6221274787009198767gmail-m_6486232300744104723gmail-HOEnZb"><div class="gmail-m_6221274787009198767gmail-m_6486232300744104723gmail-h5"><font face="georgia, serif" color="#444444"><br>
<br>
On Fri, Jan 20, 2017 at 12:22 AM, Marika Konings<br>
<<a href="mailto:marika.konings@icann.org" target="_blank">marika.konings@icann.org</a>> wrote:<br>
><br>
> Dear All,<br>
><br>
><br>
><br>
> As requested during the call today, please find attached the legal review memorandum which was submitted to the Thick WHOIS IRT on 8 June 2015.<br>
><br>
><br>
><br>
> Best regards,<br>
><br>
><br>
><br>
> Marika<br>
><br>
><br>
><br>
> Marika Konings<br>
><br>
> Senior Policy Director & Team Leader for the GNSO, Internet Corporation for Assigned Names and Numbers (ICANN)<br>
><br>
> Email: <a href="mailto:marika.konings@icann.org" target="_blank">marika.konings@icann.org</a><br>
><br>
><br>
><br>
> Follow the GNSO via Twitter @ICANN_GNSO<br>
><br>
> Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages.<br>
><br>
><br>
><br>
><br>
</font></div></div><div class="gmail-m_6221274787009198767gmail-m_6486232300744104723gmail-HOEnZb"><div class="gmail-m_6221274787009198767gmail-m_6486232300744104723gmail-h5"><font face="georgia, serif" color="#444444">> ______________________________<wbr>_________________<br>
> council mailing list<br>
> <a href="mailto:council@gnso.icann.org" target="_blank">council@gnso.icann.org</a><br>
> <a href="https://mm.icann.org/mailman/listinfo/council" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/l<wbr>istinfo/council</a><br>
><br>
</font></div></div></div></div></div><br></div>
</div><br></div>