<div dir="ltr">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.<br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 14, 2018 at 2:45 PM Gavin Brown <<a href="mailto:gavin.brown@centralnic.com">gavin.brown@centralnic.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">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/" rel="noreferrer" 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>
<br>
</blockquote></div>