Scope of an Identifier? (Re: Fwd: Minutes / Notes)

[Pekka Nikander <pekka.nikander@nomadiclab.com>]

Firstly, IMHO it is very good that the WG seems to be converging
to the notion that we basically have to make the id/loc separation.
Now, if we do make that, Christian is asking a couple of very
good questions.  I also think that we already know some possible
good answers to these questions.  It is then another matter whether
we want to go with the better answers or be happy with some lesser
ones.

Christian Huitema wrote:
> Another quite important design choice is the scope of the identifier.
>  ... The scope of an identifier system, by definition, has to be 
> wider [than the scope of an IP address]. Yet, we don't really know
> how wide. Is it a host? A host is in fact a pretty loose concept.
> Consider clusters on one hand, multi-user systems on the other. Would
> you have an identifier per node in the cluster, or one per user in a
> multi-user system? What about process mobility? If you are running a
> distributed application, do you identifiy the application, an
> instance of it on a node, or the node that supports this instance?
If we can design our architecture and solution in such a way that
is remains basically an *operational* choice to decide the scope
of an identifier, then I think we have reached a good solution.
This seems to reduce to a situation where one can assign an
identifier to any process group.  Then it remains a matter internal
to that process group and the underlying hosts to arrange
clustering, process group migration, etc.

In practise, we can start by saying that an identifier identifies
a host, but engineer the solution in such a way that the connection
between the identifier and the host is a relatively loose one,
allowing more flexibility in the future.

> Yet another design choice is the life-time of the identifier. There 
> are periodic proposals of an identifier baked in a device, e.g. a 
> unique ID for a 3G phone. But there are also identifiers based on 
> sessions, e.g. web cookies. And there are very different privacy and 
> reliability implications between the two variations.
IMHO, we need identifiers that have different lifetime and different
privacy properties.  We want to have identifiers that are short
lived and anonymous.  We need identifiers that have a longer lifetime,
act as pseudonyms, and may be assocated with some local credentials.
Finally, we probably also need long lived identifiers, associated
with credentials with more or less global scope.

The identifier name space should accomodate all these.  Furthermore,
it MUST NOT make any syntactical distinction between these three
of these.  That is, just by looking at an identifier it MUST BE
impossible to tell its lifetime and privacy status.  (Why?  Think
about collecting and correlating identifiers vs. privacy).

--Pekka Nikander