Pekka, (new subject, to define what I think is a new thread.) PN> Well, I consider an *identifier* as something that is more or PN> less intrisically bound to an identity and a *name* as something PN> that merely indicates an entity, I had not run into this distinction before. Now that you raise the point, I guess I have been thinking of identifier as an intentionally fuzzy, general term, with name being a more specific reference. Separate from discussing the merits and details of the specific distinction you draw, I think your note highlights the need to make sure we have some common terminology. I do not understand "intrinsically bound", but it sounds interesting. I am used to terminology use that derives from Shoch. A name says what a thing is, but nothing about where or how to get to it. It can be a random bit string that unique identifies the entity. Any non-randomness to the string will be relevant to administration of the string assignment, but will not provide any information about the location of the entity or how to reach it. Two entities that are topological neighbors are free to have unrelated names. Addresses contain information about location -- typically topological location. (The possibility of geographic location gets bandies about, sometimes.) Addresses are also globally unique. Routes give directions about how to reach the entity. Routes are relative to the starting point. PN> In other words, an identifier implies sameness and stability of PN> the identified entity, while a name does not have those connotations PN> to the same extent. I guess I need some examples to understand this. PN> From this point of view, IP addresses are identifiers. IP addresses have bits that are structured, semantic indicators of topological location. There is serious semantics in an IP address, not just guaranteed uniqueness. That said, an address at one layer of processing is usually a name to the next layer down. For example an email "address" divides into two names, one for the mailbox and one for the containing host. PN> However, they PN> are not end-point identifiers but identifiers for topological PN> locations within the routed network. In trying to think about mobility, I have been finding this point extremely helpful. IP addresses define a point of attachment -- a network interface -- rather than a host interface, as we are used to saying. As the host interface moves, relative to network attachments, it needs new IP addresses. Hence a mobility mechanism needs to support end-to-end exchanges that may have changing IP addresses over the life of the association. PN> Now, you may be able to do rendezvous with just names, e.g., with PN> domain names. And for referencing external objects, it is often much PN> better to use names than identifiers. I probably need to see some examples, here, to understand your point. PN> Furthermore, I find it hard to PN> imagine situations where you want to reference objects that are PN> really outside of any context; IMHO there is always some context, PN> and names are always bound to such a context. darn. you caught me in a fuzzy specification. What I meant by 'context' was an existing relationship between the two entities. When I first contact a server, there is no context. Afterwards there might be. How do I find the server that first time? Is there -- or can there be -- any difference in how I find it later? The simple example of my finding a server is the difference between using its domain name versus using its IP address (in the TCP control block or, at least, the client DNS cache. It's worth noting that client-side mobility is a very different problem from peer-to-peer mobility. Hence, something like MAST is entirely adequate when it is only the client that is moving around. The client can re-find the server the same way it originally did. With P2P, that does not work, unless each moving host updates its entry in the mechanism used to find it. So, we might consider using dynamic DNS for this, though I suspect it's not the right solution. If the mobility is rapid and frequent, the extra traffic and delay of DNS queries is likely not to be the right answer. However note that the Internet infrastructure has no problem sending consecutive packets to different places, as long as they have different IP addresses. Hence, the infrastructure can handle mobility just fine (as long as we ignore the question of forwarded packets that arrive after the recipient has moved.) PN> In my opinion, domain names are probably good for coarse grain PN> rendezvous and expecially object reference (e.g. URLs). They have PN> their problems in disconnected networks, but LLMNR / mDNS seems PN> to help there. I think the question for disconnected networks is what would work better, and why. There might be a way to have domain names satisfy them, just so we do not have to deal with multiple name spaces. PN> On the other hand, domain names are not very good PN> for security. I've been trained to prefer separating security from naming. Overloading the two gets confusing and often doesn't work very well. In any event, please clarify what security concerns you have. PN> You need some external infrastructure, and unfortunately PN> our strawman economic analysis shows that secure DNS may be PN> economicly infeasibile. huh? d/ -- Dave Crocker <mailto:dcrocker@brandenburg.com> Brandenburg InternetWorking <http://www.brandenburg.com> Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>