Re: Some Comments on ID/Loc Separation Proposals

["J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>]

    > From: 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

OK, so I guess I used a non-optimal term when I called them "properties".
Perhaps I should have called them "functionalities", or something, to
emphasize that they are things about the name that allow you to perform some
non-trivial operation with them - e.g. if it's a public key, you can
authenticate or secure things with it.


But I think the chief point I wanted to make is to get everyone to realize
that the term "identifier" was not precisely defined.

So, when one person mentions a "<foo> identifier", without specifying exactly
what set of properties/functionalities that "<foo> identifier" has, someone
else can't really understand what the first person meant.

I will suggest again that we take "identifier" to mean "name with basically
no properties/functionalities" (other than identfying the thing which it
names). To allow me to be precise hereo, I'll use the term "NF-identifier"
when I want this meaning.


    > 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.

This is a fairly fine hair to split! Yes, if a particular type of name has
some set of properties/functionalities, some class of users of that name
might decide to only use a subset of those properties/functionalities.

However, the uses clearly can't be a superset - so the full set of
properties/functionalities of a name is important, because it sets hard
bounds on what one can possibly (ever) do with it.


    >>> 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.

I think we're having a mis-communication here! Let me try this again.

Depending on exactly how one defines the term "identifier", a "locator" might
indeed be an "interface identifier". I.e. if one defines "identifier" to be
"any kind of label", then a "locator" is clearly a member of the class
"identifiers".

On the other hand, for someone who uses the term "identifier" to mean an
NF-identifier, a locator is clearly not an "interface identifier".

That's all I meant.


As to whether an "interface identifier" of the second sort is useful, well, I
don't know for sure. I think it would depend in part on the routing
architecture, and whether it had a use for names for interfaces which were
not connectivity-dependent. I've seen routing architecture that did have a
use for such names, particularly in networks of highly mobile objects.


    > 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.

First, I assuming that when you say "identifier" above, you mean some sort of
name (not necessarily an NF-identifier) for a stack/endpoint.

If so, then I am in agreement with you - that would one want to allow an
stack/endpoint to be bound to different interfaces, both over time (mobility)
and at the same time (multi-homing).

The reason it doesn't matter what kind of name you're using for the
stack/endpoint is that the important architectural concept is that you're
associating a "stack/endpoint" with an "interface" - and you're also
specifying what kinds of associations (whether one-one, one-many, or
many-one) are allowed, as well as allowing the associations to change over
time, etc

The issue of what particular names you're using for these two classes of
things comes later. So the particular kind of name we use for the
stack/endpoint is immaterial to these points in the previous paragraphs - it
could be an NF-identifier, it could be a public key, whatever.

(It also doesn't matter what kind of name we use for the interfaces, but so
far I don't think anyone has seriously proposed anything except a locator.)



Sorry for going on a bit of length about this, but my sense is that some of
the back-and-forth here is caused by use of terms for which not everyone has
the same precise definition.

There's also some lack of precision in thinking separately about the things,
and the names for them (as in the previous paragraphs).

	Noel