While there is an architectural argument that we should have nothing
more than is absolutely necessary in the architecture, taken too far
this view encourages entangling components and misusing information.
(~We could use that piece over there, instead of having the right piece
with the right meaning, sicne it would save a part.~)
While it is sometimes (particularly for management purposes) useful to
be able to name a physical node, when I look at this the piece I tend to
want to name is the communicating entity. Having a name for this thing
is useful for session establishment, referral, and security purposes.
This is distinct from, but may be a component of, the identifier used
for a specific communication session. (Some folks like to simply mint
session IDs in a way that is sufficiently unique, some like to
implicitly tie session IDs to the entity IDs, and some folks use designs
where the tie-in is explicit.)
The reason I started with the comment about necessity is taht some folks
argue that a communicating entity ID is not necessary as it can be
represented by the collected network layer locators. (And that once one
has established communication using any locators, the protocol can
exchange the rest.) This is true as far as it goes.
It seems to me however that it is useful to be able to explicitly tell
which locators go with the same communicating entity, as distinct from
the larger set of locators which might go with the same service
(whatever that means.)
To save myself typing, and because it tends to be similar to what other
folks have meant when they use the term, I tend to prefer to think of
this ID as a stack-ID. And yes, I know that is vague. Exactly what is
the stack. Does it include TCP, UDP, SCTP, and DCCP, or is it just one
of them? Etc.
I have considered writing a draft trying to clarify this, but the
question of identifiers has not seemed to be the actual top problem, so
I have not seen enough reason to do so.
Yours,
Joel
[email protected] wrote:
-----Original Message-----
From: Christian Vogt [mailto:[email protected]]
Sent: 30 June 2009 20:51
To: Krug,AL,Louise,CXR9 R
Cc: [email protected]; [email protected]
Subject: Re: [rrg] Next topic: properties of identifiers
Is host identification most useful for fault finding?
Louise -
Absolutely. In fact, there is a richness of purposes for
which one may need identifiers. What I claim is that most of
those purposes are application-specific and not essential to
an Internet architecture. For example, fault finding is the
purpose of a debugging application.
An Internet architecture must be versatile enough to enable
applications to use their own identifiers. But to do this,
the Internet architecture itself must incorporate identifiers
for only two purposes: to identify a peer service for
contact establishment, and to identify a session instantiated
during contact establishment. On top of that, applications
can do what they want, such as providing a means to identify
hosts for fault finding. Does this make sense?
- Christian
It makes sense in the abstract, but I am still mulling the question "if
a lot of applications would need something such as a host ID, and the
network does not provide it will we end up with a lot of different ways
of providing it, and possibly some very nasty ways (like IP addresses
got overused). I guess then you might say that you have the core
architecture and a set of extras that need to be standardised but you
should not expect them to be gloablly available?
Do you think the session need to have a globally unique identifier or
locally agreed between the endpoints during the contact establishment?
Louise
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
