Subject: Re: Wrap up and last call: sin6_scope_id semantics

From: "Roy Brabson" <[email-masked]>
Date: Wed, 29 Aug 2001 10:25:34 -0400

On Wednesday, 08/29/2001 at 10:25 ZE9, JINMEI Tatuya / 神明達哉
<[email-masked]> wrote:
> > I also prefer eth0 over link12.  Using the names used to define the
zones
> > (either the default interface names or actual zone definitions) seems
to be
> > more useful than generating a somewhat arbitrary name and displaying
that.
> > How is the user supposed to correlate link12 back to the actual eth0
> > interface, anyway?  I imagine another external or display could be
used,
> > but this would seem to introduce yet another step for a user to
identify
> > the particular interface/zone in question.
>
> When we can assume one-to-one mapping between interfaces and links,
> that's true.  However, if two (or more) different interfaces belong
> to a single link, using interface names as link IDs would be rather
> confusing (we'll lose the uniqueness of the ID, or we'll have to care
> about which interface is "primary" in the link".)

True, if two interfaces are in the same link-local zone then the interface
name will not uniquely identify the zone.  But the current scoping
architecture draft indicates that configuration is required to identify
that two interfaces are in the same zone, and the name used in this
configuration can be used for display of the zone name.

> As I said in a previous message, I do not necessarily object to using
> "names" as an implementation dependent convention.  I just would like
> to stick to "link1" or "site5" in the official textual representation
> in the scoping architecture draft.

I would prefer to use the textual representation which matches what is used
in configuring the zones.  It just makes more sense to echo back what a
user placed in a configuration file instead of displaying an arbitrary
value dynamically created by a given stack.  How exactly would a user
correlate an arbitrary value such as "link1" or "site5" to the given zone
which they want to use, anyway?  This would seem to be the equivalent of
telling a user they need to "guess" the correct interface ID without
proving if_nametoindex() to perform the translation of the configured
interface name to the corresponding interface ID.

Roy Brabson

--------------------------------------------------------------------
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: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 30 Aug 2001 02:06:13 +0900

>>>>> On Wed, 29 Aug 2001 10:25:34 -0400, 
>>>>> "Roy Brabson" <[email-masked]> said:

> configuration can be used for display of the zone name.

I don't see such indication of the draft...which text of the draft do
you really mean?

> interface name to the corresponding interface ID.

I admit that "link1" is not user-friendly.  But please note that the
textual representation described in the scoping architecture draft
basically defines numerical zone IDs only, which are also
"user-unfriendly".  But the draft also allows implementations to
introduce more intuitive, more user-friendly format such as interface
names for links, assuming one-to-one mapping between interfaces and
links.

Since the notion of "names" can be different among implementations, I
don't think the architecture draft should define the details of
"names".  The problem with the 4+28 split model, however, is that
numerical identifiers would even annoy users (not just be
user-unfriendly), because we'd see IDs like "1342177281" (which is
0x50000001, i.e. a site ID of site index 1).  So, "site1" is just a
readable alias for "1342177281", which is a different kind of notion
from "names".

Again, I don't oppose to introducing "names" in each implementation.
However, I'd stick to the numerical identifiers and their aliases for
readability, as the bottom line in the scoping architecture draft.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[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]
--------------------------------------------------------------------