Subject: RE: draft-ietf-ipngwg-scopedaddr-format-00.txt

From: Brian Zill <[email-masked]>
Date: Tue, 9 Nov 1999 12:28:06 -0800

After discussing this issue with Jim Bound in the hallway, he's convinced me
(in his usual totally rational, non-emotional way :-) that some people will
be very upset if we change the API in a non-backwards compatible way.  While
those of us who haven't yet carved our APIs in stone may not care, it would
be a bad thing to "reward" the early deployers by changing the API out from
under them.  Therefore, I'm now leaning toward "option #2" from my previous
mail, which is to use flags like Sam Manthorpe suggested or a parallel set
of APIs that are scope aware.

Since getipnodebyname already takes a flag field, making this backwards
compatible is straightforward (flag would have to default to no scope_id).
inet_ntop and inet_pton are more problematic.  For them, I'm leaning toward
defining an equivalent set that work on sockaddrs rather than in?_addrs.
While getipnodebyaddr doesn't take a flag field, it might not be a problem
(discussed below).  Another option is to just recommend the use of
getaddrinfo (and duck the bricks Jim will throw).

Another thing I've noticed in this discussion is some confusion over the
definition/use of scope_ids.  While this has been discussed a lot at various
meetings to what I perceived as a consensus, I don't think it has been
written down anywhere.

What I think the definition of a scope_id is: A scope_id is an *instance* of
a scope (it's not a scope -- a scope is link-local, site-local, global,
interplanetary, whatever).  By an instance, I mean it is an identifier
denoting a specific link (for link-local addresses), a specific site (for
site-local addresses), a specific planet (for global addresses), etc.  And
it is node-specific -- that is, it can have different values denoting the
same thing on different nodes (at least for link-local and site-local, we
seem to be treating zero as the universal scope_id value for Earth when
we're dealing with global addresses :-).

Because of the node-specific property of scope_ids, I think the idea
(floated from time to time) of putting scope_id information into the DNS, is
very problematic and shouldn't be allowed/persued.  Therefore, I don't think
we need to care about getipnodebyaddr not being scope-aware.  We do care for
getipnodebyname since we'd like it to be able to parse numeric address
strings with a scope_id in some format (which is what we started out
discussing in this thread before taking off on this tangent).

--Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked] (Sam Manthorpe)
Date: Tue, 9 Nov 1999 13:52:00 -0800 (PST)

> we're dealing with global addresses :-).

Yes, this is also my understanding of scope-id, very nicely explained
again.

> very problematic and shouldn't be allowed/persued.  

I agree that scope_id information should not be _in_ the DNS, _but_ it
should be added by the resolver.  Before looking at DNS, what about
<draft-ietf-ipngwg-icmp-name-lookups-05.txt> based name resolution?
I would suppose that for link-local addresses name resolution should
proceed as follows:

    1	send name lookup ICMP packets on each attached link

    2	interface on which the reply is received determines the
	scope-id to be associated with the link-local address

    3	libc name resolution function (e.g. getaddrinfo) returns
	this scope-id to application along with the link-local
	address.

I would like getipnodebyname() to be able to do this too.  As for
DNS, I belive that the same technique can be applied; i.e. the 
scope-id to be associated with a link-local or site-local address
is that of the interface through which the DNS server was reached.

> discussing in this thread before taking off on this tangent).

Yes, this too.

Cheers,
Sam.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sam Manthorpe, SGI.  tel: (650)933-2856 fax: (650)932-2856  [email-masked]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Steve Deering <[email-masked]>
Date: Tue, 9 Nov 1999 14:42:23 -0800

At 12:28 PM -0800 11/9/99, Brian Zill wrote:
>interplanetary, whatever).

At the Tokyo interim WG meeting, I suggested the use of the term "zone"
for a scope instance, based on the precedent set by IPv6 scoped multicast
addressing (e.g., the in the MZAP protocol).  If that suggestion were
adopted, the "scope_id" would be more accurately named "zone_id".

Steve

---

From: Jim Bound <[email-masked]>
Date: Tue, 09 Nov 1999 17:59:16 -0500

I think zone has to much ringing of DNS syntax and will cause confusion
too.

perimeter_id seems more appropriate...

but is it worth changing the rfc 2553 name space?

/jim

---

From: Steve Deering <[email-masked]>
Date: Tue, 9 Nov 1999 15:09:19 -0800

>I think zone has to much ringing of DNS syntax and will cause confusion

That's a good point.

>perimeter_id seems more appropriate...

Perhaps, though it's an identifier for the area inside the perimeter,
not the perimeter itself.

>but is it worth changing the rfc 2553 name space?

Maybe.

Steve

---

From: Robert Honore <[email-masked]>
Date: Wed, 10 Nov 1999 07:25:39 -0400

Dear Steve and Jim,

Perhaps the word "Region" is the one you seek?

Yours sincerely,
Robert Honore.