[TSG-Access-RD] ICANN as a proxy

[Murray S. Kucherawy]

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>
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>
> 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 on behalf of 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>
> 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 on behalf of 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/97474b32/attachment-0001.html>