[TSG-Access-RD] ICANN as a proxy

[Hollenbeck, Scott]

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.

Scott

On Dec 17, 2018, at 1:13 PM, Francisco Arias <francisco.arias at icann.org<mailto:francisco.arias at icann.org>> wrote:

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.

--
Francisco

On 12/14/18, 3:29 PM, "TSG-Access-RD on behalf of Murray S. Kucherawy" <tsg-access-rd-bounces at icann.org<mailto:tsg-access-rd-bounces at icann.org> on behalf of superuser at gmail.com<mailto:superuser at gmail.com>> wrote:

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.

On Fri, Dec 14, 2018 at 2:45 PM Gavin Brown <gavin.brown at centralnic.com<mailto:gavin.brown at centralnic.com>> wrote:
If ICANN org is willing to put itself in the critical path for handling
these requests then the problem we're trying to resolve becomes very
simple indeed! But I would guess that is not the case and perhaps the
charter text as revised needs to be amended.

G.

On 14/12/2018 19:39, Tomofumi Okubo wrote:
> Hey Andy!
>
>>    The second sentence implies that ICANN servers would act as a proxy,
>>   transiting both queries and responses. Is there a legal necessity for
>>    the information to flow through ICANN?
>
> I believe the benefit of this is twofold.
>
> One is that ICANN is forced to be part of the transaction.
> It is hard(er) for ICANN to be blamed for when they are not touching anything in the RDAP ecosystem.
> In other words, it's hard to be a primary suspect if you are not even at the crime scene.
>
> 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.
> It allows the contracted parties just innocently responded to ICANN without knowing the nature of the query.
>
> For ICANN to be a legal shield for the contracted parties, this kind of make sense to me.
>
> That being said, the technical feasibility of this model needs to be assessed in this study group.
>
> Just my 2 cents because I'm not a lawyer __
>
> Cheers!
> Tomofumi
>
>
> On 12/14/18, 10:18 AM, "TSG-Access-RD on behalf of Andrew Newton" <tsg-access-rd-bounces at icann.org<mailto:tsg-access-rd-bounces at icann.org> on behalf of andy at hxr.us<mailto:andy at hxr.us>> wrote:
>
>     During our last call, Scott and Murray discussed third-party or
>     distributed authorization, but I'd like to ask about on another aspect
>     of the operational model that appears in the charter. The current
>     charter text says:
>
>     "The implementation approach described during that webinar would place
>     ICANN in the position of determining whether a third party’s query for
>     non-public registration data ought to be approved to proceed. If
>     approved, ICANN would ask the appropriate registry or registrar to
>     provide the requested data to ICANN, which in turn would provide it to
>     the third party. If ICANN does not approve the request, the query
>     would be denied."
>
>     The second sentence implies that ICANN servers would act as a proxy,
>     transiting both queries and responses. Is there a legal necessity for
>     the information to flow through ICANN?
>
>     -andy
>
>
>
>
>

--
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tsg-access-rd/attachments/20181217/a120d58c/attachment-0001.html>