<html xmlns:v="urn:schemas-microsoft-com:vml" 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: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;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 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;
color:black;}
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;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
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;
mso-add-space:auto;
font-size:12.0pt;
font-family:"Calibri",sans-serif;
color:black;}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst
{mso-style-priority:34;
mso-style-type:export-only;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
mso-add-space:auto;
font-size:12.0pt;
font-family:"Calibri",sans-serif;
color:black;}
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle
{mso-style-priority:34;
mso-style-type:export-only;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
mso-add-space:auto;
font-size:12.0pt;
font-family:"Calibri",sans-serif;
color:black;}
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast
{mso-style-priority:34;
mso-style-type:export-only;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
mso-add-space:auto;
font-size:12.0pt;
font-family:"Calibri",sans-serif;
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
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;
color:black;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle23
{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:276331849;
mso-list-type:hybrid;
mso-list-template-ids:-1828661762 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:366952027;
mso-list-type:hybrid;
mso-list-template-ids:1596613570 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2
{mso-list-id:1148551077;
mso-list-template-ids:1817848878;}
@list l3
{mso-list-id:1499030445;
mso-list-type:hybrid;
mso-list-template-ids:-845381000 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l3:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.25in;
text-indent:-.25in;
font-family:Symbol;}
@list l3:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:.75in;
text-indent:-.25in;
font-family:"Courier New";}
@list l3:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.25in;
text-indent:-.25in;
font-family:Wingdings;}
@list l3:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.75in;
text-indent:-.25in;
font-family:Symbol;}
@list l3:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.25in;
text-indent:-.25in;
font-family:"Courier New";}
@list l3:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.75in;
text-indent:-.25in;
font-family:Wingdings;}
@list l3:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.25in;
text-indent:-.25in;
font-family:Symbol;}
@list l3:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.75in;
text-indent:-.25in;
font-family:"Courier New";}
@list l3:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:4.25in;
text-indent:-.25in;
font-family:Wingdings;}
@list l4
{mso-list-id:1641307725;
mso-list-template-ids:319716722;}
@list l5
{mso-list-id:1672877994;
mso-list-template-ids:-144039390;}
@list l5: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 l5:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l5: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:Symbol;}
@list l5: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:Symbol;}
@list l5: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:Symbol;}
@list l5: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:Symbol;}
@list l5: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:Symbol;}
@list l5: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:Symbol;}
@list l5: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:Symbol;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-US link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;color:windowtext'>This is a note from the SSAC team. Volker frames this is a discussion about changing from SHOULD to MUST – but the opposite is true. The existing Consensus Policy says “MUST” and received the endorsement of the community and was approved by the GNSO and the Board. Attempts to change to “SHOULD” will overthrow that consensus, and are not justified. Aleeza’s notes are logical.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt'>The Temp Spec is Consensus Policy, and it says:</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt'>“5.1. Publication of Registration Data. Registry Operator and Registrar MUST comply with the requirements of, and MUST provide public access to Registration Data in accordance with, Appendix A attached hereto ("Appendix A").”</span> <span style='font-size:11.0pt'>And Appendix A says:</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt'>“4.1. Registrar and Registry Operator MUST provide reasonable access to Personal Data in Registration Data to third parties on the basis of a 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.”</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;color:windowtext'>There is no reason to go with “SHOULD”. If we use a MUST, and the registrar (or whoever) determines that the balancing test has not been met, it will not disclose. If the registrar (or whoever) determines that the balancing test has been met, then it MUST disclose. Because 1) that’s compliant with GDPR, and 2) that’s the reasonable expectation of the ICANN community, which expects contracted parties to participate, for all the good and justified reasons explained in Section 4 of the Temp Spec. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;color:windowtext'>We suggest the group focus on a solution to the real problem: what happens when a contracted party and a requestor disagree about whether the balancing test has been met. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;color:windowtext'>There will be honest disagreements between parties about whether a given case meets the balancing test. There will be cases where a contracted party withholds because it does not understand how to do the balancing test properly. (There are over a thousand contracted parties around the world, some of whom are not adequately educated or staffed to fulfill this function.) There will be contracted parties who are unreasonably conservative. And there may be contracted parties who will refuse disclosure for bad purposes, for example to hide malicious activity. What we know is that ICANN Compliance is not in a position to adjudicate balancing cases.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;color:windowtext'>There were some ideas floated in recent meetings about what to do here, and this area needs further work. For example, it is reasonable to require the disclosing party, upon request, to explain its reasons/justification for not disclosing the data. (And ICANN Compliance can be involved in this objectively, ensuring that the justification is shared.) As an escalation step, some sort of mandatory mediation could be useful. Such solutions can help educate the parties, which is always a helpful outcome. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;color:windowtext'>We do need a solution here, and a balanced one. Third-party requestors are recognized under GDPR and should have some recourse. It’s not balanced when a controller can deny any and all requests and can’t even be questioned about it. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;color:windowtext'>All best,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;color:windowtext'>--Greg<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;color:windowtext'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:11.0pt;color:windowtext'>From:</span></b><span style='font-size:11.0pt;color:windowtext'> Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> <b>On Behalf Of </b>Volker Greimann<br><b>Sent:</b> Thursday, December 19, 2019 5:20 AM<br><b>To:</b> gnso-epdp-team@icann.org<br><b>Subject:</b> Re: [Gnso-epdp-team] Action Items + timeline with upcoming deadlines for feedback<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p>Hi Eleeza,<o:p></o:p></p><p>we discussed this differentiation ad nauseam during on a different topic our last call and were unable to come to consensus to change to must. I suspect that this proposed change would lead to various parties to withdrawing their consensus on the recommendation. The recommendation was not written with compliance enforcement in mind as the most important goal but rather to create an expected outcome. <o:p></o:p></p><p>Further, even when including limiting factors to a "must" recommendation, these are not likely to be sufficient as this area of law is constantly evolving. <o:p></o:p></p><p>As for the higher burden on ICANN resulting from the reasonability test, this seems intentional to me. Enforcement should not be the norm but a result of special circumstances where unreasonableness can be demonstrated without reasonable doubt. <o:p></o:p></p><p>I therefore do not support the proposed change.<o:p></o:p></p><p>Best,<o:p></o:p></p><p>Volker<o:p></o:p></p><div><p class=MsoNormal>Am 19.12.2019 um 02:00 schrieb Eleeza Agopian:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p style='margin:0in;margin-bottom:.0001pt'>Dear EPDP Team, <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'>Thank you for the question you sent to ICANN org on 6 December 2019 regarding the potential enforcement of a “SHOULD” directive within an ICANN policy, specifically, the proposed draft recommendation text which initially read, “If, based on consideration of the above factors, the authorization provider determines that the requestor’s legitimate interest is not outweighed by the interests or fundamental rights and freedoms of the data subject, the data should be disclosed.” We understand that the team agreed to the following language on its 12 December 2019 plenary call: “If, based on consideration of the above factors, the authorization provider determines that the requestor’s legitimate interest is not outweighed by the interests or fundamental rights and freedoms of the data subject, the data <b>shall</b> be disclosed. The rationale for the approval should be documented.” While the team’s discussions have resulted in changing “SHOULD” to “SHALL,” we are providing this answer to close the loop on the team’s outstanding question. <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'>We note that this question was directed to ICANN Contractual Compliance and seems to assume that ICANN Contractual Compliance would have the contractual right to enforce such a requirement. However, in order to determine how or whether such language could or would be enforced by ICANN, we would need to know who the authorization provider is. For example, if the EPDP Team were to recommend that ICANN org play the role of authorization provider, ICANN would not be in a position to enforce its own compliance with such a requirement. Alternatively, if one or more third parties was the authorizer(s), then ICANN Contractual Compliance would not be involved in enforcement since compliance is only involved in gTLD registry and registrar contractual compliance enforcement. If contracted parties were required to act as authorizers, ICANN org would enforce such a requirement pursuant to the contracted parties’ agreements with ICANN. <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'>We believe that it would be difficult to enforce the proposed “SHOULD” obligation without clearly defined limitations on when “SHOULD” would not mean “MUST,” provided the word “SHOULD” is defined as in <a href="https://tools.ietf.org/html/rfc2119"><span style='color:#1155CC'>RFC 2119</span></a>. From the Compliance perspective, a requirement framed as “MUST,” which could be potentially limited by qualifying factors (such as “unless one of the following conditions applies”), could be more predictably enforced. <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'>“SHOULD” is defined in <a href="https://tools.ietf.org/html/rfc2119"><span style='color:#1155CC'>RFC 2119 </span></a> as follows: “This word ... mean[s] that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.” <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'>For example, if the registrar is subject to a requirement that it SHOULD disclose data, and the registrar contended that it decided not to disclose requested data based on reasons it has identified as valid, the registrar would not necessarily be found to be in violation of a requirement that it SHOULD disclose data. This is essentially a “reasonableness” test, but ICANN would face a significant burden to demonstrate that a registrar was acting unreasonably. <o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p style='margin:0in;margin-bottom:.0001pt'>Based on the above, ICANN org strongly recommends the use of the word “MUST,” with an accompanying list of defined exceptions, rather than a “SHOULD.”<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt'>Thank you, </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='font-size:11.0pt'>Eleeza and Dan</span><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt'>ICANN org liaisons</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='font-size:11.0pt'> </span><o:p></o:p></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From: </b>Gnso-epdp-team <a href="mailto:gnso-epdp-team-bounces@icann.org"><gnso-epdp-team-bounces@icann.org></a> on behalf of Caitlin Tubergen <a href="mailto:caitlin.tubergen@icann.org"><caitlin.tubergen@icann.org></a><br><b>Date: </b>Friday, December 6, 2019 at 8:29 AM<br><b>To: </b><a href="mailto:gnso-epdp-team@icann.org">"gnso-epdp-team@icann.org"</a> <a href="mailto:gnso-epdp-team@icann.org"><gnso-epdp-team@icann.org></a><br><b>Subject: </b>[Gnso-epdp-team] Action Items + timeline with upcoming deadlines for feedback<o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:11.0pt'> </span><o:p></o:p></p></div><p class=MsoNormal>Dear EPDP Team,<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal>As shared during yesterday’s meeting, please find attached the proposed timelines and deadlines to get to the Initial Report by early February. As a reminder, please provide your input on the Initial Report language on:<o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraphCxSpFirst style='margin-left:-.25in;mso-add-space:auto;mso-list:l3 level1 lfo3;text-autospace:none'><span style='color:windowtext'><a href="https://docs.google.com/document/d/1eZBzRclRtEXPp1EScDfftnfnv9tneD7ovxmGe84BQz4/edit">Terms of use</a></span><o:p></o:p></li><li class=MsoListParagraphCxSpLast style='margin-left:-.25in;mso-add-space:auto;mso-list:l3 level1 lfo3;text-autospace:none'><span style='color:windowtext'><a href="https://docs.google.com/document/d/1KCzlakWVkt6GN5ZPl0my45WdR34JPes_bZwmJkY9Z3k/edit">Automation</a></span><o:p></o:p></li></ul><p class=MsoNormal style='text-autospace:none'> <o:p></o:p></p><p class=MsoNormal style='text-autospace:none'>by <b><u>Sunday 8 December at the latest</u></b>. The comments and suggestions made by the deadline will serve as the guide for discussion during the meeting on 10 December 2019. Please also take note of the other upcoming deadlines to plan your work accordingly. <o:p></o:p></p><p class=MsoNormal style='text-autospace:none'> <o:p></o:p></p><p class=MsoNormal style='text-autospace:none'>Other action items and high-level notes for Tuesday’s meeting are:<o:p></o:p></p><p class=MsoNormal style='text-autospace:none'> <o:p></o:p></p><ol style='margin-top:0in' start=1 type=1><li class=MsoListParagraphCxSpFirst style='margin-left:0in;mso-add-space:auto;mso-list:l1 level1 lfo6;text-autospace:none'>EPDP Leadership to further consider the appropriate channel to further consider the geographic differentiation issue.<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l1 level1 lfo6;text-autospace:none'>EPDP Team may continue to provide comments on the structure, formatting, and diagrams within the <span style='color:windowtext'><a href="https://docs.google.com/document/d/1isn0eJsqw-g-qvqRbocM6849OWpFl0WG/edit">Initial Report Google Doc</a></span> in comment mode (please refrain from line edits in the document).<o:p></o:p></li><li class=MsoListParagraphCxSpMiddle style='margin-left:0in;mso-add-space:auto;mso-list:l1 level1 lfo6;text-autospace:none'>EPDP Team to provide additional comments (if any) on the <a href="https://docs.google.com/document/d/1XeHP_YZN7fR0LwQ4DzRuY9PqB39uOzHXot-yH0fcvbc/edit">Authorization Provider Building Block</a> by Friday, 6 December.<o:p></o:p></li><li class=MsoListParagraphCxSpLast style='margin-left:0in;mso-add-space:auto;mso-list:l1 level1 lfo6;text-autospace:none'>EPDP Support Staff to propose compromise text, where possible, in response to the Team’s discussion and additional comments for the <a href="https://docs.google.com/document/d/1XeHP_YZN7fR0LwQ4DzRuY9PqB39uOzHXot-yH0fcvbc/edit">Authorization Provider</a> Building Block for the Team’s review by <b>Monday, 9 December</b>.<o:p></o:p></li></ol><p class=MsoNormal style='text-autospace:none'> <o:p></o:p></p><p class=MsoNormal style='text-autospace:none'>Questions for ICANN org:<o:p></o:p></p><p class=MsoNormal style='text-autospace:none'> <o:p></o:p></p><ol style='margin-top:0in' start=1 type=1><li class=MsoListParagraph style='margin-left:0in;mso-add-space:auto;mso-list:l0 level1 lfo9;text-autospace:none'>Could ICANN org provide detail on how/if it would enforce a policy with a “should” directive? By way of example, how would the following text be enforced? “If, based on consideration of the above factors, the authorization provider determines that the requestor’s legitimate interest is not outweighed by the interests or fundamental rights and freedoms of the data subject, the data <i>should</i> be disclosed.” (emphasis added) <o:p></o:p></li></ol><p class=MsoNormal style='text-autospace:none'> <o:p></o:p></p><p class=MsoNormal style='text-autospace:none'>Best regards, <o:p></o:p></p><p class=MsoNormal style='text-autospace:none'> <o:p></o:p></p><p class=MsoNormal style='text-autospace:none'>Marika, Berry, and Caitlin<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt'> </span><o:p></o:p></p><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt'><o:p> </o:p></span></p><pre>_______________________________________________<o:p></o:p></pre><pre>Gnso-epdp-team mailing list<o:p></o:p></pre><pre><a href="mailto:Gnso-epdp-team@icann.org">Gnso-epdp-team@icann.org</a><o:p></o:p></pre><pre><a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team">https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a><o:p></o:p></pre><pre>_______________________________________________<o:p></o:p></pre><pre>By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://www.icann.org/privacy/tos">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.<o:p></o:p></pre></blockquote><div><p class=MsoNormal><span style='font-size:11.0pt'>-- <br>Volker A. Greimann<br>General Counsel and Policy Manager<br><strong><span style='font-family:"Calibri",sans-serif'>KEY-SYSTEMS GMBH</span></strong><br><br>T: +49 6894 9396901<br>M: +49 6894 9396851<br>F: +49 6894 9396851<br>W: <a href="http://www.key-systems.net">www.key-systems.net</a><br><br>Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835<br>CEO: Alexander Siffrin<br><br>Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.<o:p></o:p></span></p></div></div></body></html>