>>>>> On Thu, 09 Aug 2001 00:36:16 +0700, 
>>>>> Robert Elz <[EMAIL PROTECTED]> 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 PROTECTED]
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------

Reply via email to