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