Dave,
Dave Crocker wrote:
DC> In general I suggest we find some specific scenarios that require a new
DC> construct for end-point identifiers. ...
Concrete scenarios are very good indeed.
PN> On the other hand, security looks to me as a good reason for
PN> having stable end-point identifiers.
DC> and rendezvous.
DC> any reference to an object that requires use outside of an existing
DC> context.
Well, I consider an *identifier* as something that is more or
less intrisically bound to an identity and a *name* as something
that merely indicates an entity, i.e., involves indirection.
In other words, an identifier implies sameness and stability of
the identified entity, while a name does not have those connotations
to the same extent.
From this point of view, IP addresses are identifiers. However, they
are not end-point identifiers but identifiers for topological
locations within the routed network.
Now, you may be able to do rendezvous with just names, e.g.,
with domain names. And for referencing external objects, it
is often much better to use names than identifiers. Furthermore,
I find it hard to imagine situations where you want to reference
objects that are really outside of any context; IMHO there is
always some context, and names are always bound to such a context.
PN> Even facing the danger of opening yet another rat hole, in my
PN> opinion we should not have a very strict definition for end-point.
PN> ...
PN> From my point of view, an end-point may be a process, a group of
PN> processes, a host, or even a server cluster offering services as
DC> Just for fun, let's start by using the term "domain name" and try to
DC> understand why it will not suffice.
DC>
DC> domain names have been successfully used for all of the examples you
DC> give.
In my opinion, domain names are probably good for coarse grain
rendezvous and expecially object reference (e.g. URLs). They have
their problems in disconnected networks, but LLMNR / mDNS seems
to help there. On the other hand, domain names are not very good
for security. You need some external infrastructure, and unfortunately
our strawman economic analysis shows that secure DNS may be
economicly infeasibile. The cost of security is a crusial issue here.
One of the success factors of SSH has been the low deployment cost.
--Pekka Nikander