<div dir="ltr"><div>This is presently one of my two biggest concerns. In particular, how is a client issuing a query right now supposed to know which attributes are public right now and which are not, given that such a list could change as a matter of policy in between software updates?<br><br></div><div>The other is whether ICANN has, or intends to deploy, the physical and human infrastructure needed to support that sort of query volume.</div><div><br></div><div>-MSK<br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 17, 2018 at 10:23 AM Hollenbeck, Scott <<a href="mailto:shollenbeck@verisign.com">shollenbeck@verisign.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="auto">
<div dir="ltr"></div>
<div dir="ltr">It would be a whole lot less confusing for clients if ICANN were the access point for all queries. As I noted in an earlier message, any form of “split” service required the client to know which data elements are public and which aren’t. There’s
also nothing in the bootstrap service to distinguish the services based on the data elements they serve.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Scott</div>
<div dir="ltr"><br>
On Dec 17, 2018, at 1:13 PM, Francisco Arias <<a href="mailto:francisco.arias@icann.org" target="_blank">francisco.arias@icann.org</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail-m_-4307765087941377827WordSection1">
<p class="MsoNormal"><span style="font-size:12pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:12pt"><u></u> <u></u></span></p>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black">-- <u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black">Francisco</span><span style="font-size:12pt"><u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:12pt"><u></u> <u></u></span></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:0.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" target="_blank">tsg-access-rd-bounces@icann.org</a> on behalf of
<a href="mailto:superuser@gmail.com" target="_blank">superuser@gmail.com</a>> wrote:<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:0.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.<u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-left:0.5in"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:0.5in">On Fri, Dec 14, 2018 at 2:45 PM Gavin Brown <<a href="mailto:gavin.brown@centralnic.com" target="_blank">gavin.brown@centralnic.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-right:0in;margin-bottom:12pt;margin-left:0.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>
<u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div dir="ltr"><span></span><br>
</div>
</blockquote>
</div>
</blockquote></div>