[TSG-Access-RD] [Ext] Re: ICANN as a proxy

[Hollenbeck, Scott]

Francisco, please explain why ICANN can’t just receive and proxy all queries if you’re already planning to receive all queries for whatever “non-public” data turns out to be. It really would make things easier for both clients and the operators who will be the data sources if we each know that we only have to deal with ICANN.

Scott

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

Client’s do not know what fields are public and which aren’t; that is how RDAP works right know. But you can use the truncated responses to signal the client to re-try with proper credentials. The new thing with a schema in which ICANN is the sole authorizer and proxy for non-public data, is that the query to obtain the non-public data would have to be sent somewhere different to where the public data came from.

--
Francisco

On 12/17/18, 3:45 PM, "Murray S. Kucherawy" <superuser at gmail.com<mailto:superuser at gmail.com>> wrote:

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?
The other is whether ICANN has, or intends to deploy, the physical and human infrastructure needed to support that sort of query volume.

-MSK

On Mon, Dec 17, 2018 at 10:23 AM Hollenbeck, Scott <shollenbeck at verisign.com<mailto:shollenbeck at verisign.com>> wrote:
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/20181218/975120de/attachment-0001.html>