Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt

[Marc Blanchet <[e-mail]>]

Le 2013-06-20 à 15:34, "John R Levine" <[e-mail]> a écrit :

>>> The IPv6 and ASN spaces are both so large that IANA will never allocate more than a small fraction of either.  Do you really want clients hammering on IANA every time someone or something accidentally tries to look up something in the unallocated range?
>> 
>> You are continually taking the point that that is hitting the IANA web servers hard. Caching infrastructure are all available today for much larger issues than we are discussing and as I wrote before, IANA is already using caching infrastructure. So it is not as a big issue that you are arguing.  Obviously, it has to be planned with IANA, but this is not a first.
> 
> I think you're missing two key points here.
> 
> One is that this wouldn't just happen each time there's a change to the table (roughly never), it'd happen each time someone tries to check an address or ASN that's not in the table, which I expect will happen all the time.  Unless you expect IANA to add table entries saying "This isn't allocated and won't be anytims soon", which would be a giant can of worms, there's no reverse caching to keep clients from hitting it on each query of an unallocated address or ASN, and there are a lot of unallocated addresses.

an XML file is just a small file on the Internet. Cached, there is a copy everywhere. It is one http request to get the file. As simple and resource consuming as fetching an html file = 0. If the file is in the "Internet caching infrastructure" (using that term to avoid naming specific caching providers), then it could handle zillions of queries.  

What I'm saying is that we want to tell the developers to be "clever" to minimize these requests, given that the likelihood that the data change is low. In the worst case, if they fetch every time, then no big deal if the file is in the cache infrastructure. and they have an incentive to be clever because fetching every time will take some time for them to get the data, to rely on the data, to parse the data. But again, worst case, they fetch every time. their problem.

Marc.

> 
>>> Also, the point of the "baked in" was that the RDAP client need not include the ability to update the table.
> 
> The Lazy Programmer in me is sure that even if we told people that every RDAP client has to include something to fire off a daemon and do a table update on demand, it's not going to happen.  So please let's not tell them to.
> 
>>> So in 2119-ese,
>>> 
>>> RDAP clients SHOULD use a hints table to select an initial numbers server, with some way to update the table, which might be as crude as installing a new version of the RDAP client,
>>> 
>>> clients MAY use pool.numbers.rdap.arpa as an initial server if there is no hints table available, or the target isn't in the table (they will whether or not we say they can, so we might as well provide a well known name for it), and
>>> 
>>> clients MUST use <tld>.domain.rdap.arpa as an initial server for TLD.
>>> 
>>> In each case, the protocol is https.  Anyone who plans to run an RDAP server and won't be able to provide https should speak up now.
> 
> Regards,
> John Levine, [e-mail], Taughannock Networks, Trumansburg NY
> "I dropped the toothpaste", said Tom, crestfallenly.