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

From: "Dave Thaler" <[email-masked]>
Date: Thu, 9 Aug 2001 06:24:54 -0700

I disagree as well that there's a "majority" (or any sort of consensus) for A,
and it would in fact be my last choice of the four possibilities (counting implementation 
dependent).
 
I would prefer (in order):
C (flexible)
implementation dependent (what you suggest below)
B (strict)
A (flat)
 
-Dave

	-----Original Message----- 
	From: JINMEI Tatuya / 神明達哉 [mailto:[email-masked]] 
	Sent: Wed 08/08/2001 15:15 
	To: Robert Elz 
	Cc: [email-masked] 
	Subject: Re: Wrap up and last call: sin6_scope_id semantics 

	>>>>> On Thu, 09 Aug 2001 00:36:16 +0700,
	>>>>> Robert Elz <[email-masked]> said:
	
	>   | The majority is those who support A.
	
	> Actually, it wasn't, you had 4 supporting A, and 4 not supporting A.
	> A might have more support than either of the others, but not majority
	> support...
	
	You could say that, but I believe B and C should be separate.
	Actually,
	
	- Francis (who supports B) said he said he'd rather prefer A to C,
	  because C would introduce too much complexity.
	- Markku (or Dave? anyway who supports C) said he'd rather prefer A to
	  B, because we'd not see much benefit to separate the field
	  (i.e. 4+28) if we get rid of the flexibility that C provided.
	
	> I'm not sure I know or care enough about this to offer an opinion, but
	> I would like to ask a question ....
	
	>   | A) Using the "flat 32", the zone indices are as follows:
	>   |
	>   |   ID(intf1) = 1, ID(intf2) = 2, ..., ID(intf5) = 5
	>   |   ID(link1) = 1, ID(link2) = 2, ..., ID(link4) = 4
	>   |   ID(site1) = 1, ID(site2) = 2
	
	> Would another variation of that approach result in ID(site2) == 5
	> and ID(link4) == 5 ?
	
	Yes, it would.
	
	> That is to avoid the problem where "1" means one place in one context
	> and somewhere totally different in another.  Instead "2" in link context
	> would mean a particular link, in site context it would mean a collection
	> of links, but the link "2" would certainly be one of them.
	
	> With things defined that way, I think A would suit me just fine
	> (not that I'd count my opinion on this issue), without it, I think
	> I'd prefer B or C, just so the ambiguity is avoided.
	
	Hmm, I guess it would be okay to leave it as implementation dependent,
	that is, "we adopt the flat 32 model, but the actual mapping from a
	particular zone to a zone ID (sin6_scope_id) is implementation
	dependent."  Does this make sense to you?
	
	                                        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]
	--------------------------------------------------------------------

--------------------------------------------------------------------
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: Atsushi Onoe <[email-masked]>
Date: Thu, 16 Aug 2001 23:43:56 +0900 (JST)

<[email-masked]>
References:
	<[email-masked]>
X-Mailer: Cue version 0.6 (010815-1037/onoe)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii

> If B were the standard interoperable thing, but C would also be legal
> behavior (since it's a superset of B behavior) for an implementation,
> that
> would be fine by me.

So perhaps you will be against this 'must'?

| - when a zone ID is used with an address (typically in the sockaddr_in6
|   structure), the scope type of the ID must be equal to the scope type
|   of the address.

I won't oppose that an implementation accepts the values which don't match
the scope type, but at least it MUST NOT returns such values to applications,
IMHO.

Atsushi Onoe

---

From: "Roy Brabson" <[email-masked]>
Date: Thu, 30 Aug 2001 08:48:40 -0400

On Thursday, 08/30/2001 at 12:08 ZE9, JINMEI Tatuya / 神明達哉
<[email-masked]> wrote:
> I'd like to propose the following approach:
>
> - the scoping architecture draft only defines the numerical zone IDs
>   and their aliases for readability (like "site1")
This is fine.  I've never really objected to the aliases, I just don't find
them very useful.

> - the scoping architecture draft does NOT define the zone "names", but
>   mentions that implementation can use intuitive names in the textual
>   representation, and that interface names can be used as
>   interface/link/subnet zone IDs by default.
Good as well.  Maybe something like an implementation MAY choose to display
the names used in configuring the zones in the textual representation.  I
just don't want anyone to read the text and think this type of behavior is
somehow precluded.

> - write a separate informational document, which talks about the API
>   of the scoping issues, including possible representation of names,
>   and mapping of numerical identifiers and names.
Yes, I think keeping the API discussion out of the standards track RFC
makes sense.  And I like having the informational RFC for the API issues as
well.

Roy Brabson