<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)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><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;}
@font-face
        {font-family:Verdana;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:"Helvetica Neue Light";
        panose-1:2 0 4 3 0 0 0 2 0 4;}
@font-face
        {font-family:"Helvetica Neue";
        panose-1:2 0 5 3 0 0 0 2 0 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 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:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        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";}
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:11.0pt;
        font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;}
p.xmsonormal, li.xmsonormal, div.xmsonormal
        {mso-style-name:x_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.EmailStyle22
        {mso-style-type:personal;
        font-family:"Helvetica Neue";
        color:windowtext;}
span.EmailStyle23
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle25
        {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:620957373;
        mso-list-template-ids:417382002;}
@list l1
        {mso-list-id:646055128;
        mso-list-template-ids:426006454;}
@list l2
        {mso-list-id:1035042731;
        mso-list-type:hybrid;
        mso-list-template-ids:1798723012 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l2:level1
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l2:level2
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l2:level3
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l2:level4
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l2:level5
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l2:level6
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l2:level7
        {mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l2:level8
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l2:level9
        {mso-level-number-format:roman-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:right;
        text-indent:-9.0pt;}
@list l3
        {mso-list-id:1372536916;
        mso-list-template-ids:372659024;}
@list l3:level1
        {mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l3:level2
        {mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l3:level3
        {mso-level-tab-stop:1.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l3:level4
        {mso-level-tab-stop:2.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l3:level5
        {mso-level-tab-stop:2.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l3:level6
        {mso-level-tab-stop:3.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l3:level7
        {mso-level-tab-stop:3.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l3:level8
        {mso-level-tab-stop:4.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l3:level9
        {mso-level-tab-stop:4.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l4
        {mso-list-id:1566914437;
        mso-list-template-ids:1991142216;}
@list l4:level1
        {mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l4:level2
        {mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l4:level3
        {mso-level-tab-stop:1.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l4:level4
        {mso-level-tab-stop:2.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l4:level5
        {mso-level-tab-stop:2.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l4:level6
        {mso-level-tab-stop:3.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l4:level7
        {mso-level-tab-stop:3.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l4:level8
        {mso-level-tab-stop:4.0in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l4:level9
        {mso-level-tab-stop:4.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l5
        {mso-list-id:1833641886;
        mso-list-template-ids:794727014;}
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 lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi all,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">First off, happy Friday to all! This is a good discussion and really getting at the heart of what decisions we need to make in our work to get any kind of recommendations across the finish line.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Brian – can I just clarify your note below please? If I understand correctly, you are indicating the contracted parties are, in fact, the controllers and continue to have liability with regard to non-public data but you
<b>DO NOT</b> want them to have the ability to reject any requests for non-public data that flow to them through the SSAD? Did I get that right?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I can understand a scenario where that would be advisable if the contracted parties were processers of the data, but having a hard time seeing how this would be possible when it has been established that CP’s are actually controllers.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Might be something that’s better discussed on a future call, but I do think this is certainly a question that needs to be addressed.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Have a good weekend all!<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Matt <o:p></o:p></p>
<p class="MsoNormal"><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><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of "King, Brian via Gnso-epdp-team" <gnso-epdp-team@icann.org><br>
<b>Reply-To: </b>"King, Brian" <Brian.King@markmonitor.com><br>
<b>Date: </b>Friday, September 20, 2019 at 12:51 PM<br>
<b>To: </b>"James M. Bladel" <jbladel@godaddy.com>, "Heineman, Ashley" <AHeineman@ntia.gov>, Greg Aaron <greg@illumintel.com>, 'Sarah Wyld' <swyld@tucows.com>, "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org><br>
<b>Subject: </b>Re: [Gnso-epdp-team] Questions regarding disclosure risks<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Hi all,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">I would like to thank Sarah, Greg, and Mark Sv for helping us organize these concepts and frame the possible options. I support James’ request to staff, noting that ICANN’s preferences, while not dispositive, are valuable input for our
 work. <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Good point, Ashley.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">James, I think we’re mostly on board, and there is additional value to the CPs in the model you outline if there is no right to deny the request. The Bird & Bird memo notes that, “a CP's liability under the GDPR is significantly affected
 by whether it is a "controller" or a "processor", and that this determination hinges on three factors:
<o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level1 lfo3">The degree of actual control exercised by a party,<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level1 lfo3">The image given to data subjects, and<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level1 lfo3">Reasonable expectations of data subjects on the basis of this visibility.
<o:p></o:p></li></ol>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">We can (and should) drastically influence 2 and 3 with policy recommendations that require crystal-clear notice to registrants about how registration data will be processed. We identified this opportunity early on as the RAA is insufficiently
 vague, and I think we’re probably unanimous on this. <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">The remaining factor tending to increase CP liability is the degree of actual control exercised, or “the right to deny the request.” I understand that the ability to deny requests appears attractive for risk mitigation, but I implore CPs
 and the EPDP team to understand that this would increase liability for CPs. <o:p>
</o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal"><b><span lang="EN-GB" style="font-size:10.0pt;color:black">Brian J. King
</span></b><span lang="EN-GB" style="font-size:10.0pt;color:black"> <br>
Director of Internet Policy and Industry Affairs</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:10.0pt;color:black"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:10.0pt;color:black">T +1 443 761 3726</span><u><span style="font-size:10.0pt;color:#0563C1"><a href="http://www.markmonitor.com"><span lang="EN-GB" style="color:#0563C1"><br>
</span><span style="color:#0563C1">markmonitor.com</span></a></span></u><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><b><span lang="EN-GB" style="font-size:10.0pt;color:black">MarkMonitor<br>
</span></b><span lang="EN-GB" style="font-size:10.0pt;color:black">Protecting companies and consumers in a digital world</span><o:p></o:p></p>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Gnso-epdp-team <gnso-epdp-team-bounces@icann.org>
<b>On Behalf Of </b>James M. Bladel<br>
<b>Sent:</b> Friday, September 20, 2019 2:24 PM<br>
<b>To:</b> Heineman, Ashley <AHeineman@ntia.gov>; Greg Aaron <greg@illumintel.com>; 'Sarah Wyld' <swyld@tucows.com>; gnso-epdp-team@icann.org<br>
<b>Subject:</b> Re: [Gnso-epdp-team] Questions regarding disclosure risks<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue"">Greg – I think we’re assuming that there’s no scenario where ICANN wants (or is able) to operate a replica of all gTLD RDS.  But we still need them to explicitly state this, so
 we can work around it and move on.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue""> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue"">Ashely –  Contracted Parties have had some (informal) discussions about our preferred model, and I think your description is closest to the mark.  </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue""> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue"">Some “entity” takes the request, checks it for accuracy/validity, and then relays it to the appropriate Contracted Party.  The CP then responds
<b>to the entity</b>, either by providing the non-public data or issuing a denial (with rationale).  In this approach the Contracted Party is only concerned with transactions to the centralized entity, and retains the right to deny the request if something
 doesn’t pass the smell test. CPs also recognize that some degree of credential & request verification “pre-screening” has already taken place. Requestors have the benefit of a single point of contact with a standardized request format for all TLDs/Registrars.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue""> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue"">The question in front of us Is whether or not ICANN is willing & able to assume that role -- either directly or by creating/delegating some other entity.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue""> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue"">J.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue""> </span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-family:"Helvetica Neue Light"">-------------</span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-family:"Helvetica Neue Light";color:#00B050">James Bladel</span></b><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family:"Helvetica Neue Light"">GoDaddy</span><o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue""> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue""> </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><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">"Heineman, Ashley" <<a href="mailto:AHeineman@ntia.gov">AHeineman@ntia.gov</a>><br>
<b>Date: </b>Friday, September 20, 2019 at 13:10<br>
<b>To: </b>"James M. Bladel" <<a href="mailto:jbladel@godaddy.com">jbladel@godaddy.com</a>>, Greg Aaron <<a href="mailto:greg@illumintel.com">greg@illumintel.com</a>>, 'Sarah Wyld' <<a href="mailto:swyld@tucows.com">swyld@tucows.com</a>>, "<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>Re: [Gnso-epdp-team] Questions regarding disclosure risks</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div style="border:none;border-left:solid #A6A6A6 4.5pt;padding:0in 0in 0in 14.0pt">
<p class="MsoNormal" style="background:#EBEBEB"><span style="font-size:9.0pt;font-family:"Tahoma",sans-serif;color:black">Notice:</span><span style="color:black">
</span><span style="font-size:9.0pt;font-family:"Tahoma",sans-serif;color:black">This email is from an external sender.
</span><o:p></o:p></p>
</div>
<p> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">Hi all.  Thanks for this and a quick question on the questions.  Does ICANN *have to* establish a replica database in this scenario?  Can't the information just more or less pass through ICANN? 
 That would mean less data being transferred and could also presumably less data stored/retained.  Right?  Just thinking out loud in an effort to identify other options so we don't unintentionally box ourselves in.  </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">Thanks!</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">Ashley (GAC)</span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> </span><o:p></o:p></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="98%" align="center">
</div>
<div id="divRplyFwdMsg">
<p class="MsoNormal"><b><span style="color:black">From:</span></b><span style="color:black"> Gnso-epdp-team <<a href="mailto:gnso-epdp-team-bounces@icann.org">gnso-epdp-team-bounces@icann.org</a>> on behalf of James M. Bladel <<a href="mailto:jbladel@godaddy.com">jbladel@godaddy.com</a>><br>
<b>Sent:</b> Friday, September 20, 2019 11:35 AM<br>
<b>To:</b> Greg Aaron <<a href="mailto:greg@illumintel.com">greg@illumintel.com</a>>; 'Sarah Wyld' <<a href="mailto:swyld@tucows.com">swyld@tucows.com</a>>;
<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> Re: [Gnso-epdp-team] Questions regarding disclosure risks</span> <o:p>
</o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">Greg et al -<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Sarahs’ Alt super powers expired at midnight yesterday and her laptop has now turned back in to a pumpkin.  So I’ll respond to Greg and pose a few questions to ICANN Staff.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Greg - In this case, Yes. “Addressed” = making the disclosure decision, and (if affirmative) providing the Requestor with the requested non-public data.  For clarity, “provided” can mean that ICANN sends the data directly to the Requestor,
 or somehow <b>causes</b> another (contracted) party to transmit the data to the Requestor.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Many EPDP members have expressed a desire to work with ICANN directly, rather than route requests to  individual Contracted Parties.  They would also prefer to have ICANN make the disclosure determination, as opposed to leaving this to
 the affected Contracted Party (please jump in if I’m misunderstanding/mischaracterizing this point).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Therefore, the questions we (me, Sarah, Registrars, ePDP) would like to refer to our Staff Liaisons are:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Does ICANN have a clear preference on whether or not it will:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">1. Field these requests for non-public data<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2. Maintain its own RDS replica database<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">3. Make a/the determination of the validity of the request<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">4. Assume responsibility for this decision, in any scenario where ICANN doesn’t hold the data directly and must require a Contracted Party to respond to the Requestor (even if the Contracted Party disputes ICANN’s determination).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">We have been dancing around these questions for a quite a while, and I now believe the answers stand between us and progress on our work.  Either ICANN agrees to assume some/all of the role of decision-maker (and accept responsibility for
 making this decision), or we abandon the “centralized” version of SSAD and instead focus our efforts on developing a distributed model (which is expressly opposed by some “requestor” stakeholders).  <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Either way, the is the fork in the road, and we need a clear path forward. If there are no further questions or objections, I recommend that Marika/Staff refer this to our liaisons.  <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks—<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">J.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">_______________<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">James Bladel<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">GoDaddy<o:p></o:p></p>
</div>
</div>
</div>
<div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="98%" align="center">
</div>
<div id="x_divRplyFwdMsg">
<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 Greg Aaron <<a href="mailto:greg@illumintel.com">greg@illumintel.com</a>><br>
<b>Sent:</b> Thursday, September 19, 2019 14:25<br>
<b>To:</b> 'Sarah Wyld'; <a href="mailto:gnso-epdp-team@icann.org">gnso-epdp-team@icann.org</a><br>
<b>Subject:</b> Re: [Gnso-epdp-team] Questions regarding disclosure risks <o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div style="border:none;border-left:solid #A6A6A6 4.5pt;padding:0in 0in 0in 14.0pt">
<p class="MsoNormal" style="background:#EBEBEB"><span style="font-size:9.0pt;font-family:"Tahoma",sans-serif;color:black">Notice:This email is from an external sender.
</span><o:p></o:p></p>
</div>
<p> <o:p></o:p></p>
<div>
<div>
<p class="xmsonormal">When you say “addressed” what do you mean -- that ICANN decides whether the data should be disclosed in response to a query?<o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="xmsonormal"><b>From:</b> Sarah Wyld <<a href="mailto:swyld@tucows.com">swyld@tucows.com</a>><br>
<b>Sent:</b> Thursday, September 19, 2019 11:16 AM<br>
<b>To:</b> Greg Aaron <<a href="mailto:greg@illumintel.com">greg@illumintel.com</a>>;
<a href="mailto:gnso-epdp-team@icann.org">gnso-epdp-team@icann.org</a><br>
<b>Subject:</b> Re: [Gnso-epdp-team] Questions regarding disclosure risks<o:p></o:p></p>
</div>
</div>
<p class="xmsonormal"><span style="color:#000066"> </span><o:p></o:p></p>
<p><span style="font-size:10.0pt;font-family:"Verdana",sans-serif">Hi Greg,<br>
<br>
"Responding party" here would mean that requests are received and addressed by ICANN Org. This email focused specifically on questions raised by ICANN Org working in this capacity, I'm interested to see what other scenarios you could expect to occur here.</span><o:p></o:p></p>
<p><span style="font-size:10.0pt;font-family:"Verdana",sans-serif">Thanks.</span><o:p></o:p></p>
<pre><span style="color:#000066">-- </span><o:p></o:p></pre>
<pre><span style="color:#000066">Sarah Wyld</span><o:p></o:p></pre>
<pre><span style="color:#000066">Domains Product Team</span><o:p></o:p></pre>
<pre><span style="color:#000066">Tucows</span><o:p></o:p></pre>
<pre><span style="color:#000066">+1.416 535 0123 Ext. 1392</span><o:p></o:p></pre>
<pre><span style="color:#000066"> </span><o:p></o:p></pre>
<pre><span style="color:#000066"> </span><o:p></o:p></pre>
<div>
<p class="xmsonormal"><span style="color:#000066">On 9/19/2019 10:12 AM, Greg Aaron wrote:</span><o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="xmsonormal">Sarah, what do you mean by “responding party”?  For example so your scenarios assume that ICANN is acting in a specific legal capacity?<o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal">I ask because depending on what you mean, there may be other scenarios.<o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal">All best,<o:p></o:p></p>
<p class="xmsonormal">--Greg<o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<p class="xmsonormal"> <o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="xmsonormal"><b>From:</b> Gnso-epdp-team<span style="color:#000066"><a href="mailto:gnso-epdp-team-bounces@icann.org"><gnso-epdp-team-bounces@icann.org></a></span><b>On Behalf Of
</b>Sarah Wyld<br>
<b>Sent:</b> Wednesday, September 18, 2019 3:18 PM<br>
<b>To:</b> <span style="color:#000066"><a href="mailto:gnso-epdp-team@icann.org">gnso-epdp-team@icann.org</a></span><br>
<b>Subject:</b> [Gnso-epdp-team] Questions regarding disclosure risks<o:p></o:p></p>
</div>
</div>
<p class="xmsonormal"><span style="color:#000066"> </span><o:p></o:p></p>
<p>Hello all,<o:p></o:p></p>
<p>During the recent EPDP face-to-face meetings in Los Angeles, several members of the working group expressed a desire to position ICANN as the responding party to requests for disclosure of non-public registration data.<br>
<br>
In order to fulfill this request, one of two things must be true. Either:<o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="xmsonormal" style="color:#000066;margin-top:0in;margin-bottom:0in;margin-bottom:.0001pt;mso-list:l3 level1 lfo6">
ICANN Org maintains a current (<24 hours) copy of the entire RDS database; or<o:p></o:p></li><li class="xmsonormal" style="color:#000066;margin-top:0in;margin-bottom:0in;margin-bottom:.0001pt;mso-list:l3 level1 lfo6">
ICANN has some mechanism (contract clause) to compel the Contracted Party to disclose the data to ICANN or the requestor<o:p></o:p></li></ol>
<p>These potential scenarios raise the following questions:<o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="xmsonormal" style="color:#000066;margin-top:0in;margin-bottom:0in;margin-bottom:.0001pt;mso-list:l4 level1 lfo9">
In the first scenario, does ICANN accept the legal risks and operational costs of maintaining its own replica of all RDS data for gTLDs? If not, how would those risks and costs be addressed?<o:p></o:p></li><li class="xmsonormal" style="color:#000066;margin-top:0in;margin-bottom:0in;margin-bottom:.0001pt;mso-list:l4 level1 lfo9">
In the second scenario, will ICANN “relay” disclosed data between the requestor and the Registry/Registrar?<o:p></o:p></li><li class="xmsonormal" style="color:#000066;margin-top:0in;margin-bottom:0in;margin-bottom:.0001pt;mso-list:l4 level1 lfo9">
What should be done in situations where ICANN instructs the Registry/Registrar to disclose data (either to ICANN or the requestor), but the contracted party has determined that the request is not legitimate and refuses? Is this matter referred to ICANN compliance?
<o:p></o:p></li></ol>
<p style="margin-bottom:12.0pt"><br>
Thank you, <o:p></o:p></p>
<pre><span style="color:#000066">-- </span><o:p></o:p></pre>
<pre><span style="color:#000066">Sarah Wyld</span><o:p></o:p></pre>
<pre><span style="color:#000066">Domains Product Team</span><o:p></o:p></pre>
<pre><span style="color:#000066">Tucows</span><o:p></o:p></pre>
<pre><span style="color:#000066">+1.416 535 0123 Ext. 1392</span><o:p></o:p></pre>
<pre><span style="color:#000066"> </span><o:p></o:p></pre>
<pre><span style="color:#000066"> </span><o:p></o:p></pre>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>