Re: Some Comments on ID/Loc Separation Proposals

[Erik Nordmark <Erik.Nordmark@eng.sun.com>]

> Do realize that for most people, when they speak of an "identifier" for the
> host/endpoint/stack, they are sometimes thinking of names with no properties
> - a subtly different kind of "ID" from the "interface ID" you were just
> talking about.
> 
> Of course, there are some schemes for host/endpoint/stack "identifiers" in
> which those names *do* have properties - they are public keys, or hashes of
> public keys, or DNS names, or whatever...

I guess the issues isn't whether the frobnits has a property or not,
because even your example of a random process id has the properties that they
are random and uniques, but whether this property is important; being
used for some particular purpose.
I think this is shades of grey; a random frobnits can be used as a good
hash key somewhere, which is a much *lighter* usage that the random bits
also being a hash of a public key.


>     > An interface ID makes no sense to me.
> 
> Perhaps because you, in contrast, are thinking of "ID" as "name with no
> properties"? I think you will agree that interfaces do need names of some
> sort - our familiar "locators" (i.e. an address which *only* names an
> interface, and its location).

Actually I was thinking more of "makes no sense"= isn't useful in the context
of id/loc split.
If one wants to separate out identifiers from locators for the purposes
of allowing "rehoming" presumably one would want to rehome between different
interfaces and not just between different locators assigned to the same 
interface.

>     > The concept of a stack name, where there can be one or more "stacks" on
>     > a given host, provides the right granularity to me. Each "stack" can
>     > presumbly have one or more network interfaces.
> 
> I assume also that each interface can have one or more stacks talking through
> it, right?

Right.

  Erik