> That is, pick the scope identifier of a lower level object that is within
> the higher level object as the identifier for that object.
>
> 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.
I don't know if there is a requirement for the stability of ids
that has bearing on this suggestion.
For instance, when intf #2 is removed from the node while running,
then applications explicitly using intf #2 would clearly need
to handle the change to the configuration.
But your constraint seem to imply that the ID(link2) would now need to
change from 2 to be the same as the ID for some other interface in that link.
That would force applications using link ids to handle the reconfiguration
even though the node is still attached to the same set of sites - it is merely
using different interfaces to attach to the links.
I guess one could handle this type of reconfiguration by
- never reusing the IDs at any scope for new stuff, and
- somehow keeping the historic bindings around.
That way ID(link2) = 2 even though interface #2 is gone.
Erik
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
