Subject: RE: [Crisp] Working Group Last Call on AREG docs

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 18 Feb 2005 08:17:31 -0500

> >> For the document: I think the idea was that, we needed
> >> something simple
> >> to start with, and when have more experience with referral 
> mechanism,
> >> we can come up with a refined document.
> >
> > One of the issues with this approach is that the early "simple"
> > implementations tend to be very difficult to dislodge once 
> they've been
> > deployed.
> 
> And ones that are overly complex tend to never be deployed.
> 
> We have been looking at this for sometime now and have not found 
> anything more palatable.

You made quite a leap from "simple" to "overly complex".  I won't
disagree with your assessment, but it only makes sense if the only
options available are "simple" and "overly complex".

Could you help me understand why anything other than a hard-wired server
name falls into the category of "overly complex"?  There's no text in
the document to describe the situation as far as I can tell.  I didn't
see anything other than this:

"The client SHOULD start every query from the IRIS server iris.nro.net
and follow the referrals to find the authoritative server to actually
query."

Justification would be helpful.  Given the very complete description of
referrals in other IRIS documents, the lack of text explaining why a
referral won't work here is somewhat mystifying to me.

-Scott-

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

---

From: Shane Kerr <[email-masked]>
Date: Fri, 18 Feb 2005 15:29:36 +0100

> referral won't work here is somewhat mystifying to me.

I don't understand. A referral from where? I'm not trying to be sarcastic or 
anything, but the only option I see other than telling coders where to start 
their referral process is not to tell them anything.

Perhaps:

"Users SHOULD use http://www.google.com/ to search for an appropriate web 
page with information about what IRIS server to configure for AREG server 
location."

Okay, maybe I'm being a little sarcastic now. ;)

-- 
Shane Kerr
RIPE NCC

---

From: Andrew Newton <[email-masked]>
Date: Fri, 18 Feb 2005 10:04:30 -0500

> options available are "simple" and "overly complex".

Sorry.  One day I will learn not to write email before my first morning 
coffee.

> see anything other than this:

First, I agree that it should be a configurable default, not 
hard-wired.  I believe this is almost what Ted was saying (he just said 
"configurable", I say "configurable default").

> referral won't work here is somewhat mystifying to me.

First, the well-known top still uses referrals (its not a centralized 
DB).  But what you are suggesting is a highly, coordinated referral 
mesh, which to me seems like overkill at the moment.  Additionally, it 
still does not solve the exact problem of "where do I start?".  Having 
software implementors and users assume an entry point seems to be the 
same problem only spread out over a larger number of nodes.

-andy

---

From: Engin Gunduz <[email-masked]>
Date: Fri, 18 Feb 2005 16:06:31 +0100

> referral won't work here is somewhat mystifying to me.

The document does not say referral will not work.
Referral _will_ work. The problem is to figure out where to start from.

For DREG, the solution is to find the starting point from DNS records.
This is possible because there is a natural link between domain registration
data and DNS data.

Using DNS is problematic for AREG as there is no trivial link between
DNS data and address registration.  Yes, there is reverse DNS tree but
it is not trivial to find the starting point of referral in the
reverse DNS.  And reverse DNS can be useful only for IP address registration
data. For autonomous system numbers, there is nothing in the DNS
at all.

-engin

-- 
Engin Gunduz
RIPE NCC Software Engineering Department

---

From: Ted Hardie <[email-masked]>
Date: Fri, 18 Feb 2005 08:37:41 -0800

At 10:04 AM -0500 2/18/05, Andrew Newton wrote:
>First, the well-known top still uses referrals (its not a 
>centralized DB).  But what you are suggesting is a highly, 
>coordinated referral mesh, which to me seems like overkill at the 
>moment.  Additionally, it still does not solve the exact problem of 
>"where do I start?".  Having software implementors and users assume 
>an entry point seems to be the same problem only spread out over a 
>larger number of nodes.

But I'm not sure a highly coordinated mesh is the only other choice. 
If a client
starts any place and asks for something that is not known locally, that place
can always give a referral to a well-known "top"; if they have other 
data, great, but
if not things aren't lost.   That means the number of places the 
"top" has to be
updated goes from "every client" to "every referrer" when a change is needed.
And the client can *still* be pointed at the top if the person doing the
configuration prefers it that way.

I think there will be a number of users who are sufficiently focused on
one region and task that they would be able to point their clients at
that RIR's IRIS server and go on their merry way.  I have not idea, though,
whether that number is small, some, lots, most, or almost all.  Any data
that we can bring to bear on that point?
			regards,
				Ted