<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: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:Verdana;
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;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Helvetica Neue Light";}
@font-face
{font-family:"Helvetica Neue";}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
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";
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;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:#000066;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
margin:0in;
margin-bottom:.0001pt;
font-size:11.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;}
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;
color:black;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Helvetica Neue",serif;
color:windowtext;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle25
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle27
{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:1372536916;
mso-list-template-ids:372659024;}
@list l0:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:1566914437;
mso-list-template-ids:1991142216;}
@list l1:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2
{mso-list-id:1593203944;
mso-list-template-ids:-706083936;}
@list l2: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 l2: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 l2: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 l2: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 l2: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 l2: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 l2: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 l2: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 l2: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;}
@list l3
{mso-list-id:1667050013;
mso-list-template-ids:-1611486382;}
@list l4
{mso-list-id:1692802217;
mso-list-template-ids:1278769156;}
@list l5
{mso-list-id:1757165640;
mso-list-type:hybrid;
mso-list-template-ids:-689907670 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l5: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 l5: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";}
@list l5: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 l5: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 l5: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";}
@list l5: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 l5: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 l5: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";}
@list l5: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><!--[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="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:windowtext">It was my understanding that under a JCA, ICANN would not be a third party with no need to process – as a joint controller, they would be reasonably expected to process.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext">Regarding ICANN’s position to make a valid balancing test, I think it’s good to recognize that many registrations are conducted by resellers. Volker has previously made a point that understanding the geographic
or personhood status in such cases would be “an administrative nightmare”. I don’t see why we’d expect a registrar in such cases to have any additional insight over ICANN in making a valid balancing test – either would be sufficient.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="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="color:windowtext">From:</span></b><span style="color:windowtext"> Gnso-epdp-team <gnso-epdp-team-bounces@icann.org>
<b>On Behalf Of </b>Volker Greimann<br>
<b>Sent:</b> Monday, September 23, 2019 1:49 AM<br>
<b>To:</b> 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>
<p>Hi<o:p></o:p></p>
<p>I also agree that a central repository is not desirable and may even be problematic under the GDPR. Even shuttling the disclosrue through ICANN can be seen as problematic as it exposes a third party to the data that has no real need of processing it.
<o:p></o:p></p>
<p>I could imagine a central portal working in a way that it accepts and redirects requests to the entities holding the data, who then make the balancing test and if disclosure is granted, make that disclosure directly to the requestor. In either case, the
central portal could be informed of the decision.<o:p></o:p></p>
<p>ICANN as the decider is neither beneficial, data protection compliance not desirable. ICANN will not be in a position to make a valid balancing test.<o:p></o:p></p>
<p>Best,<o:p></o:p></p>
<p>Volker<o:p></o:p></p>
<div>
<p class="MsoNormal">Am 20.09.2019 um 21:38 schrieb Greg Aaron:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Hi, Ashley – see my post of 1:34 pm (pasted below). No, ICANN does not have to establish a replica database. What you and James just described are the same as my Model #1, where the data sits at the registrars/registries but ICANN operates
a central point that shuttles the data back and forth. (And ICANN can be the decider, or the registry/registrar can be the decider.) I think the three of us are on the same page here.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">IMHO the replica database idea probably has the most drawbacks. It may be the most complicated and therefore expensive, the hardest operationally for ICANN and the contracted parties to maintain, and I suspect that it presents the most
security problems. It would be helpful for the WG to have analysis of each option’s positives and negatives.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Regardless, we do need an answer to the most vital question -- will ICANN be the decider or not?
<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">There are two parts to the answer. First is whether the idea of “ICANN the decider” works under GDPR and if the EU data authorities will accept ICANN being in the position. And if “ICANN the decider” is possible, then whether ICANN Org
will accept the role. Those two things can be pondered concurrently, but we really need an answer to the first part.
<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Regarding whether ICANN will accept the role: I would think that would be a Board-level discussion, since it is a major risk/liability consideration and because solving the access problem is very important for ICANN’s credibility. Last
week I think Chris Disspain said that the Board had not considered the issue. <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">All best,<o:p></o:p></p>
<p class="MsoNormal">--Greg<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<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> James M. Bladel <a href="mailto:jbladel@godaddy.com">
<jbladel@godaddy.com></a> <br>
<b>Sent:</b> Friday, September 20, 2019 2:24 PM<br>
<b>To:</b> Heineman, Ashley <a href="mailto:AHeineman@ntia.gov"><AHeineman@ntia.gov></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><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",serif">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",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue",serif">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",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue",serif">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",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue",serif">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",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue",serif">J.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue",serif"> </span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-family:"Helvetica Neue Light",serif">-------------</span><o:p></o:p></p>
<p class="MsoNormal"><b>James Bladel</b><o:p></o:p></p>
<p class="MsoNormal"><span style="font-family:"Helvetica Neue Light",serif">GoDaddy</span><o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue",serif"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Helvetica Neue",serif"> </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">From: </span></b><span style="font-size:12.0pt">"Heineman, Ashley" <</span><a href="mailto:AHeineman@ntia.gov"><span style="font-size:12.0pt">AHeineman@ntia.gov</span></a><span style="font-size:12.0pt">><br>
<b>Date: </b>Friday, September 20, 2019 at 13:10<br>
<b>To: </b>"James M. Bladel" <</span><a href="mailto:jbladel@godaddy.com"><span style="font-size:12.0pt">jbladel@godaddy.com</span></a><span style="font-size:12.0pt">>, Greg Aaron <</span><a href="mailto:greg@illumintel.com"><span style="font-size:12.0pt">greg@illumintel.com</span></a><span style="font-size:12.0pt">>,
'Sarah Wyld' <</span><a href="mailto:swyld@tucows.com"><span style="font-size:12.0pt">swyld@tucows.com</span></a><span style="font-size:12.0pt">>, "</span><a href="mailto:gnso-epdp-team@icann.org"><span style="font-size:12.0pt">gnso-epdp-team@icann.org</span></a><span style="font-size:12.0pt">"
<</span><a href="mailto:gnso-epdp-team@icann.org"><span style="font-size:12.0pt">gnso-epdp-team@icann.org</span></a><span style="font-size:12.0pt">><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">Notice:</span>
<span style="font-size:9.0pt;font-family:"Tahoma",sans-serif">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">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"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">Thanks!</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">Ashley (GAC)</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><b>From:</b> Greg Aaron <a href="mailto:greg@illumintel.com">
<greg@illumintel.com></a> <br>
<b>Sent:</b> Friday, September 20, 2019 1:34 PM<br>
<b>To:</b> 'James M. Bladel' <a href="mailto:jbladel@godaddy.com"><jbladel@godaddy.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<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Thanks much, James. My observation is about the models we discussed in L.A. (What kinds of hamburgers are on the menu?) We should be precise about what we mean by “distributed”. I see three models:<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="color:windowtext;margin-left:0in;mso-list:l5 level1 lfo3">
Model #1: Queries come from requestors into a central point (run somehow by ICANN), that central point distributes the queries to the relevant registrars/registries, then the central point routes the replies back to the requestors. The central point also passes
out authentication credentials to the parties making queries. This is the technical model the TSG wrote about. This has a DISTRIBUTED data model – the data resides at the registries/registrars. It has CENTRALIZED query input/output and access/authentication
functions.<o:p></o:p></li><li class="MsoListParagraph" style="color:windowtext;margin-left:0in;mso-list:l5 level1 lfo3">
Model #2: A central point passes out authentication credentials, and requestors and registries/registrars then use those to trade queries with each other directly. This is a DISTRIBUTED model in two ways: the data is distributed because it resides at the registries/registrars,
and query-making and response takes place among distributed parties. It is CENTRALIZED in one way: access/authentication functions.<o:p></o:p></li><li class="MsoListParagraph" style="color:windowtext;margin-left:0in;mso-list:l5 level1 lfo3">
Model #3: ICANN holds a registry containing all RDS data, obtained from the registries/registrars, and all queries go to and immediately served back from there. The central point also controls access (authentication creds). This is all CENTRALIZED. I will
call this the Lord of the Rings Model: “One registry to rule them all / One registry to find them / One registry to bring them all / And at ICANN bind them.”<o:p></o:p></li></ul>
<p class="MsoListParagraph"><span style="color:windowtext"> </span><o:p></o:p></p>
<p class="MsoNormal">In Model #1, ICANN can be the party making the disclosure decisions. In that case, the registry/registrar would be acting pretty much as a data processor – if ICANN sends it a query, the registry/registrar simply supplies the data. Or,
the registrar/registry can be the decision-maker in model #1.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Model #2 only allows the registry/registrar to be the decision-maker.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Model #3 exists only for ICANN to be the decision-maker.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">So, ICANN can be “the decider” without a centralized registry. The most crucial question is whether ICANN can or will act as the decider. If ICANN’s the decider, then we have a choice between Model #1 or Model #3. If ICANN will not be
the decider, then we have a choice of Model #1 or Model #2.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Sarah posited ICANN as the decider, and then said the registry/registrar would be making 6(1)f decisions. I didn’t understand that, because there can only be one decider.
<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">So, we need to know who the decider will be. And the WG should enumerate the plusses and minuses of each of the models.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">All best,<o:p></o:p></p>
<p class="MsoNormal">--Greg<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt"> </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>From:</b> 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 <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">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<a href="mailto:gnso-epdp-team-bounces@icann.org"><gnso-epdp-team-bounces@icann.org></a><b>On Behalf Of
</b>Sarah Wyld<br>
<b>Sent:</b> Wednesday, September 18, 2019 3:18 PM<br>
<b>To:</b> <a href="mailto:gnso-epdp-team@icann.org">gnso-epdp-team@icann.org</a><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:l0 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:l0 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:l1 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:l1 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:l1 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>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7Cd27c174edcbf4e8df8a908d74002d8e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637048253301325822&sdata=TLa5hkG%2Fd5o2vTz4QROkCJ0xTfe3ZxurooC5gqb1gOE%3D&reserved=0">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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7Cd27c174edcbf4e8df8a908d74002d8e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637048253301325822&sdata=dvesgyNYUtJCaZGjMiROIloi88jq9wFDpqtiqVHVYlo%3D&reserved=0">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7Cd27c174edcbf4e8df8a908d74002d8e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637048253301325822&sdata=gWvFZRnbp6Twjx4rdK%2BkeyWk%2BcZqC8wHuXN%2FGzQxNRM%3D&reserved=0">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">-- <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="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.key-systems.net&data=02%7C01%7Cmarksv%40microsoft.com%7Cd27c174edcbf4e8df8a908d74002d8e2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637048253301335778&sdata=g4BtsFQWHu33FTLtTtY3Ge0EpcX4cc7C6LS10vRGkIs%3D&reserved=0">
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></p>
</div>
</div>
</body>
</html>