Subject: Re: [Crisp] staring points

From: Andrew Newton <[email-masked]>
Date: Thu, 3 Mar 2005 12:28:08 -0500

On Feb 24, 2005, at 1:24 PM, Leslie Daigle wrote:

> Right now, the document mixes the two:  you SHOULD start from
> one defined top, although you MAY do whatever else you please.
> That doesn't really leave room for developing other equivalently
> weighted strategies (e.g., "local AREG -- you SHOULD start at
> areg-iris.yourisp.net", or some such rot), which makes it
> seem like a single TOP. OTOH, the fact that you can do anything
> else means that it's not really a single TOP.

It took me awhile to fully digest this point, but I think I understand 
the concern.

Perhaps this language solves the problem:

It is RECOMMENDED that IRIS clients issuing AREG1 requests use the 
'top' resolution method when no resolution method has been explicitly 
given by a user.  IRIS servers accepting AREG1 requests seeking 
information for which they are not authoritative SHOULD refer clients 
using the 'top' resolution method.

-andy

_______________________________________________
Crisp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/crisp

---

From: Shane Kerr <[email-masked]>
Date: Fri, 04 Mar 2005 11:12:16 +0100

[ After staring at the subject for a few weeks , I started to change it to 
something more appropriate. ;) ]

Andrew Newton wrote:
> It is RECOMMENDED that IRIS clients issuing AREG1 requests use the 'top' 
> resolution method when no resolution method has been explicitly given by 
> a user.  IRIS servers accepting AREG1 requests seeking information for 
> which they are not authoritative SHOULD refer clients using the 'top' 
> resolution method.

To be clear: Top-down searching in AREG matches both the networking and 
political topologies, and should be used.

Apparently recommending that the protocol match the actual way numbers are 
distributed gives people the willies (and to be fair, it conflicts with the 
CRISP requirements document). So we thought that making top-down a 
recommendation, with an opt-out clause, would resolve the problem.

On another point: Andy's text reminds me of a question we thought of a while 
ago, but I don't know the answer to. Is there any provision in IRIS to avoid 
looping? The scenerio above could easily lead to loops. For instance:

12:00, IANA allocates a new AS block to an RIR
12:30, the top-level server is updated to point to the RIR
12:31, user queries top-level server, gets sent to RIR
12:31, RIR tells user to start at the top
12:31, user queries top-level server, gets sent to RIR
12:31, RIR tells user to start at the top
  .
  .
  .

While in the case of RIR's, this is something that can probably be 
prevented, it seems likely that at some point in the hierarchy there would 
at some point be a misconfiguration. Does IRIS recommend or require that 
clients keep track of the chain of referrals to avoid looping?

-- 
Shane Kerr
RIPE NCC

---

From: Andrew Newton <[email-masked]>
Date: Fri, 4 Mar 2005 08:11:14 -0500

On Mar 4, 2005, at 5:12 AM, Shane Kerr wrote:

> prevented, it seems likely that at some point in the hierarchy there 
> would at some point be a misconfiguration. Does IRIS recommend or 
> require that clients keep track of the chain of referrals to avoid 
> looping?

Section 4.2 of iris-core:

    When following entity references and search continuations, clients
    SHOULD only follow an <entity> or <searchContinuation> response once.
    Failure to do so may result in the client process getting stuck in a
    never-ending query loop, commonly known as a referral loop.

Simple loop detection isn't that hard to implement.

-andy

---

From: Leslie Daigle <[email-masked]>
Date: Fri, 04 Mar 2005 11:50:15 -0500

I'm thinking that maybe this should be an agenda (*cough*) item
for our meeting next week...

Leslie.

---

From: Robert Martin-Legene <[email-masked]>
Date: Fri, 4 Mar 2005 23:35:56 +0100

>    SHOULD only follow an <entity> or <searchContinuation> response once.

So if I ask ${TOP} which refers me to ARIN, then ARIN can't tell
me to go to, say, L3 for more detailed info?

That doesn't sound like it scales very well. (I'm also thinking truly
worldwide ISP in an IPv6 world).

-- robert

---

From: Andrew Newton <[email-masked]>
Date: Sat, 5 Mar 2005 10:46:31 -0500

> me to go to, say, L3 for more detailed info?

Perhaps the wordsmithing was not as exact as it could have been:

   When following entity references and search continuations, clients
   SHOULD follow an instance of an <entity> or <searchContinuation> only 
once.

It's also been pointed out to me that some of the examples in DREG use 
the wrong authority.

These are the kinds of things we need to put in the RFC errata.

-andy

---

From: Robert Martin-Legene <[email-masked]>
Date: Sun, 6 Mar 2005 21:46:07 +0100

>   SHOULD follow an instance of an <entity> or <searchContinuation> only 

Is SHOULD really good enough? Better would probably be for the client to
remember where it had been wrt a particular lookup. I know it's harder
to code. But if for instance co.uk was managed by a seperate (from .uk)
registry, you would need multiple references. I guess there are better
examples out there.

>It's also been pointed out to me that some of the examples in DREG use 

I am so happy to hear that. I have tried to understand them and it just
didnt quite click. I may have an idea or two for better examples. Maybe
we can meet up "some day" ;-)

-- robert

---

From: Andrew Newton <[email-masked]>
Date: Sun, 6 Mar 2005 19:45:36 -0500

On Mar 6, 2005, at 3:46 PM, Robert Martin-Legene wrote:
> Is SHOULD really good enough?

According to Section 6 of RFC 2119, all this language is about 
interoperability.  If a client follows a referral more than once, it is 
likely to still be interoperable with the server.  But if it does this, 
then it SHOULD understand the consequences.

> Better would probably be for the client to

Keeping a simple hash set of followed, normalized referrals is probably 
good enough for most approaches.  I have written a more complicated 
scheme that does connection optimization.  However, I don't recommend 
anybody wasting their time doing this as I doubt there is much of a 
need for it and things like LWZ make it moot.

>> It's also been pointed out to me that some of the examples in DREG 
>> use the wrong authority.
>
> I am so happy to hear that.

I know it may seem like I am trying to confuse people by design, but it 
is really quite accidental that I am naturally good at it.  :)

-andy

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Mon, 7 Mar 2005 09:22:22 +0100

> registry, you would need multiple references. 

But those would be different reference "instances" (using Andy's new 
formulation), and it would be perfectly valid to follow them.

Best,
Marcos

---

From: Shane Kerr <[email-masked]>
Date: Mon, 07 Mar 2005 10:33:39 +0100

Leslie Daigle wrote:
> 
> Having read the revised version...
> 
> No, I don't think you're hearing what I'm saying.
> 
> I'm saying that:
> 
>     . if this *spec* defines a TOP starting point, then
>       make it a *name* not a *location*, so that it
>       can be updated over time (that's the NAPTR shim,
>       and I propose that areg-iris.arpa is a reasonable
>       place to host it).

This is what I don't get. I'm sometimes a little slower than the other kids 
(it's true - I used to miss the first half of recess), so can you please 
explain why having a client have:

#define AREG_ROOT          "areg-iris.arpa"
#define AREG_ROOT_METHOD   "NAPTR"

Is somehow easier to update over time having clients use:

#define AREG_ROOT          "iris.nro.net"
#define AREG_ROOT_METHOD   "S-NAPTR"

Or indeed easier than:

#define AREG_ROOT          "iris.nro.net"
#define AREG_ROOT_METHOD   "A"

As I see it, the only fundamental difference is that the IAB controls ARPA 
and the NRO controls NRO.NET, which from a technology point is no difference 
at all.

Please, what am I missing?!?! :(

-- 
Shane Kerr
RIPE NCC

---

From: Andrei Robachevsky <[email-masked]>
Date: Mon, 07 Mar 2005 16:59:11 +0100

Shane Kerr wrote:

> This is what I don't get. I'm sometimes a little slower than the other 
> kids (it's true - I used to miss the first half of recess), so can you 
> please explain why having a client have:
> 
> As I see it, the only fundamental difference is that the IAB controls 
> ARPA and the NRO controls NRO.NET, which from a technology point is no 
> difference at all.
> 

I think what makes me uncomfortable is embedding specific names or 
locations in general. In that respect indirect reference is just a 
little bit better that a direct one.

Can IANA and IANA considerations section help us here?

Andrei

---

From: George Michaelson <[email-masked]>
Date: Mon, 7 Mar 2005 10:18:04 -0600

>Can IANA and IANA considerations section help us here?
 
I think this is a reasonable question. I think we should strongly consider
putting this into an IANA/considerations issue, with an expectation the
IANA registry defines the entrypoint outside of these documents, and avoid
overloading spec documents with operational practices.

-George

-- 
George Michaelson       |  APNIC                 
Email: [email-masked]    |  PO Box 2131 Milton    
Phone: +61 7 3858 3150  |  QLD 4064 Australia    
  Fax: +61 7 3858 3199  |  http://www.apnic.net

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Tue, 8 Mar 2005 09:46:52 +0100

Shane,

> This is what I don't get. I'm sometimes a little slower than the other 
kids
> explain why having a client have:

IIGIR that is the very point of S-NAPTR, as Leslie said. S-NAPTR delivers 
two degrees of freedom: you fix the name of the service, and you can 
manipulate the service protocol (areg, whois, ...) and the location 
(host/port/priority/...) of an instance of a protocol server.

If we fix the location (i.e. "iris.nro.net"), then you've lost a big part 
of this freedom (yes, though you can still manipulate the A-Records of the 
location).

Best,
Marcos