<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size: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;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;}
.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;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:12.0pt">To be clear, the requirement given to us is that ICANN would be the only authorizing body for each request for non-public data. Requests for public data should not be changed (i.e., the client, following the
bootstrapping algorithm queries the authoritative server for the data). So, not all the RDAP queries.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">-- <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">Francisco</span><span style="font-size:12.0pt"><o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">On 12/14/18, 3:29 PM, "TSG-Access-RD on behalf of Murray S. Kucherawy" <<a href="mailto:tsg-access-rd-bounces@icann.org">tsg-access-rd-bounces@icann.org</a> on behalf of
<a href="mailto:superuser@gmail.com">superuser@gmail.com</a>> wrote:<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">I would like to understand what they have in mind in terms of investment in infrastructure if the intend to insert themselves as brokers for all RDAP queries.<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">On Fri, Dec 14, 2018 at 2:45 PM Gavin Brown <<a href="mailto:gavin.brown@centralnic.com">gavin.brown@centralnic.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
If ICANN org is willing to put itself in the critical path for handling<br>
these requests then the problem we're trying to resolve becomes very<br>
simple indeed! But I would guess that is not the case and perhaps the<br>
charter text as revised needs to be amended.<br>
<br>
G.<br>
<br>
On 14/12/2018 19:39, Tomofumi Okubo wrote:<br>
> Hey Andy!<br>
> <br>
>> The second sentence implies that ICANN servers would act as a proxy,<br>
>> transiting both queries and responses. Is there a legal necessity for<br>
>> the information to flow through ICANN?<br>
> <br>
> I believe the benefit of this is twofold.<br>
> <br>
> One is that ICANN is forced to be part of the transaction.<br>
> It is hard(er) for ICANN to be blamed for when they are not touching anything in the RDAP ecosystem.<br>
> In other words, it's hard to be a primary suspect if you are not even at the crime scene.<br>
> <br>
> Another is that the contracted party that receive the query interacts only with ICANN which makes it easier for the contracted parties to claim innocence.<br>
> It allows the contracted parties just innocently responded to ICANN without knowing the nature of the query.<br>
> <br>
> For ICANN to be a legal shield for the contracted parties, this kind of make sense to me.<br>
> <br>
> That being said, the technical feasibility of this model needs to be assessed in this study group.<br>
> <br>
> Just my 2 cents because I'm not a lawyer __<br>
> <br>
> Cheers!<br>
> Tomofumi<br>
> <br>
> <br>
> On 12/14/18, 10:18 AM, "TSG-Access-RD on behalf of Andrew Newton" <<a href="mailto:tsg-access-rd-bounces@icann.org" target="_blank">tsg-access-rd-bounces@icann.org</a> on behalf of
<a href="mailto:andy@hxr.us" target="_blank">andy@hxr.us</a>> wrote:<br>
> <br>
> During our last call, Scott and Murray discussed third-party or<br>
> distributed authorization, but I'd like to ask about on another aspect<br>
> of the operational model that appears in the charter. The current<br>
> charter text says:<br>
> <br>
> "The implementation approach described during that webinar would place<br>
> ICANN in the position of determining whether a third party’s query for<br>
> non-public registration data ought to be approved to proceed. If<br>
> approved, ICANN would ask the appropriate registry or registrar to<br>
> provide the requested data to ICANN, which in turn would provide it to<br>
> the third party. If ICANN does not approve the request, the query<br>
> would be denied."<br>
> <br>
> The second sentence implies that ICANN servers would act as a proxy,<br>
> transiting both queries and responses. Is there a legal necessity for<br>
> the information to flow through ICANN?<br>
> <br>
> -andy<br>
> <br>
> <br>
> <br>
> <br>
> <br>
<br>
-- <br>
Gavin Brown<br>
Chief Technology Officer<br>
CentralNic Group plc (LSE:CNIC)<br>
Innovative, Reliable and Flexible Registry Services<br>
for ccTLD, gTLD and private domain name registries<br>
<a href="https://www.centralnic.com/" target="_blank">https://www.centralnic.com/</a><br>
+44.7548243029<br>
<br>
CentralNic Group plc is a company registered in England and Wales with<br>
company number 8576358. Registered Offices: 35-39 Moorgate, London,<br>
EC2R 6AR.<br>
<br>
<o:p></o:p></p>
</blockquote>
</div>
</div>
</body>
</html>