<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 name=Title content=""><meta name=Keywords content=""><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:"Courier New";
panose-1:2 7 3 9 2 2 5 2 4 4;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.msoIns
{mso-style-type:export-only;
mso-style-name:"";
text-decoration:underline;
color:teal;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@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:447551630;
mso-list-template-ids:1661271548;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New",serif;
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:630749115;
mso-list-type:hybrid;
mso-list-template-ids:488777662 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New",serif;}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New",serif;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New",serif;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l2
{mso-list-id:1376274856;
mso-list-type:hybrid;
mso-list-template-ids:1265121732 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New",serif;}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New",serif;}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New",serif;}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style></head><body bgcolor=white lang=EN-US link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal>Dear All,</p><p class=MsoNormal> </p><p class=MsoNormal>For your information, please find below the notes and action items of small team #2, which met last week to discuss:</p><p class=MsoNormal> </p><p class=MsoNormal>h) <b>Applicability of Data Processing Requirements</b></p><p class=MsoNormal>h1) Should Registry Operators and Registrars (“Contracted Parties”) be permitted or required to differentiate between registrants on a geographic basis?</p><p class=MsoNormal>h2) Is there a legal basis for Contracted Parties to differentiate between registrants on a geographic basis?</p><p class=MsoNormal> </p><p class=MsoNormal>Best regards,</p><p class=MsoNormal> </p><div style='mso-element:para-border-div;border:none;border-bottom:solid windowtext 1.5pt;padding:0in 0in 1.0pt 0in'><p class=MsoNormal style='border:none;padding:0in'>Marika, Berry and Caitlin</p><p class=MsoNormal style='border:none;padding:0in'><o:p> </o:p></p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Small Group 2 High-level agreements (Geographic Basis)</p><p class=MsoNormal> </p><table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0 style='border-collapse:collapse'><tr style='height:610.0pt'><td valign=top style='border:solid black 1.0pt;padding:5.0pt 5.0pt 5.0pt 5.0pt;height:610.0pt'><p class=MsoNormal><b>Charter question h1) Should Registry Operators and Registrars (“Contracted Parties”) be permitted or required to differentiate between registrants on a geographic basis?</b></p><p class=MsoNormal> </p><p class=MsoNormal>1. The group seems to agree that contracted parties should be <i>permitted</i> to differentiate on a geographic basis, but there is not agreement whether differentiation should be required or explored.</p><p class=MsoNormal> </p><p class=MsoNormal>2. The members who believe geographical differentiation should NOT be required identified several concerns. Specifically, those not in support noted:</p><p class=MsoNormal><o:p> </o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>the actual location of the registrant is not alone dispositive of whether GDPR applies especially because of the widespread industry use of additional processors (e.g., backend registry service providers and resellers for registry operators and registrars, respectively).</li><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>data subjects need to be informed at the time of collection about how their personal data is being processed, i.e. what data is collected, to whom it is transferred, how long it is stored etc. Also, information on the data subject’s rights needs to be provided, such as the right of access, right to rectification, right to erasure and the right to data portability. Not having a common approach for all registered name holders would give some RNHs these rights, while others would not get such rights. That would potentially lead to two classes of RNHs, which should be avoided.</li><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>ICANN is about “one world - one Internet”, i.e., global standards and interoperability. Such interoperability would be lost and fragmentation in the marketplace would occur if there were no requirement for taking a single approach at the global level.</li><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>there are significant liability implications for Contracted Parties if they are incorrect</li><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>any consensus policy needs to be commercially reasonable and implementable, and in the current market place, differentiation based on geographic location will be difficult to scale</li><li class=MsoListParagraph style='margin-left:0in;mso-list:l2 level1 lfo2'>ICANN policies should not create competitive advantages for some contracted parties over others - such as a policy may result in certain ICANN accredited Registrars and/or gTLD Registry Operators to seem less appealing to customers (RNHs) due to their establishment in jurisdictions with less stringent privacy protection </li></ul><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>3. The members who believe geographical differentiation SHOULD be required; however, they identified several concerns. Specifically, those in support of required differentiation noted:</p><p class=MsoNormal><o:p> </o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraph style='margin-left:0in;mso-list:l1 level1 lfo3'>When GDPR was adopted, the global nature of the DNS was not taken into account. It therefore may be shortsighted of the EPDP Team to just focus on GDPR.</li><li class=MsoListParagraph style='margin-left:0in;mso-list:l1 level1 lfo3'>Applying GDPR to all registrants would undermine the role of sovereign states to be able to enforce their own laws and regulations.</li><li class=MsoListParagraph style='margin-left:0in;mso-list:l1 level1 lfo3'>Businesses are always required to take into account local laws when choosing to do business with various countries; therefore, cost is not necessarily a persuasive argument to not require differentiation.</li><li class=MsoListParagraph style='margin-left:0in;mso-list:l1 level1 lfo3'>The Expert Working Group developed a rules engine; perhaps the group can recommend future exploration of the EWG rules engine to see if it is feasible.</li></ul><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>4. Some expressed that one option for future exploration could be to consider the EWG rules engine to see if this is a feasible differentiation mechanism or if a differentiation mechanism could be developed in the future. </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>For background, the <a href="https://www.icann.org/en/system/files/files/final-report-06jun14-en.pdf">EWG Report</a> reflected the consensus position of experts convened by the ICANN Board of Directors in 2012 to propose a new policy for WHOIS that complied with applicable privacy regulations, including GDPR. The EWG Report states: </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><i>The RDS could provide for a legal compartmentalization. Specifically, data elements could be tagged according to the applicable law for the data subject (i.e., the Registrant) and treated accordingly. To achieve this legal compartmentalization, the RDS could implement a “rules engine” that would apply the applicable data protection laws to each specific transfer. More specifically, “rules engine” refers to a feature that could be implemented within the RDS to manage (a) the storage, collection and processing of domain name information based on Registrant, Contact, Registrar, Registry, and RDS jurisdictions (represented by the following data elements: Registrant and Contact Country Code, Registrar and Registry Jurisdictions), and (b) data protection laws of the applicable jurisdictions, in accordance with ICANN's future defined policy for the RDS.</i></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The EWG then made the following recommendation:</p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>107. An information system to apply data protection laws (i.e., a “rules engine”) and localization of RDS data storage must be considered as two means of implementing the high level of data protection required. This must be ensured through standard contractual clauses, which flow from a logical privacy policy for the RDS ecosystem. </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>Charter question h2) Is there a legal basis for Contracted Parties to differentiate b/w registrants on a geographic basis?</b></p><p class=MsoNormal> </p><p class=MsoNormal>Yes, there is a legal basis for contracted parties to differentiate b/w registrants on a geographic basis. However, the location of the registrant alone is not a dispositive indicator if the GDPR applies. If the controller or any processor is within the EU, the GDPR will also apply.</p></td></tr></table><p class=MsoNormal> </p><p class=MsoNormal> </p><p class=MsoNormal><i>These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/2IpHBQ.</i></p><p class=MsoNormal> </p><p class=MsoNormal>1. Roll Call & SOI Updates (5 minutes)</p><p class=MsoNormal>Attendance will be taken from Adobe Connect</p><p class=MsoNormal>Please remember to mute your microphones when not speaking, and state your name before speaking for transcription purposes.</p><p class=MsoNormal>Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team.</p><p class=MsoNormal> </p><p class=MsoNormal>h) Applicability of Data Processing Requirements</p><p class=MsoNormal>h1) Should Registry Operators and Registrars (“Contracted Parties”) be permitted or required to differentiate between registrants on a geographic basis?</p><p class=MsoNormal> </p><p class=MsoNormal>· The group needs to define the data subject. There are five possible options:</p><p class=MsoNormal> </p><p class=MsoNormal>o 1. Anyone who is physically located within the borders of the EU, so his data is being processed while he resides in the EU - that would include tourists or people on business trips (and this could extend to months)</p><p class=MsoNormal>o 2. A resident of the EU (that is a non EU citizen who has residency in an EU country) and is within the EU borders</p><p class=MsoNormal>o 3. An EU citizen who is within the EU borders</p><p class=MsoNormal>o 4. An EU citizen or resident who is physically located anywhere and whose data is being processed</p><p class=MsoNormal>o 5. A data subject who is located anywhere and his data is being processed in the EU</p><p class=MsoNormal> </p><p class=MsoNormal>· The group should work on a policy with the type of data covered by GDPR and the types of data that are not.</p><p class=MsoNormal> </p><p class=MsoNormal>· The group needs to distinguish two layers: (1) what is compliant with GDPR; (2) the policy. Regarding compliance, it's not just entities/persons in the EU, we must also discuss controllers/processors. The policy question to ask: do we want fragmentation in the marketplace - do we want operators to distinguish b/w those who fall under GDPR and who don't? ICANN is about avoiding fragmentation and interoperability of the marketplace. Accordingly, it may be preferred to registries/registrars to treat all customers the same.</p><p class=MsoNormal> </p><p class=MsoNormal>· >From a policy perspective, this is not the first time that privacy and data protection laws has come up at ICANN. We need to be compliant with GDPR, but the policy should not be restricted to GDPR as privacy laws will change over time. It would be more straightforward across the board if the policy didn't only apply to the EU. Contracted parties should not have to differentiate on a geographic basis.</p><p class=MsoNormal> </p><p class=MsoNormal>· The group needs to focus on where the processing activities are occurring - does the controlling/processing activities occur in the EU?</p><p class=MsoNormal> </p><p class=MsoNormal>Q: How does the group feel about the proposal that registry/registrar should apply the same standards across the board for data processing?</p><p class=MsoNormal> </p><p class=MsoNormal>· Registry operators should not be required to differentiate b/w registrars on a geographic basis for the following reasons:</p><p class=MsoNormal>o the actual location of the registrant is not alone dispositive of whether GDPR applies</p><p class=MsoNormal>o significant liability implications of being wrong</p><p class=MsoNormal>o importantly for registries, practical implementation consideration. The RySG believes that any consensus policy needs to be commercially reasonable and implementable. There could be a situation where a Ry (the controller) is not in the EU, the RNH is not in the EU, but the backend provider is. There is also a large reseller market in the registrar space. There are some scaling issues in thinking of all of the various scenarios.</p><p class=MsoNormal> </p><p class=MsoNormal>· From a policy point of view, it would be better to have a non-fragmented internet. From a practical and implementation point of view, this may not be an easy thing to do.</p><p class=MsoNormal> </p><p class=MsoNormal>· There was a consensus recommendation that came out of the EWG - they came up with the rules engine, which was the approach to apply the applicable policy for privacy laws. When GDPR was adopted, the DNS was not taken into account. It is shortsighted of us to just focus on GDPR.</p><p class=MsoNormal> </p><p class=MsoNormal>· The contracted parties may be permitted to differentiate b/w registrants on a geographic basis - the policy should not be applied in a universal manner. The group needs to also take into account data protection laws worldwide.</p><p class=MsoNormal> </p><p class=MsoNormal>· The group is trying to cope with policy vs. practical implementation issues. Being mindful of the Team's scope, which is to try to make the Temp Spec permanent and not a blue-sky redesign. Is specific geographic implementation possible?</p><p class=MsoNormal>o 1. Many countries are busy implementing their own privacy laws, partly b/c they want to set themselves up as a trading partner with the EU.</p><p class=MsoNormal>o 2. The GDPR covers EU citizens data.</p><p class=MsoNormal>o 3. The group is stuck with the ICANN model. There is a clear legal obligation for the publishing and processing of data. Any outcome of the discussion needs to be commercially reasonable. The only feasible and commercially reasonable position we can use at the moment is to implement the Temp Spec globally, but there may well be PDPs aimed at recognizing resellers that could help in identifying properly European individuals in the system.</p><p class=MsoNormal> </p><p class=MsoNormal>· ICANN has done a lot over the years to strengthen registrant rights. It is hard to explain to some registrants that they do not have the same rights as other registrants. Registrars needs to inform registrants about what data is used and for what - does this group want registrars to have to differentiate by registrant - this could lead to confusion and fragmentation.</p><p class=MsoNormal> </p><p class=MsoNormal>· There is also an issue of sovereignty. To apply EU rules to non-EU entities is not a good result.</p><p class=MsoNormal> </p><p class=MsoNormal>· We all, as companies, have to comply with the laws that apply to us. Just because it is costly is not a persuasive argument.</p><p class=MsoNormal> </p><p class=MsoNormal>· Cost of implementation should be a consideration and is a persuasive point. The cost for law enforcement and IP to access redacted data is also significant. The issue here is shifting the cost from one entity to another.</p><p class=MsoNormal> </p><p class=MsoNormal>· The Team should look at the matter from a policy point view saying that I would rather not see a fragmented Internet and all registrants to have the same level of protection everywhere</p><p class=MsoNormal> </p><p class=MsoNormal>· From a practical and implementation point of view, it will be very difficult to differentiate between registrants based on location; however, it is up to the registries and registrars to speak to this.</p><p class=MsoNormal> </p><p class=MsoNormal>· The future of the Internet and evolving technologies promises the need for global policies. In addition, and the Team must take into consideration the impact of its decisions on the business and industry.</p><p class=MsoNormal> </p><p class=MsoNormal>Recap:</p><p class=MsoNormal>1. The group would agree that contracted parties should be permitted to differentiate, but there is not agreement whether differentiation should be required.</p><p class=MsoNormal>2. The group thinks more work can be done regarding implementation of differentiation, e.g., associated costs, practicalities, etc.</p><p class=MsoNormal> </p><p class=MsoNormal>· Based on interventions by group members (Thomas, Hadia, Emily, Amr) there are group members that contracted parties should not be required to differentiate based on geographic basis - this may be rough consensus.</p><p class=MsoNormal> </p><p class=MsoNormal>· The small team should not use the term consensus as that term has a specific meaning in the GNSO.</p><p class=MsoNormal> </p><p class=MsoNormal>· We've addressed the legal basis in Charter Question h2.</p><p class=MsoNormal>· For h1, it would be best to summarize the key issues identified.</p><p class=MsoNormal>· Could part of the recommendation be to explore the EWG's rule engine?</p><p class=MsoNormal> </p><p class=MsoNormal> </p><p class=MsoNormal> </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>