It's my turn to catch up :-)
Christian Vogt allegedly wrote on 06/26/2009 1:24 PM:
> But are all these identifier types essential elements of an Internet
> architecture? I would argue most of them are not -- they are useful
> within the scope of a particular Internet application, but they are not
> essential for the Internet per se to function. In fact, I see only two
> purposes for which the Internet architecture must have identifiers:
>
> (1) service identification, identifying a piece of communication
> software that responds to incoming contact establishment attempts
>
> (2) session identification, identifying the protocol state corresponding
> to a particular session after contact establishment
First, let's avoid thinking of the Internet in client/server concepts.
"Service" has connotations of a destination that is frequently accessed,
well-known, and perhaps globally addressed. We need to leave room for
simple personal communications. Let's just talk about destinations.
I repeat the litany of five identifier functions :-) ...
* for access, to use a visited network at all.
* for initially finding something you want to talk to. Examples would
be domain names and SIP URIs. These might correspond to your
"service identification".
* for initial contact, in order to establish sessions. These include
authentication and authorization identifiers.
* for session control: initial authentication and association of
locators with sessions, as well as re-authentication when locators
change.
* for referrals, whereby one endpoint tells another about yet a third.
Which of these are "essential for the Internet to function"? I don't
see how we could get rid of any of access, search, authentication,
session control and referral. However,
* You might be able to use the same identifiers for different
functions. That is, you may be able to use the same identifier as
input to multiple identification functions.
* Also, a single identification function can take multiple
identifiers.
* Finally, different layers will repeat the same functions. For
example, you may have multiple authentication functions, or
"session" control at multiple layers.
We haven't resolved the practical aspects of what might be the most
convenient way to reduce identifier count because we don't have enough
experience, so we're projecting and speculating.
Toni Stoev allegedly wrote on 06/26/2009 8:29 PM:
> Node identification provides for efficient handling of node
> multihoming, possibly dynamic, and for stable mapping of human
> readable names.
If I move a session from one device to another, or from one interface to
another, a node identifier is not enough to support session continuity.
If I have a way to identify sessions that does support session
continuity, then a node identifier is not necessary in addition for that
purpose. As others have said, one might want a node identifier for
management, but what we really want is a way to talk to a management
entity that claims to be responsible for the node.
Joel M. Halpern allegedly wrote on 07/03/2009 10:36 PM:
> The reason this (naming the set of locators that lead to the same
> entity) leads to a stack ID (or node, host, something) is that I want
> that collective property available before I start communicating.
> Referrals are the easy case. I am trying to refer someone to a
> specific entity. They do not have a session with that entity. So a
> session ID is clearly totally useless for a referral.
http://tools.ietf.org/html/draft-carpenter-behave-referral-object-00
(which we should get back to, Joel).
> I believe that similar constraints apply at the time of initial
> communication establishment, in that there is a semantic difference
> between using multiple locators for a target to establish
> communication and trying to establish communicaiton with multiple
> "equivalent but distinct" targets. I consider it helpful to
> udnerstand that distinction.
Of course there is but I don't see the point you're trying to make. If
you address a letter to {my country, my town, my street, my house, me},
you are using multiple locators for a target, but are you trying to
establish communication with "equivalent but distinct" targets?
Identifiers do not all have to name the endpoints of communication; they
can also name the scope in which other (associated) identifiers are to
be interpreted.
I'm not going to say much more about whether we want a "stack ID" or
whether doing the same thing with a set of identifiers with multiple
purposes is better. We can leave that to the market.
Stopping here for now.
... Scott
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
