Subject: [weirds] bootstrap slides

From: Marc Blanchet <[email-masked]>
Date: Fri, 26 Jul 2013 13:58:28 -0400

Hello,
 please find slides for the bootstrap discussion.

Marc.

---

From: "John Levine" <[email-masked]>
Date: 27 Jul 2013 09:08:46 -0000

> please find slides for the bootstrap discussion.

Looks OK, except that you left out the most likely numbers bootstrap,
start at your local RIR and trust them to redirect.

R's,
John

---

From: Marc Blanchet <[email-masked]>
Date: Sat, 27 Jul 2013 12:58:45 +0100

> start at your local RIR and trust them to redirect.

ok, will add. But at the same time, somewhere we need to list those servers. Shall not be in an RFC. Then, it shall be an IANA registry. So if it is an IANA registry, then why not then do a match using the ranges and then you most likely go to the right server right away. 

Marc.

---

From: "John R Levine" <[email-masked]>
Date: 27 Jul 2013 14:43:24 +0200

> ok, will add. But at the same time, somewhere we need to list those 
>servers. Shall not be in an RFC. Then, it shall be an IANA registry. So
>if it is an IANA registry, then why not then do a match using the ranges 
>and then you most likely go to the right server right away.

Because it's going to be configured one time when the lookup software is 
installed, by asking the person doing the installing where they are, or 
maybe a rough guess from the high bits of the local IP address, not done 
dynamically on every lookup.  Given that there are only five RIRs, and 
there is approximately zero chance that there will ever be any more, there 
might nominally be a registry, but in reality it'll be hard coded.

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

---

From: Marc Blanchet <[email-masked]>
Date: Sat, 27 Jul 2013 14:03:20 +0100

Le 2013-07-27 à 13:43, "John R Levine" <[email-masked]> a écrit :

>> ok, will add. But at the same time, somewhere we need to list those servers. Shall not be in an RFC. Then, it shall be an IANA registry. So
>> if it is an IANA registry, then why not then do a match using the ranges and then you most likely go to the right server right away.
> 
> Because it's going to be configured one time when the lookup software is installed, by asking the person doing the installing where they are, or maybe a rough guess from the high bits of the local IP address, not done dynamically on every lookup.  Given that there are only five RIRs, and there is approximately zero chance that there will ever be any more, there might nominally be a registry, but in reality it'll be hard coded.

that is fine. The implementation choice of hard coding or else is implementation choice. We shall still tell the implementors where to get the right data. hence a registry. 

the question at hand is the following:
a) rely on redirect being implemented by all RIR and that they trust themselves. If someone is not playing well the game (server down, wrong redirection, bugs,...), then it falls apart. I don't think the IETF can "ask/require" the RIR to do redirection between themselves.

b) rely on matching using the IANA registry, but then have the rir-redirection optional ( just great if done, but not mandatory). 

I think b) is more reliable and also separate clearly the protocol part and the operational part.  let the operational part do their own stuff (decide if they want to do nice redirect between themselves).

Marc.

---

From: Byron Ellacott <[email-masked]>
Date: Sat, 27 Jul 2013 14:58:21 +0000

Hi Marc,

On 27/07/13 3:03 PM, "Marc Blanchet" <[email-masked]> wrote:

>>> if it is an IANA registry, then why not then do a match using the
>>>ranges and then you most likely go to the right server right away.
>> 
>> Because it's going to be configured one time when the lookup software
>>is installed, by asking the person doing the installing where they are,
>>or maybe a rough guess from the high bits of the local IP address, not
>>done dynamically on every lookup.  Given that there are only five RIRs,
>>and there is approximately zero chance that there will ever be any more,
>>there might nominally be a registry, but in reality it'll be hard coded.
>
>that is fine. The implementation choice of hard coding or else is
>implementation choice. We shall still tell the implementors where to get
>the right data. hence a registry.
>
>a) rely on redirect being implemented by all RIR and that they trust
>themselves. If someone is not playing well the game (server down, wrong
>redirection, bugs,...), then it falls apart. I don't think the IETF can
>"ask/require" the RIR to do redirection between themselves.

You need to trust the RIRs to redirect to each other.  140.83.0.0/16, for
example, is in 140/8 that IANA has registered as LEGACY space on
whois.arin.net, but 140.83/16 was transferred to APNIC in 2011.  There are
large tracts of IPv4 in the "swamp" of legacy where the exact disposition
of each block is not recorded at the IANA level.  You can see the full
disposition of the entire internet number space on the NRO website:

	http://www.nro.net/wp-content/uploads/apnic-uploads/delegated-extended

It is a significantly larger list than the IANA registries.

You can head over to http://rdappilot.arin.net/ip/140.83.0.0/16 and be
redirected to http://testwhois.apnic.net/ip/140.83.0.0/16 .

>b) rely on matching using the IANA registry, but then have the
>rir-redirection optional ( just great if done, but not mandatory).

Redirection between RIRs is a critical goal for us, but I don't think the
IETF can formalise it.

Noting that the IANA registry is a useful starting point for selecting an
RIR server should be sufficient.

  Byrom

---

From: Marc Blanchet <[email-masked]>
Date: Sat, 27 Jul 2013 17:02:40 +0200

Le 2013-07-27 à 16:58, Byron Ellacott <[email-masked]> a écrit :

> You need to trust the RIRs to redirect to each other.

I trust them, but my point was about how much IETF can say about it.

>  140.83.0.0/16, for
> of each block is not recorded at the IANA level.

let's forget Ipv4... just do Ipv6 ;-)

>  You can see the full

that was my point.

> RIR server should be sufficient.

great. I agree.

Marc.

---

From: Andy Newton <[email-masked]>
Date: Sun, 28 Jul 2013 09:10:57 +0000

>redirected to http://testwhois.apnic.net/ip/140.83.0.0/16 .

Correction, http://rdappilot.arin.net/restfulwhois/rdap/ip/140.83.0.0

$ nicinfo -V 140.83.0.0
# NicInfo v.1000.0.0-SNAPSHOT
## Using configuration found in /Users/anewton/.NicInfo
## Evicted 0 files from the cache
## Assuming query value is IP4ADDR
## Issuing GET for 
http://rdappilot.arin.net/restfulwhois/rdap/ip/140.83.0.0
## Issuing GET for http://testwhois.apnic.net/ip/140.83.0.0
Š

>Redirection between RIRs is a critical goal for us, but I don't think the

I agree with this. In the whois world, not all the RIRs point to the other
RIRs. Only some do it. And while in the RDAP world that might change I
don't think the IETF can mandate it.

>RIR server should be sufficient.

Agree.

-andy

---

From: Arturo Servin <[email-masked]>
Date: Sun, 28 Jul 2013 11:15:07 +0200

If we (the RIRs) do an agreement then we could document it in an
informational RFC.

	This seems something of layer9 today but we could work out this.

/as