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

From: Marc Blanchet <[email-masked]>
Date: Wed, 5 Jun 2013 16:54:08 -0400

Hello,
 this is a draft on bootstrapping, but instead of using DNS as the other draft I sent, this one uses IANA XML registries, as discussed. That way we have two proposal on the table we can compare.  At one time, one of these two drafts will be dropped... ;-)

Please comment.

Regards, Marc.

Début du message réexpédié :

> De : [email-masked]
> Objet : I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt
> Date : 5 juin 2013 16:49:40 HAE
> À : [email-masked]
> Répondre à : [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title           : Finding the Authoritative Registration Data (RDAP) Service
> 	Author(s)       : Marc Blanchet
> 	Filename        : draft-blanchet-weirds-bootstrap-ianaregistries-00.txt
> 	Pages           : 6
> 	Date            : 2013-06-05
> 
> Abstract:
>   This document specifies a method to find which Registration Data
>   Access Protocol (RDAP) server is authoritative to answer queries for
>   a requested scope, such as domain names, IP addresses or Autonomous
>   System numbers, using data available in IANA registries.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-blanchet-weirds-bootstrap-ianaregistries
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-ianaregistries-00
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Linlin Zhou" <[email-masked]>
Date: Thu, 6 Jun 2013 14:50:22 +0800

Dear Marc,

It is said that domain, IP or AS “is found by doing the longest match” with
the corresponding IANA registry information in this draft. I feel the text
here is not very accurate.

For domain, you can match the last label of a domain with the domain column
of the IANA xml file.

As for IP or AS, check an single IP or AS number, or a CIDR IP address
whether it belongs to a range of the IP or AS, then find the rdap server
address.

Regards,

Linlin

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Marc Blanchet
Sent: Thursday, June 06, 2013 4:54 AM
To: [email-masked]
Subject: [weirds] Fwd: I-D Action:
draft-blanchet-weirds-bootstrap-ianaregistries-00.txt

Hello,

 this is a draft on bootstrapping, but instead of using DNS as the other
draft I sent, this one uses IANA XML registries, as discussed. That way we
have two proposal on the table we can compare.  At one time, one of these
two drafts will be dropped... ;-)

Please comment.

Regards, Marc.

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

     Title           : Finding the Authoritative Registration Data (RDAP)
Service
     Author(s)       : Marc Blanchet
     Filename        : draft-blanchet-weirds-bootstrap-ianaregistries-00.txt
     Pages           : 6
     Date            : 2013-06-05

Abstract:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-blanchet-weirds-bootstrap-ianaregistr
ies

---

From: "John Levine" <[email-masked]>
Date: 6 Jun 2013 10:05:17 -0000

> this is a draft on bootstrapping, but instead of using DNS as the other draft I sent, this one
>uses IANA XML registries, as discussed. That way we have two proposal on the table we can
>compare.  At one time, one of these two drafts will be dropped... ;-)
>
>Please comment.

So now I'd need an XML parser to do the bootstrap, a JSON parser to
handle query results, and a new cache separate from my DNS cache and
(if I'm using a browser) the browser cache to handle the bootstrap
data?  And that means that a URL at IANA is now in the critical path
for all lookups?

Speaking as a lazy linux user writing scripts with wget, cacheing the
file is a pain, so I'll just fetch it each time I do a lookup.  I'm
paying 25 cents/domain to ICANN so I'm their customer and they better
put up with it.  Even though I'm looking up ccTLD and RIR data.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 6 Jun 2013 10:15:53 -0000

For IP numbers and ASNs, what about just querying your closest RIR,
and it redirects to another RIR or LIR if appropriate.

There's only five RIRs, they all are friends with each other, and they
all need to have cross links anyway for legacy space that's been moved
from one RIR to another anyway.

---

From: Andy Newton <[email-masked]>
Date: Thu, 6 Jun 2013 10:27:57 +0000

On 6/6/13 6:05 AM, "John Levine" <[email-masked]> wrote:

>handle query results,...

It might be worth asking the IANA if they can also produce their
registries in JSON format. Least they can say is "no".

>
>Speaking as a lazy linux user writing scripts...

I hear ya. Hopefully they'll use 'nicinfo -Q --json example.com | jsawk
ldhName' or 'nicinfo -Q --value ldhName', which will do all the
bootstrapping and caching for them. (adding a feature to only produce
entities by role type seems like a good idea for this program now that I
think about it)

Or they'll just wget to their RDAP server of choice, which will go through
the trouble of updating its bootstrapping map. But no matter what
mechanism for bootstrapping we pick, I doubt they'll go through the
trouble of using it at all. They'll just pick the nearest RDAP server and
hope for a redirect.

-andy

---

From: Andy Newton <[email-masked]>
Date: Thu, 6 Jun 2013 10:30:44 +0000

>from one RIR to another anyway.

This always a possibility and something a client should be prepared to do
even if they start with the most appropriate RIR using the IANA
bootstrapping. But there is nothing wrong with trying to find the most
appropriate server first even if it means following a redirect.

-andy

---

From: "John R Levine" <[email-masked]>
Date: 6 Jun 2013 14:23:06 +0200

> trouble of using it at all. They'll just pick the nearest RDAP server and

For IPs and ASNs, I expect you're right.

For domains, the various registries are not friends and often have no idea 
who each other are, so we really do need some sort of external bootstrap. 
On the other hand, I think that it'd be adequate to have a bootstrap point 
per TLD, so these should work to find out about example.com and 
example.on.ca:

 	http://com.domain.rdap.arpa/domain/example.com
 	http://ca.domain.rdap.arpa/domain/example.on.ca

The name com.domain.rdap.arpa resolves to a CNAME, A, or AAAA that points 
at the server.  The server might redirect to something like 
rdap.verisign-grs.com, or it might just be rdap.verisign-grs.com.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 6 Jun 2013 08:55:44 -0400

Le 2013-06-06 à 02:50, "Linlin Zhou" <[email-masked]> a écrit :

> Dear Marc,
>  
> It is said that domain, IP or AS “is found by doing the longest match” with the corresponding IANA registry information in this draft. I feel the text here is not very accurate.

I agree that it is underspecified....

> For domain, you can match the last label of a domain with the domain column of the IANA xml file.

I wanted to be generic enough, so the algorithm can apply to multiple levels, if the XML file has such. For example, the file may have two entries:

com
example.com

and the query is for a.example.com, it should do the longest match and take the second entry.

That is what I was trying to convey with the longest match. However, it is clearly underspecified. I should have had something around "longest match, per label'. Some text to work out.

> As for IP or AS, check an single IP or AS number, or a CIDR IP address whether it belongs to a range of the IP or AS, then find the rdap server address.

similarly, one may have:

2001::/16
2001:1000::/32

and the query is for 2001:1000:1:1::1. it should do the longest match and take the second entry.

This is what I intended for longest match.  

I'll add more text in the next rev.

Thanks for the comments and review.

Regards, Marc.

>  
> Regards,
> Linlin
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Blanchet
> Subject: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt
>  
> Hello,

---

From: Andy Newton <[email-masked]>
Date: Thu, 6 Jun 2013 13:57:14 +0000

>rdap.verisign-grs.com, or it might just be rdap.verisign-grs.com.

So for .uk and .co.uk, do you envision using DNS wildcards? I just don't
like the idea of query for xx.yy and if you get NXDOMAIN, query for yy.

-andy

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 6 Jun 2013 10:19:49 -0400

a) these comments below are more around the first draft using DNS.

> like the idea of query for xx.yy and if you get NXDOMAIN, query for yy.

the draft says that wildcards may be used. I don't think we can say "MUST" use wildcards. So that is why I put the NXDOMAIN discussion in the draft.
However, I do see most operators use wildcards "all the time". Therefore, I expect the client not to process NXDOMAIN so often, but should be prepared to. So this is how the draft was written, at least the intent...

Marc.

> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: Andy Newton <[email-masked]>
Date: Thu, 6 Jun 2013 14:39:37 +0000

On 6/6/13 10:19 AM, "Marc Blanchet" <[email-masked]> wrote:

>However, I do see most operators use wildcards "all the time". Therefore,
>I expect the client not to process NXDOMAIN so often, but should be
>prepared to. So this is how the draft was written, at least the intent...

Even if they don't have to process them so often, if it is in the spec
then we expect implementers to have to write code to process NXDOMAINs and
this complexity is still there. I'd rather this come out of the spec and
we put the onus of multi-level domains on the server side. This is in
spirit with the rest of the RDAP framework.

-andy

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 6 Jun 2013 10:52:50 -0400

Le 2013-06-06 à 10:39, Andy Newton <[email-masked]> a écrit :

> this complexity is still there.

yes.

> I'd rather this come out of the spec and
> we put the onus of multi-level domains on the server side.

fair. I was not willing to impose wildcards in the first rev of the draft. Will see what other people think and if the DNS solution is the one chosen.

Marc.

> This is in

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Thu, 06 Jun 2013 15:54:30 -0300

<Like>

Question / comment :

- do we actually need to solve bootstrapping for entity, nameserver ? Is
a 'lightweight' bootstrap only with domain, autnum, ip4 and ip6
acceptable ?

cheers!

~Carlos

On 6/5/13 5:54 PM, Marc Blanchet wrote:
> draft I sent, this one uses IANA XML registries, as discussed. That way
> we have two proposal on the table we can compare.  At one time, one of
> these two drafts will be dropped... ;-)
> 
> Please comment.
> 
> Regards, Marc.
> 
>> *De : [email-masked] <mailto:[email-masked]>
>> *Objet : **I-D Action:
>> draft-blanchet-weirds-bootstrap-ianaregistries-00.txt*
>> *Date : *5 juin 2013 16:49:40 HAE
>> *À : [email-masked] <mailto:[email-masked]>
>> *Répondre à : [email-masked] <mailto:[email-masked]>
>>
>>

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 6 Jun 2013 15:13:34 -0400

> a 'lightweight' bootstrap only with domain, autnum, ip4 and ip6

- don't have an answer, since I haven't thought through yet. That is why I put "TBD" in the draft(s)...

Marc.

---

From: "Linlin Zhou" <[email-masked]>
Date: Fri, 7 Jun 2013 11:09:29 +0800

> -----Original Message-----
> From: John Levine [mailto:[email-masked]]
> Sent: Thursday, June 06, 2013 6:16 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [weirds] draft-blanchet-weirds-bootstrap-ianaregistries-00.txt
> 
> For IP numbers and ASNs, what about just querying your closest RIR, and it
> redirects to another RIR or LIR if appropriate.
> 

I agree that this is also a feasible approach. There are only 5 RIRs after all. But I am not very clear about how to find the closest RIR. Can the service discovery tech work?

> There's only five RIRs, they all are friends with each other, and they all need to
> have cross links anyway for legacy space that's been moved from one RIR to
> another anyway.

---

From: "John R Levine" <[email-masked]>
Date: 7 Jun 2013 11:43:28 +0200

> I agree that this is also a feasible approach. There are only 5 RIRs after all. But I am not very clear about how to find the closest RIR. Can the service discovery tech work?

Since the closest RIR to a given host almost never changes, it could be a 
one-time configuration setting when the software is installed.  Or you 
could do a kludge like taking the IPv4 address of the local host, and 
using a static 240 entry table to guess the RIR from the first octet of 
the address.

Whatever you do, the penalty for guessing wrong is quite low.  The worst 
that will happen is that queries will go over the net to an RIR farther 
away.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 18 Jun 2013 14:00:05 -0400

my current reading of the discussion about bootstrapping is the following:
- for names, do dns rdap.arpa, wildcards 
- for addresses, use IANA registry.

Which is essentially a merge of the two drafts I wrote into a combined one.

Looking to see agreement on the way forward and I'll update the draft shortly.

Marc.

---

From: Andy Newton <[email-masked]>
Date: Tue, 18 Jun 2013 18:22:47 +0000

From: Marc Blanchet <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, June 18, 2013 2:00 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [weirds] I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-00.txt

I don't like the hybrid approach given that the IANA registries approach works for both names and numbers.

The issue for rdap.arpa for numbers are the ASNs. With a little creativity, we might get that to work too. Perhaps zero padding and reversing the numbers with a different label for each digit might allow enough wiggle room for the creating a zone file. So 199679 would become 9.7.6.9.9.1.0.0.0.0.as.rdap.arpa. Just a thought.

The downside to rdap.arpa is that we are forcing all registry operators to support HTTPS. With an IANA registries model, each operator could register their HTTP and/or HTTPS URLs.

-andy

---

From: "John Levine" <[email-masked]>
Date: 18 Jun 2013 21:54:59 -0000

>- for names, do dns rdap.arpa, wildcards 

Either wildcards, or just TLDs.

>- for addresses, use IANA registry.

The suggestions I've seen are to use the RIR servers as a pool of
initial RDAP servers, since they already know about each other's
allocations.

The IANA registry might work, but I would want to be sure they were
willing to have a potentially vast number of clients frequently
fetching these pages:
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xml

It appears that www.iana.org is just one web server, or perhaps a
small set of them behind a load balancer, which doesn't strike me as
appropriate for a critical resource.

R's,
John

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Wed, 19 Jun 2013 00:13:50 -0300

Maybe my pool suggestion was a little misunderstood. My original
suggestion about the pools made no assumptions on the bootstrap method
for the servers.

I was rather trying to address one of the underlying hypothesis about
how RDAP will be used in the wild, namely by lots of rather simplistic
clients, which unless convinced otherwise will always hit the same
server (like they hit ARIN now).

As this hypothesis goes, the RDAP client universe will be populated by
clients which will have no incentive at all to bootstrap but will just
get the first server in fixed list with a hammer.

Warm regards,

~Carlos

---

From: Simon Perreault <[email-masked]>
Date: Wed, 19 Jun 2013 10:29:16 +0200

Le 2013-06-18 20:22, Andy Newton a écrit :
> The issue for rdap.arpa for numbers are the ASNs. With a little
> creativity, we might get that to work too. Perhaps zero padding and
> reversing the numbers with a different label for each digit might allow
> enough wiggle room for the creating a zone file. So 199679 would become
> 9.7.6.9.9.1.0.0.0.0.as.rdap.arpa. Just a thought.

Maybe use hex?

> The downside to rdap.arpa is that we are forcing all registry operators
> to support HTTPS.

Maybe clients could try HTTPS first and fallback on HTTP?

Simon

---

From: Pieter Vandepitte <[email-masked]>
Date: Wed, 19 Jun 2013 10:55:23 +0200

> Maybe clients could try HTTPS first and fallback on HTTP?

Seems a bad idea to me. It's sufficient for a mitm to block https and
then grab credentials

Pieter

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 19 Jun 2013 09:47:22 -0400

about addresses:
- having all RIR to redirect to each other is to me an operational decision that implies they have a formal agreement between themselves about this service. I'm not sure we can write this down in an RFC.  Even if we do, what happens if one of the RIR disagree next month and stop redirecting?
- so my take is the following:
 a) we need to define a reliable bootstrap method, reliable in the sense that it implies the least amount of agreement between parties.
 b) we specify optional optimisations, such as connecting to one server and hopefully it will redirect to the right one. If the optimisation does not work anymore, the client can fallback to the "reliable" method.

For a), I think it is either the IANA registries or a DNS-based approach, each have been specified in a separate draft I published.

Regarding IANA registries, they have a farm of servers and caching infrastructure. They have already been doing some larger scale caching for some registries that have been hit by large numbers, so they can do. In any of the choices we have, IANA will be involved, so as soon as we have concensus, I'll contact them to discuss the plan and pre-empt any issue.

Marc.

---

From: "John R Levine" <[email-masked]>
Date: 19 Jun 2013 11:47:27 -0400

> - having all RIR to redirect to each other is to me an operational 
> decision that implies they have a formal agreement between themselves 
> about this service. I'm not sure we can write this down in an RFC. 
> Even if we do, what happens if one of the RIR disagree next month and 
> stop redirecting?

We would have worse problems than bootstrapping if RIRs stopped returning 
referalls to each other, since there are a large number of IP blocks that 
have been transferred from one RIR to another over the past decades.  A 
reasonable approach would be to put the RIR pool into a draft, then ask 
the RIRs whether they are willing to implement it.

I would be happy to do the DNS approach if we could figure out a way to 
put the IPv6 allocations into a DNS zone that wouldn't require 
many thousands of records.  The AS numbers are even worse in that regard.

> Regarding IANA registries, they have a farm of servers and caching 
> infrastructure. They have already been doing some larger scale caching 
> for some registries that have been hit by large numbers, so they can do.

Really?  3000 http queries per second is very large scale.

>> get the first server in fixed list with a hammer.

The current suggestion is to make a pool of servers, e.g.

numbers.rdap.arpa A 1.2.3.4 ; ARIN
 	          A 2.3.4.5 ; RIPE
 		  A 3.4.5.6 ; LACNIC
 		  A 4.5.6.7 ; APNIC
 		  A 5.6.7.8 ; AFRINIC

This at least spreads the load around.  I suppose as s minor optimization 
you could envision Akamai-style tricks that send DNS clients a server that 
is topologically close to them.

Regards,

---

From: Andy Newton <[email-masked]>
Date: Wed, 19 Jun 2013 16:31:12 +0000

>Really?  3000 http queries per second is very large scale.

Aren't you mixing models? 3000 HTTP queries/sec would be for an HTTP
bootstrap server, not for an IANA XML/JSON registry approach where the
clients fetch the data once in a blue moon.

-andy

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Wed, 19 Jun 2013 15:46:56 -0300

Yes, methinks we're talking about two related, but different
problems/aspects.

---

From: "John Levine" <[email-masked]>
Date: 19 Jun 2013 20:07:23 -0000

>clients fetch the data once in a blue moon.

Sort of, but speaking as a Lazy Programmer(TM), I don't think that the
IANA registry approach will work the way you want it to.

The assumption here appears to be that RDAP clients will fetch a
document from the registry, spin up an XML parser (that's what it's in
now), turn it into some internal database format, store the database
in an atomic way (in case two clients decide to fetch it at the same
time), then provide some way for that client and other clients on the
same host to query the internal database, and to realize when the TTL
on the internal database has expired and fetch it again.

I can't help but note that this bootstrap process is considerably more
complex than the RDAP queries it's supposed to precede.  We Lazy
Programmers will either fetch the file every time and throw it away,
or more likely we will notice that even though there is no formal
numbers bootstrap pool, in fact all of the RIRs know who's responsible
for what, so we'll use one of them as a boostrap anyway.

For the names, on the other hand, sticking the TLD or the whole domain
into a DNS name as part of a wget or curl command is about two lines
of shell script.

R's,
John

---

From: Ernie Dainow <[email-masked]>
Date: Wed, 19 Jun 2013 17:22:09 -0400

Yes, the process you describe is complex. So an Extra Lazy Programmer, 
realizing that the IANA tables don't change very much (certainly not for 
Numbers or the major TLDs) would use a simple utility script once every 
month or so to pull the IANA tables for names and/or numbers, strip the 
XML and store them as two column text files (TLD or Number, URL). These 
text files (all relatively small) are read by client software for in 
memory lookups. The RDAP redirector (assuming it gets updated 
frequently) provides backup for the few outdated entries in the tables 
between local updates.

The Super Extra Lazy Programmer, simply waits for IANA to publish the 
tables and someone on the mailing list to publish an open source utility 
script they can use to create their own local files.

-Ernie

---

From: "John R Levine" <[email-masked]>
Date: 19 Jun 2013 18:03:55 -0400

> Numbers or the major TLDs) would use a simple utility script once every month 
> or so to pull the IANA tables for names and/or numbers, strip the XML and 
> store them as two column text files (TLD or Number, URL).

You must know much more industrious lazy programmers than I do.  Assuming 
you have such a file, could you show me how to splice the appropriate 
server name for an IPv6 address into a wget in a shell script in a 
reasonable number of lines of code?  Keep in mind that the IANA IPv6 
allocations range in length from /12 to /23, and you should't cheat, since 
there are adjacent /23's assigned to different RIRs.

For some real life examples, look at the freeware WHOIS client that comes 
with FreeBSD.  It has some flags to query specific WHOIS servers, and
"-c foo" to query foo.whois-servers.net, but that's it.

The linux client can use a config file of patterns and servers, but as far 
as I can tell, linux distros don't come with one (my Ubuntu doesn't). A 
few weenies use one that's maintained on a git site.

Really, I'm not opposed to a reasonable bootstrap, but reasonable has to 
be something that isn't more work than the actual work.

Do you really think that <tld>.domain.rdap.arpa is unworkable for names? 
It sure would be nice to be able to do something like this to look up a 
domain's abuse contact:

dom=$1
wget http://$(echo "$dom"|sed -e 's/.*\.//').domain.rdap.arpa/contact/abuse

Or assuming we do the numbers pool:

ip=$1
wget http://pool.numbers.rdap.arpa/ip/$1/abuse

Regards,

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 19 Jun 2013 16:33:56 -0700

> It sure would be nice to be able to do something like this to look up a
Can you (or someone) point me/us at something that explains how .ARPA is
administered?  Is it an IANA project, and we would need to set up a
registry in the usual way that results in updates to that zone?

-MSK

---

From: "John R Levine" <[email-masked]>
Date: 19 Jun 2013 20:24:54 -0400

> registry in the usual way that results in updates to that zone?

RFC 3172 describes the operation of .ARPA.  It roughly says that if the 
IESG approves a standards track document that adds something to .ARPA, 
then the IAB asks IANA to implement it.

For the RDAP names, my proposal (which I can merge into Marc's I-D if 
people want) is to have a bootstrap per TLD, so the name or addresses of 
the RDAP bootstrap server is a field added to their existing TLD database, 
with no new registries needed.

I expect the process of updating rdap.arpa would be similar to that for 
in-addr.arpa or ip6.arpa, but that'd be up to IANA.

Regards,

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 19 Jun 2013 20:40:29 -0400

Le 2013-06-19 à 19:33, "Murray S. Kucherawy" <[email-masked]> a écrit :

> Do you really think that <tld>.domain.rdap.arpa is unworkable for names? It sure would be nice to be able to do something like this to look up a domain's abuse contact:
> 
> 
> Can you (or someone) point me/us at something that explains how .ARPA is administered?

http://www.iana.org/domains/arpa  and RFC3172.

>   Is it an IANA project, and we would need to set up a registry in the usual way that results in updates to that zone?

if we go that route, then we will put some guidance in the RFC and IANA will implement it.  The details of this is not important at this point. We need to first agree that this is the right approach.

Marc (also IAB member shepherd for .arpa liaison to IANA)

---

From: Arturo Servin <[email-masked]>
Date: Thu, 20 Jun 2013 10:11:06 +0700

I agree with the three (Andy, Carlos and John).

    This bootstraping would suppose to be once in a while, so we
shouldn't need a large infrastructure. But as John said, we lazy
programers can be a problem; and a big one.

Regards,
as

---

From: Arturo Servin <[email-masked]>
Date: Thu, 20 Jun 2013 10:20:28 +0700

IPs have allocation hierarchy, that is why ip6 and in-addr are in
the way the are. ASNs do not have it and the registry is a bit messy (at
least the 2 bytes one).

    So, why not just use:

199679.as.rdap.arpa?

    It would be 4 billion zone though.

> 9.7.6.9.9.1.0.0.0.0.as.rdap.arpa. Just a thought. 

regards,
as

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Thu, 20 Jun 2013 00:43:43 -0300

Yup, the AS registry is flat. Reverse notation in this case does not help.

One possibility is to have a flat zone with potentially 4billion records
(although it would be closer to 40k-50k records today, not unmanageable
at all).

cheers,

~Carlos

---

From: Andy Newton <[email-masked]>
Date: Thu, 20 Jun 2013 12:13:23 +0000

On 6/19/13 6:03 PM, "John R Levine" <[email-masked]> wrote:

>>month 
>You must know much more industrious lazy programmers than I do.

I agree with Ernie here.

>  Assuming 

Code for that is in NicInfo. You can consult the source. It wasn't
terribly difficult to write at all. I did it at the beach.

>few weenies use one that's maintained on a git site.

A lot of Linux distros use "jwhois", which has some quirks but attempts to
figure out the first hop on its own. But even then it sends a lot of
domain queries to ARIN and a lot of AS queries to VeriSign. A very large
percentage of port 43 queries received by ARIN are not answerable by ARIN
because they are domain queries. But we have to answer with something, and
in the RDAP world answering with a redirect is just as cheap as answering
with a 404.

As a side note, a lot of lazy programmers hard code our server IP
addresses. We can take an IP out of rotation and there will still be port
43 traffic hitting that IP a year later.

>wget http://$(echo "$dom"|sed -e
>'s/.*\.//').domain.rdap.arpa/contact/abuse

/contact/abuse was taken out of the drafts sometime back. So I guess this
provides some insight about programmers reading RFCs. :)

>wget http://pool.numbers.rdap.arpa/ip/$1/abuse

But you are suggesting a hybrid bootstrap approach. So it is also complex
as there are two code paths. In this approach, a lazy programmer is just
gonna hit one of the RIR servers and hope for a redirect. After all,
that's what a lot of them do today even though there are no such things as
redirects in Whois.

-andy

---

From: "John Levine" <[email-masked]>
Date: 20 Jun 2013 16:13:08 -0000

>I agree with Ernie here.

So I've been scratching my head, trying to channel my inner Lazy
Programmer.  It occurred to me that a key fact I was forgetting is
that for numbers, the bootstrap information changes approximately
never, certainly slower than the typical software revision cycle.

The IPv4 list, assuming it's by /8, will never change.  The IPv6 list
hasn't changed since 2006 (other than deprecating old Teredo and 6bone
space in 2008) and given how big those /12 allocations are, probably
won't change for at least another five years.  The ASN list actually
changed last week with an assignment to LACNIC, but the previous
assignment lasted six years.

So in practice it would be workable to bake the bootstrap into numbers
clients, with the advice to update your client every year or two.

For names, the situation is considerably more fluid.  There are
several hundred TLDs, likely to increase soon to about 2000.  I see
that there are updates to the root zone, typically nameserver changes,
several times a month which seems like a plausible rough proxy for how
often RDAP servers would change, and ICANN is likely to be trickling
out new TLDs monthly for the next couple of years.

Hence I wouldn't want to bake in anything for names that didn't have a
level of indirection to something that can be kept up to date, i.e.,
<tld>.names.rdap.arpa.

R's,
John

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 20 Jun 2013 13:10:21 -0400

> never, certainly slower than the typical software revision cycle.

a) the allocations shall not change.
b) therefore, a client that had saved the previous table could only go back to fetch a new version of the table when a requested object is not in the range of its current saved version. In this case, it would be almost "on-demand", not everybody at the same time, etc...

Marc.

---

From: "John R Levine" <[email-masked]>
Date: 20 Jun 2013 14:17:50 -0400

> b) therefore, a client that had saved the previous table could only go 
> back to fetch a new version of the table when a requested object is not 
> in the range of its current saved version. In this case, it would be 
> almost "on-demand", not everybody at the same time, etc...

Holy DDoS, Batman!*

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?

Also, the point of the "baked in" was that the RDAP client need not 
include the ability to update the table.

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.

R's,
John

* - Sacré ddsd, Homme-chauve-souris!

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 20 Jun 2013 15:12:06 -0400

Le 2013-06-20 à 14:17, "John R Levine" <[email-masked]> 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.

> 
> Also, the point of the "baked in" was that the RDAP client need not include the ability to update the table.
> 
> 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
> 
> 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.
> 
> R's,
> John
>

---

From: "John R Levine" <[email-masked]>
Date: 20 Jun 2013 15:34:03 -0400

> 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 befo…

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.

>> 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.

Regards,

---

From: Ernie Dainow <[email-masked]>
Date: Thu, 20 Jun 2013 15:42:32 -0400

There seems to be a big difference in opinion about what is a lot of work
or not. Managing an IANA table and using it for lookup of names and numbers
is not difficult in python, ruby, php and several other environments.
Granted it may not be so easy to do in a shell script. But then lots of
things are not done easily in a shell script. Should the decision on
whether to use IANA tables or DNS for bootstrapping depend on how easy it
is to use in a shell script?

-Ernie

On Wed, Jun 19, 2013 at 6:03 PM, John R Levine <[email-masked]> wrote:

>> month or so to pull the IANA tables for names and/or numbers, strip the XML
>> and store them as two column text files (TLD or Number, URL).
>>
>
> as I can tell, linux distros don't come with one (my Ubuntu doesn't). A few
> weenies use one that's maintained on a git site.
>
> wget http://$(echo "$dom"|sed -e 's/.*\.//').domain.rdap.arpa/**
> contact/abuse
>
> wget http://pool.numbers.rdap.arpa/**ip/$1/abuse<http://pool.numbers.rdap.arpa/ip/$1/abuse>
>
>
> Regards,

---

From: "John R Levine" <[email-masked]>
Date: 20 Jun 2013 16:22:12 -0400

> is to use in a shell script?

Remember that the IETF can't dictate to people what to do.  We can only 
tell them how to interoperate.  It seems rather likely that people will be 
doing RDAP from shell scripts, since we certainly do WHOIS from shell 
scripts.  So if we dictate something too hard to do in a shell script, the 
Lazy Programmers will do something else, with consequent interop problems.

What do you think of the suggestion that the numbers bootstrap be baked 
into the clients, with occasional updates via unspecified means since it 
changes so rarely, and the names use <tld>.domain.rdap.arpa?

Regards,

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Thu, 20 Jun 2013 18:06:22 -0300

But we the IETF can try to help people do the 'right' (or the less
harmful) thing. People who hardcode addresses are hopeless, but I tend
to believe that there is a majority of mostly well intended, although a
bit clueless, pool of programmers out there.

This is where the idea of the pool comes in. Again, I'd like to stress
that the pooling would work in addition to any bootstrapping mechanisms
that we settle on, plural intended.

I see from the numbers John shared that pooling for names would result
in either smaller TLDs sharing an disproportionate portion of .com's
query load or .com's servers appearing anywhere.

regards,

Carlos

On 6/20/13 5:22 PM, John R Levine wrote:
> tell them how to interoperate.  It seems rather likely that people will
> be doing RDAP from shell scripts, since we certainly do WHOIS from shell
> scripts.  So if we dictate something too hard to do in a shell script,
> the Lazy Programmers will do something else, with consequent interop
> problems.
>

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 20 Jun 2013 17:10:38 -0400

>> is to use in a shell script?

I'm also in the opinion that the lazy programmer argument is not very useful, and I don't agree with it. I'm sensible to complexity, but there is a limit to that argument.

Marc.

> 
> Remember that the IETF can't dictate to people what to do.  We can only tell them how to interoperate.  It seems rather likely that people will be doing RDAP from shell scripts, since we certainly do WHOIS from shell scripts.  So if we dictate something too hard to do in a shell script, the Lazy Programmers will do something else, with consequent interop problems.
> 
> What do you think of the suggestion that the numbers bootstrap be baked into the clients, with occasional updates via unspecified means since it changes so rarely, and the names use <tld>.domain.rdap.arpa?
> 
> Regards,

---

From: "John Levine" <[email-masked]>
Date: 20 Jun 2013 21:30:52 -0000

>that we settle on, plural intended.

People use fixed WHOIS server addresses because there is a lot of
crufty old code dating back to the early days when there only was one
WHOIS server.  There are no legacy RDAP clients, so a simple and
effective way to ensure that even the Lazy Programmers write their
name clients to use <tld>.domain.rdap.arpa is to make it never work if
they don't.

Numbers are different because no matter how excellent the bootstrap
is, there will always be referrals for things that have been moved
from one RIR to another, so the RIRs will always have a pretty good
idea of who is responsible for what.

Also, please keep in mind that LPs will be lazy whether you like it or
not, and there is no plausible numbers bootstrap as simple as plugging
the TLD into a fixed name.  No matter how vigorously we wag our
fingers and write MUST MUST MUST MUST, some numbers clients will take
lame-o approaches like a fixed starting server or a built-in bootstrap
list. I don't see any merit in denying the inevitable reality.

R's,
John

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 20 Jun 2013 17:20:03 -0400

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

> 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.

> 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,
>>>

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 20 Jun 2013 17:22:26 -0400

> What do you think of the suggestion that the numbers bootstrap be baked into the clients, with occasional updates via unspecified means since it changes so rarely, and the names use <tld>.domain.rd…

The new update of my draft being written is saying:
- numbers: get data from IANA.
- names: use DNS.
(a combination of the two drafts I wrote).

will see where it goes.

Marc.

---

From: "John R Levine" <[email-masked]>
Date: 20 Jun 2013 18:03:24 -0400

> an XML file is just a small file on the Internet. Cached, there is a 
> copy everywhere.

I have a physical server in a nearby hosting center and some VPSes in 
Pennsylvania.  I'm fairly sure there are no http caches in front of any of 
them and even more sure there are no https caches.  IANA's web servers 
appear to be on a single physical network in California, not mirrored 
using Akamai or the like.

The RDAP clients I expect to use won't be full web browsers, and they're 
not on consumer ISPs with awful "transparent" web caches.  I also have no 
interest in dragging a big XML parser into a tiny JSON application.

You know, if we assume that the TTL on the IANA file is a year or two, my 
baked-in+upgrade approach is functionally equivalent to yours and depends 
less on third parties who may not want to be volunteered.

R's,
John

Regards,

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 20 Jun 2013 18:40:16 -0400

Le 2013-06-20 à 18:03, "John R Levine" <[email-masked]> a écrit :

>> an XML file is just a small file on the Internet. Cached, there is a copy everywhere.
> 
> I have a physical server in a nearby hosting center and some VPSes in Pennsylvania.  I'm fairly sure there are no http caches in front of any of them and even more sure there are no https caches.  IANA's web servers appear to be on a single physical network in California, not mirrored using Akamai or the like.

ok. I think we are getting way too deep here and becomes completly irrelevant. 

> 
> The RDAP clients I expect to use won't be full web browsers,

don't need to.

> and they're not on consumer ISPs with awful "transparent" web caches. I also have no interest in dragging a big XML parser into a tiny JSON application.

then, I'm against that argument. This is pretty straightforward parsing.

> 
> You know, if we assume that the TTL on the IANA file is a year or two, my baked-in+upgrade approach is functionally equivalent to yours and depends less on third parties who may not want to be volunteered.

there is implementation specificities (that are outside of the scope of the IETF) and there are interop stuff.

What I'm saying is that the client should get the data from the IANA registry. Does it do it often, not often, upgrade, etc... is not in IETF document. However, we should provide some guidance about what to do. The implementor may decide to use or not use the guidance. Therefore, baked-in+upgrade or whatever is irrelevant to me, as long as they use the same source, which is what I care.

marc.

---

From: Byron Ellacott <[email-masked]>
Date: Fri, 21 Jun 2013 05:45:12 +0000

Hi Marc,

>(a combination of the two drafts I wrote).

How would a client bootstrap a query for 29.12.202.in-addr.arpa ?

If I am querying for IP network 2001:0400::/22, which server would I
contact? [0]

I would prefer to see an approach that minimises variance in bootstrap
complexity between names and numbers: making numbers bootstrap too complex
increases the likelihood of an unofficial solution arising, such as an
HTTP(S) request to rdap.org or rdap.arin.net.

  Byron

[0] To save you the time, here are the relevant entries in the IANA IPv6
registry:

2001:0400::/23 ARIN     1999-07-01 whois.arin.net ALLOCATED
2001:0600::/23 RIPE NCC 1999-07-01 whois.ripe.net ALLOCATED

(You might see 0::/0, 2000::/3, or a 404 for this query, but the
bootstrapping client shouldn't be the place where the final answer is
determined).

  Byron

---

From: Arturo Servin <[email-masked]>
Date: Fri, 21 Jun 2013 15:20:32 +0700

I would prefer all DNS.

    Byron made good points.

.as

---

From: Arturo Servin <[email-masked]>
Date: Fri, 21 Jun 2013 15:31:35 +0700

Marc,

    It seems that you are focusing too much in that "an XML is very easy
to parse" but you are forgeting the scalability issues that lazy
programers may be.

    As John said in other email we could use all the MUST, MUST NOT that
we can imagine and even though there is no guarantee that those
guidelines would be follow.

    I am not saying that we should not use XML in IANA, just saying that
we must not minimize the operational impact that it could be to IANA.

Regards,
as

---

From: Tony Hansen <[email-masked]>
Date: Fri, 21 Jun 2013 09:15:01 -0400

> we must not minimize the operational impact that it could be to IANA.

IANA already uses XML in many many places on their web site,
particularly in their protocol registries.

    Tony Hansen

---

From: Arturo Servin <[email-masked]>
Date: Fri, 21 Jun 2013 21:07:49 +0700

Yes, but now they are not hit by many requests as it may be with rdap.

/as

---

From: Kim Davies <[email-masked]>
Date: Fri, 21 Jun 2013 08:26:01 -0700

>    Yes, but now they are not hit by many requests as it may be with rdap.

At least one of IANA's registries is hit with around a billion requests per month over HTTP/HTTPS. We deploy data that we serve that has high utilisation via a content delivery network with points of presence around the world, and the remainder of the website is across two fully redundant sites. We can expand our infrastructure if the IETF produces a new protocol requirement that we can not currently satisfy.

I would suggest choosing the right solution based on all the factors, but I wouldn't necessarily veto a particular approach if it was otherwise considered the right one, solely on the basis that IANA would not be able to host it.

In sum, if there is a reason for IANA to maintain a data set with high utilisation expectations, we will take steps to support it with a robust infrastructure. 

kim

---

From: "John Levine" <[email-masked]>
Date: 21 Jun 2013 17:20:28 -0000

>How would a client bootstrap a query for 29.12.202.in-addr.arpa ?

It would look at arpa.domains.rdap.arpa to get the name of the RDAP
server for .arpa, if there were one.  I expect that's not the answer
to the question you meant to ask.

If you're asking how to bootstrap a query for 202.12.29.0/24, or
2001:0400::/22, my proposal is that the numbers bootstraps are built
into the clients, with informal advice to update them every year or
two, sort of like the root zone hints in a DNS cache.  Given how
slowly the IANA numbers tables change, I think that's more workable
than something that tries to boostrap the rather irregular numbers
assignments on the fly.

>HTTP(S) request to rdap.org or rdap.arin.net.

Indeed.  But do keep in mind that there are some rather basic operational
differences between names and numbers that won't change.

* Numbers assignments move among RIRs, so the RIRs have a history of
cooperation and awareness of each other's assignments.  

* Names never move from one TLD to another, and there's no need for
operational cooperation between different TLDs.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 21 Jun 2013 17:28:07 -0000

>In sum, if there is a reason for IANA to maintain a data set with high utilisation
>expectations, we will take steps to support it with a robust infrastructure. 

Thanks.

While we have your attention, do you see problems with the current
name bootstrap proposal?  Each TLD is requested to provide the name or
IP addresses of an RDAP server, sort of like they provide the name of
a WHOIS server now, and you publish them as CNAME or A/AAAA records
in <tld>.domain.rdap.arpa.

R's,
John

---

From: Byron Ellacott <[email-masked]>
Date: Mon, 24 Jun 2013 01:32:24 +0000

>to the question you meant to ask.

Presumably, the server for .arpa is then going to redirect the client to
the appropriate RDAP server for the specific resource associated with the
reverse domain being queried.  The implicit questions are: how the server
for .arpa is going to do that; and why wouldn't a client skip all the
bothersome XML parsing stuff and just ask arpa.domains.rdap.arpa?

>than something that tries to boostrap the rather irregular numbers

I don't mind this approach; is there suitable RFC wording that would allow
clients to have confidence that asking one of the numbers bootstrap
servers will get you to the right place for the answer you seek?

(ie, the RIRs will redirect to each other, but should that information go
into an RFC, and if so, how?)

>cooperation and awareness of each other's assignments.

As you pointed out a few messages ago, numbers query clients are going to
rely on the RIRs cooperating for redirection no matter what bootstrap
method is used.

  Byron

---

From: "John R Levine" <[email-masked]>
Date: 23 Jun 2013 21:47:13 -0400

> reverse domain being queried.

Uh, no.  Since arpa is a TLD, it'll find you the RDAP server for the .arpa 
TLD, which will tell you something about the people at IANA who manage it. 
As I said, this is probably not the question you meant to ask.  It's worth 
noting somewhere that asking about the rDNS name associated with an IP 
address is not the same as asking about that IP address.  Name and number 
queries are different, different question syntax and different answer 
syntax.

>> two, sort of like the root zone hints in a DNS cache. ...

> servers will get you to the right place for the answer you seek?

This is the IETF, so we can't force anyone to do anything.  But assuming 
the RIRs are willing, we could put in language along the lines of what I 
suggested a couple of messages ago.

R's,
John

---

From: Byron Ellacott <[email-masked]>
Date: Mon, 24 Jun 2013 03:44:45 +0000

Hi John,

>queries are different, different question syntax and different answer

My point is that when querying for the reverse domain, you will eventually
get to:

	https://rdap.apnic.net/domain/29.12.202.in-addr.arpa

And if you're querying for the equivalent /24, you will eventually get to:

	https://rdap.apnic.net/ip/202.12.29.0/24

The steps followed might be a little different given slightly different
hierarchies between reverse DNS and allocations, but the key difference is
only the expected query load.  If bootstrapping via DNS is sufficient for
the reverse DNS domain queries, is query load the main reason it isn't
also sufficient for IP network queries?

(Given we broadly agree on bootstrapping approach, I'm not sure this line
of discussion is all that relevant.)

  Byron

---

From: Byron Ellacott <[email-masked]>
Date: Mon, 24 Jun 2013 06:18:20 +0000

Hi John,

On 24/06/13 3:05 PM, "John R. Levine" <[email-masked]> wrote:

>> If bootstrapping via DNS is sufficient for the reverse DNS domain
>> queries, is query load the main reason it isn't also sufficient for IP
>> network queries?
>
>Numbers are different.  For IPv4 you could fake it by using the top octet
>of the address, but for IPv6 and ASNs the allocation structure is
>extremely irregular and I don't see any way to represent it in the DNS
>with reasonable performance.

Right, I agree, but I'm not suggesting that bootstrap should start by
trying to find the best server directly by picking some part of the
address and looking that up in the DNS.  I am suggesting that if
arpa.domain.rdap.arpa is capable of redirecting a querying client to the
correct server for 2.0.192.in-addr.arpa, then something.rdap.arpa is
capable of redirecting a querying client to the correct server for
192.0.2/24.

>It's perfectly possible to represent the allocation information in a
>compact and efficiently searchable form (it is, after all, on three pages
>at IANA), but not by using the formats that the DNS provides.  The number
>bootstrap data changes very rarely, like once a year or less, so it's OK
>for the update not to be automatic.  Hence the per-TLD DNS lookup for the
>regularly named but frequently updated and uncoordinated DNS registries,
>and the vague baked-in bootstrap hack for the irregularly named, but
>rarely updated and well coordinated RIRs.

And something.rdap.arpa could quite easily be a set of servers where a
client can select a good reasonable starting server from that set based on
an internal hints table, but where any of the set of servers will do the
appropriate redirection.

What I don't want to see is that the bootstrap process for numbers
involves fetching that table as the first step in the bootstrap, plus or
minus caching, because that sort of fetch-and-parse significantly
increases the complexity of doing a query for an IP network.  (And I don't
think you've suggested this.)

  Byron

---

From: "John R Levine" <[email-masked]>
Date: 24 Jun 2013 10:22:00 -0400

> I am suggesting that if arpa.domain.rdap.arpa is capable of redirecting 
> a querying client to the correct server for 2.0.192.in-addr.arpa, then 
> something.rdap.arpa is capable of redirecting a querying client to the 
> correct server for 192.0.2/24.

I don't know anyone who expects that IANA would run a high performance 
RDAP server on .ARPA.  It seems unlikely that they they would run any RDAP 
server other than perhaps a small one for .INT and the root database.

> client can select a good reasonable starting server from that set ...

That's basically the pool approach.

> think you've suggested this.)

Again, right.  My idea is that the numbers bootstrap is built into the 
client or a local table, with no automatic fetching or updates.

Regards,

---

From: "John R. Levine" <[email-masked]>
Date: 24 Jun 2013 01:05:10 -0400

> queries, is query load the main reason it isn't also sufficient for IP 

I could have sworn we went over all this last week, but anyway, ...

Query load is only part of the reason.

Domain names are allocated a TLD at a time, so a reasonable boostrap is to 
use the TLD name as the handle.  It doesn't matter that the .COM server 
gets 3000 queries/sec, since the vast majority of bootstrap queries for 
com.domain.rdap.arpa will be satisfied from local caches.  Due to both the 
ICANN new TLD program and the number of existing TLDs, it seems likely 
that the bootstrap data will change fairly often, so we need something 
that automatically updates clients when there's a change, hence DNS.

Marc's draft says "longest match", but in fact the IANA domain registry is 
all TLDs so just doing the TLD lookup rather than the whole name is 
adequate and makes the DNS caches work.

If you do the obvious thing for IPv4 and IPv6 and use something that looks 
like rDNS, e.g. 4.3.2.1.ip4.rdap.arpa. or 
f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.f.e.d.c.b.a.9.8.7.6.5.4.3.2.1.0.ip6.rdap.arpa, 
and cover the DNS namespace with DNS wildcards, you get pessimal DNS cache 
behavior, i.e., none at all.  Each query for a different address goes back 
to the bootstrap server which synthesizes a unique response per address, 
which means vast traffic on the rdap.arpa servers, and DNS caches filling 
up with useless junk, since a cache entry is only reused if it exactly 
matches a previous query.

The longest allocated IPv6 prefix is a /23, but even if you truncate the 
bootstrap queries to 24 bits (for 4 bit rDNS boundaries) you're still 
going to need 4096 real or synthesized entries for each allocated /12, 
with basically the same problems.

Even worse, the ASN space is flat, with allocated numbers ranging from 1 
to 394,239 with some large unallocated holes.  A DNS zone of that size is 
not going to make DNS servers or DNS caches happy.  Even if we invented a 
rDNS like representation to make it easier to cover ranges with wildcards, 
it'd have the same performance problems.

Does that make more sense?

R's,
John

---

From: "Linlin Zhou" <[email-masked]>
Date: Tue, 25 Jun 2013 10:30:15 +0800

> It's perfectly possible to represent the allocation information in a
compact and
> efficiently searchable form (it is, after all, on three pages at IANA),
but not by
> using the formats that the DNS provides.  The number bootstrap data
> changes very rarely, like once a year or less, so it's OK for the update
not to be
> automatic.  Hence the per-TLD DNS lookup for the regularly named but
> frequently updated and uncoordinated DNS registries, and the vague
baked-in
> bootstrap hack for the irregularly named, but rarely updated and well
> coordinated RIRs.
> 
I agree with John. I think it is better to use a local table or file for
numbers bootstrap and update when necessary. We've already adopted this
method.

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 25 Jun 2013 09:16:39 -0400

> numbers bootstrap and update when necessary. We've already adopted this

The "local table or file" has to come from somewhere. And the right place is IANA registry.  So the specification should tell you where to get the data. The implementation may decide to fetch it more or less frequently, such as software updates or more frequently. THis is implementation choice.  So the whole point of using the IANA registry is to ensure that everybody is taking the right source of information at the right place.

Marc.

---

From: "John R Levine" <[email-masked]>
Date: 25 Jun 2013 09:45:09 -0400

> The "local table or file" has to come from somewhere. And the right place is IANA registry.  So the specification should tell you where to get the data. The implementation may decide to fetch it mo…

That's fine so long as we also make it abundantly clear that the bootstrap 
information changes very slowly so that clients MUST NOT fetch it on every 
run and SHOULD NOT fetch it every day, or even every week or every month.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 25 Jun 2013 15:26:29 -0000

>> The "local table or file" has to come from somewhere. And the right place is IANA registry.  So
>the specification should tell you where to get the data. The implementation may decide to fetch it
>more or less frequently, such as software updates or more frequently. THis is implementation
>choice.  So the whole point of using the IANA registry is to ensure that everybody is taking the
>right source of information at the right place.
>

It occurs to me that this is like the bootstrap file in your DNS
cache.  The authoritative copy comes from IANA, but it changes very
slowly, and the penalty for being slightly out of date is low, so you
don't need to be able to update it automatically.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 25 Jun 2013 11:26:22 -0700

> don't need to be able to update it automatically.

I'm a little uncomfortable with the assumption that the numbers list will
never change ever amen, so I'd prefer this sort of approach versus
expecting clients to compile the list in.

-MSK, participatorially

---

From: "John R Levine" <[email-masked]>
Date: 25 Jun 2013 16:00:37 -0400

> expecting clients to compile the list in.

I figured it'd be in a local config file that is installed with the RDAP 
client and updated either when you update the client or perhaps by running 
a separate update program.  But again, it doesn't have to be particularly 
easy or automatic since once a year is likely to be plenty.

Regards,