>>>>> On Mon, 13 Aug 2001 16:12:27 +0200,
>>>>> Francis Dupont <[EMAIL PROTECTED]> said:
>> => I believe there should be none because the stability requirement
>> should be for id names, not id values. Of course, we should recommend
>> to use always names too.
> Notice that I did *not* talk about stability across reboots.
> My issue is whether it is ok or not to have the ids change
> on a whim while the machine is *running* (e.g. due to using hotplugging to
> add or remove NICs).
> => it seems we agree to say it is *not* ok.
Of course not.
Aside from this particular issue, it seems that MIB guys also want
zone IDs that can identify particular scope types. If such usage has
reality, it would mean 4+28 (or something similar) IDs are more
suitable.
I talked with Steve (and some other guys who supported the idea A) on
this issue assuming such usage in MIBs, and we thought we could
compromise on this point, as long as we could avoid "flexibility" that
the idea C would provide.
So, the basic idea is as follows:
- take 4+28 split.
- actual mapping from zone to the 28 bit part does not matter, but it
should not change while the node is running (as discussed in this
thread)
- introduce "aliases" for numeric zone IDs to improve readability in
the textual representation. e.g. "link2" is an alias of a link ID
whose intra-link id is 2 (i.e. 0x20000002). "site4" is an alias of
a site ID whose intra-site id is 4 (i.e. 0x50000004). We now allow
fec0::1234%site4 as well as fec0::1234%1342177284 (1342177284=0x50000004)
- 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.
This should basically be the same idea as B. So I guess supporters of
B do not oppose to this (I hope not, actually). As I said above, most
of supporters of A could live with this.
Can we (especially those who support C) make a compromise on this with
this plan? Then I'll revise the textual representation in the scope
architecture draft, according to the idea.
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]
--------------------------------------------------------------------
