<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:27924634;
mso-list-template-ids:420379734;}
@list l0:level1
{mso-level-start-at:3;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:320887635;
mso-list-template-ids:1871640912;}
@list l1:level1
{mso-level-start-at:2;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2
{mso-list-id:461189874;
mso-list-template-ids:1625833486;}
@list l2:level1
{mso-level-start-at:6;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3
{mso-list-id:628556332;
mso-list-template-ids:-34180258;}
@list l3:level1
{mso-level-start-at:5;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4
{mso-list-id:745346064;
mso-list-template-ids:-565543804;}
@list l4:level1
{mso-level-start-at:4;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5
{mso-list-id:769159187;
mso-list-type:hybrid;
mso-list-template-ids:-1866194996 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l5:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l5:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l5:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l6
{mso-list-id:1262445579;
mso-list-template-ids:-1899342678;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Dear All, <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Please find below the input from ICANN Org on the questions that were raised by the EPDP meeting on the 9<sup>th</sup>, 13<sup>th</sup>, and 16<sup>th</sup>. The responses will get posted shortly here:
<a href="https://community.icann.org/x/ahppBQ">https://community.icann.org/x/ahppBQ</a>.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Caitlin, Berry and Marika<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt">**</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoNormal" style="color:black;mso-list:l5 level1 lfo3">Regarding Temporary Specification section 4.4.8 - Supporting a framework to address issues involving domain name registrations: the team requests additional specificity. Does this mean that registrars
and registries must support a uniform access mechanism when approved or is there some present requirement?<o:p></o:p></li></ol>
<p class="MsoListParagraph"><span style="color:#4472C4">RESPONSE: Section 4.4.8 identifies that addressing issues involving domain name registrations, including but not limited to: consumer protection, investigation of cybercrime, DNS abuse, and intellectual
property protection using a framework to be developed is a legitimate purpose for the processing of registration data. With regard to the second question, section 4.4.8 does not by itself require that registrars and registries must support a uniform access
mechanism when approved. Please note however that section 4.1 of Appendix A does have a requirement for registrars and registries to “provide reasonable access to Personal Data in Registration Data to third parties on the basis of legitimate interests pursued
by the third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the Registered Name Holder or data subject pursuant to Article 6(1)(f) GDPR.” Separately, section 4.2 of Appendix A requires registrars and
registries to “provide reasonable access to Personal Data in Registration Data to a third party where the Article 29 Working Party/European Data Protection Board, court order of a relevant court of competent jurisdiction concerning the GDPR, applicable legislation
or regulation has provided guidance that the provision of specified non-public elements of Registration Data to a specified class of third party for a specified purpose is lawful.” Section 4.2 of Appendix A further requires that registrars and registries “provide
such reasonable access within 90 days of the date ICANN publishes any such guidance, unless legal requirements otherwise demand an earlier implementation.”</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<ol style="margin-top:0in" start="2" type="1">
<li class="MsoNormal" style="color:black;mso-list:l5 level1 lfo3">Regarding Temporary Specification section 4.4.13 - Handling contractual monitoring requests: which data sets will be required to measure compliance against which contractual provisions?<o:p></o:p></li></ol>
<p class="MsoListParagraph"><span style="color:#4472C4">RESPONSE: The data requested by ICANN Contractual Compliance will vary depending on the particular compliance issue. For example, for a registrant’s complaint that a renewal reminder email was not received,
ICANN Contractual Compliance may request from the registrar of record a copy of the communication to the Registered Name Holder.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<ol style="margin-top:0in" start="3" type="1">
<li class="MsoNormal" style="color:black;mso-list:l5 level1 lfo3">Can ICANN summarize in some searchable form the contacts and engagements with the EDPB and/or other DPAs in relation to the Temporary Specification for gTLD Registration Data?<o:p></o:p></li></ol>
<p class="MsoListParagraph"><span style="color:#4472C4">RESPONSE: ICANN org has been open and transparent with our engagements with the EDPB and DPAs. All of the formal written communications from EDPB and DPAs are published on ICANN correspondence. In addition,
we’ve had informal verbal conversations with the EDPB and DPAs to educate, inform, and ask for guidance. Summaries of those informal conversations are published in blogs. To assist the EPDP Team in its work, ICANN org will provide the EPDP Team with a compiled
list of correspondence received and blogs published thus far, including the topic of each correspondence/blog.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<ol style="margin-top:0in" start="4" type="1">
<li class="MsoNormal" style="color:black;mso-list:l5 level1 lfo3">In section 5.7 of the Temporary Specification (and other sections), what is the meaning of “reasonable access”? Is it access to personal data reasonably provided? Does “reasonably” relate to
the effort necessary to retrieve it? Does it mean how criteria for releasing it are applied, i.e., legitimate and not overcome by the rights of others? Should it just be “access”?<o:p></o:p></li></ol>
<p class="MsoListParagraph"><span style="color:#4472C4">RESPONSE: “Reasonable access” is not defined in the Temporary Specification. Generally, compliance with the requirement for registrars and registries to provide reasonable access to non-public registration
data is evaluated on a case-by-case basis, based on evidence provided by the requestor, including its request for access to non-public registration data, evidence of the requestor’s legitimate purpose for accessing the non-public registration data, the timing
and content of the contracted party’s response to the request (if any), and any other information or evidence relevant to assessing the request and response.</span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<ol style="margin-top:0in" start="5" type="1">
<li class="MsoNormal" style="color:black;mso-list:l5 level1 lfo3"><span style="color:windowtext">Believing that ICANN org has its own GDPR implementation plan in place, it would be helpful for our group to understand the elements and implementation status of
the plan so that the Team can draw comparisons to the EPDP Team’s work.</span><o:p></o:p></li></ol>
<p class="MsoListParagraph"><span style="color:#4472C4">RESPONSE: ICANN org has been open and transparent about its work to get ready for GDPR both in terms of domain registration data collected and processed by registrars and registries (which we refer to
as “external” GDPR readiness), and personal data processed by ICANN org in the ordinary course of the organization’s operations such as finance, meetings, and human resources (which we refer to as “internal” GDPR readiness). ICANN org’s plans and activities
regarding “external” (domain registration data) GDPR compliance have been openly and transparently blogged and posted on the ICANN Data Protection page at <https://www.icann.org/dataprotectionprivacy>. On 5 June 2018, ICANN’s CEO and President, Göran Marby,
shared information about ICANN org’s “internal” efforts to be GDPR compliant via a blog. In the blog, Göran shared that several of ICANN’s policies have been updated. These include an updated online</span><span style="color:black"> </span><a href="https://www.icann.org/privacy/policy"><span style="color:#954F72">Privacy
Policy</span></a><span style="color:#4472C4">, a revised</span><span style="color:black"> </span><a href="https://www.icann.org/privacy/tos"><span style="color:#954F72">Terms of Service</span></a><span style="color:#4472C4">, a revised</span><span style="color:black"> </span><a href="https://www.icann.org/privacy/cookies"><span style="color:#954F72">Cookies
Policy</span></a><span style="color:#4472C4">, a new </span><a href="https://www.icann.org/privacy/applicantnotice"><span style="color:#954F72">Notice of Applicant Privacy</span></a><span style="color:black"> </span><span style="color:#4472C4">(relating to
data processed for employment applications), and a revised </span><a href="https://newgtlds.icann.org/en/applicants/agb/program-privacy"><span style="color:#954F72">New gTLD Program Personal Data Privacy Statement</span></a><span style="color:#4472C4">. Additionally,
ICANN org has also rolled out internal changes to the way we handle personal data, from data processing arrangements with vendors to our various personnel policies. Read the full blog</span><span style="color:black"> </span><a href="https://www.icann.org/news/blog/data-protection-privacy-update-icann-s-gdpr-efforts-with-temporary-specification-now-in-effect"><span style="color:#954F72">here</span></a><span style="color:#4472C4">.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:black"> </span><o:p></o:p></p>
<ol style="margin-top:0in" start="6" type="1">
<li class="MsoNormal" style="color:black;mso-list:l5 level1 lfo3">The Council envisioned, via the EPDP Charter, to have direct participation of ICANN org liaisons, within the EPDP Team. As we leave the Triage and head into substantive detail, do the ICANN liaisons
see a role or specific set of actions for ICANN supporting the team?<o:p></o:p></li></ol>
<p class="MsoListParagraph"><span style="color:#4472C4">RESPONSE: Section III of the EPDP Charter describes the role of ICANN org liaisons as “ICANN Staff Liaison: The ICANN Org GDD and Legal Liaisons are expected to provide timely input on issues that may
require ICANN Org input such as implementation-related queries. The ICANN Staff Liaisons are not expected to advocate for any position and/or participate in any EPDP Team consensus calls.” In line with this description of ICANN org liaisons’ role, Göran Marby’s
<a href="https://www.icann.org/en/system/files/correspondence/marby-to-forrest-et-al-02aug18-en.pdf">
response</a> to the GNSO Council regarding a request for appointment of ICANN org liaisons confirmed the scope of participation of the ICANN org liaisons as “Trang Nguyen from ICANN organization’s Global Domains Division and Dan Halloran from ICANN’s legal
team will join the working group’s mailing list and the group’s calls to coordinate responses to requests for GDD or legal input as needed to support the working group’s deliberations. Such requests will ordinarily be responded to in writing, following consultation
with internal and external experts as appropriate.” </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</body>
</html>