Pekka, PN> Merriam-Webster on-line defines as follows: uh oh. when discussion starts including dictionary definitions, it is often worth stepping back and making sure that the right issue is being discussed. I was not criticising your usage, but rather noting that it was different from mine. And that observation was only intended to be relevant as an indicator that we (the community) probably do not have sufficient commonality to our use of the terms, for this line of discussion. This being a technical discussion, we had better have some useful, technical definitions. Then we can switch to having a debate about problems and solutions. There is technical history to the terms at issue, here. However they suffer different definitions in different technical discussions. That's bad, at least until we all agree on a single set of definitions. DC>> I do not understand "intrinsically bound", but it sounds interesting. PN> Well, in my thinking a specific identifier is only able PN> to denote a specific entity. That is, the relationship PN> between an identifier and the corresponding identity should PN> be a function, i.e., there must not be any identifiers PN> that denote more than one entities. Typically the PN> relationship is (or should be) bijective. Apologies, but I am still not understanding well enough, I think. By way of seeing whether I am understanding at all: Some mappings between strings and objects are by arbitrary assignment. Some have a "semantic" process so that the string actually can be analyzed. Calling a computer "aland" does not really tell you anything about it, nevermind also not telling you where it is. Calling it "aland.bbn.com" at least tells you something about the administrative agency that assigned the name. (It still does not tell you anything about where it is, even though you might think it does.) Also, aland is likely not to have a unique, whereas aland.bbn.com is required to be unique. (The question of uniqueness depends on context. For most computer-related assignment processes, uniqueness is required.) 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. DC>> I guess I need some examples to understand this. PN> Well, as I wrote above, I think that a name can be re-bound PN> while an identifier should not be re-bindable. In the Internet context. what would be an example of an identifier that cannot be re-bound? (And let me alert you to my belief that all of them can be. So when you provide your example, please anticipate that I will be likely to cite examples that show the non-rebinding feature is a matter of policy, or otherwise itself is "re-bindable"... In other words, all this stuff depends on precise -- and often arbitrary -- definitions and policy.) PN> In a PN> micro-mobility solution, it may make sense to use IP addresses more PN> like topology-unrelated names, and record a route for each address PN> separately. right. as you noted later in your reply, whenever we talk about mobility we need to be careful to specify scope of possible change and rate of possible change. extremes seem to demand very different solutions. DC>> Hence a mobility mechanism needs to support end-to-end exchanges that DC>> may have changing IP addresses over the life of the association. PN> I concur. Furthermore, not only (macro)mobility mechanisms but PN> also multi-address multi-homing mechanisms. I'm finding myself viewing multi-homing as a simple (ie, degenerate) case of mobility. 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. PN> Rendezvous is needed for two purposes: PN> - to allow initial connections PN> - to resolve the loss of working addresses caused by PN> simultaneous movement ack. PN> As you write, the difference between client-side mobilty and P2P PN> mobility lies in rendezvous. On the other hand, we also have to PN> remember that more and more servers are becoming mobile, in some way PN> or another (re-hosting, network re-numbering, etc). Hence, I would PN> not consider these two types of mobility that different. In the long term, no. but it's worth considering a simpler solution, for the simpler case, if a) we think there will be significant benefit, and b) deferring the more difficult part does not make it harder or less likely to be solved. The mobile-client/stable-server example requires no new rendezvous mechanism and I think it covers a very, very large portion of current mobility needs. And I think that the rendezvous function needed for mutual mobility can be solved independently. So there is no real disadvantage to deferring it from the "addressing" problem. PN> No problem here. On the other hand, if we had proper and secure PN> identifiers, packet forwarding would not be an architectural PN> problem, either. we probably disagree. packet forwarding requires creating additional infrastructure, as we have been seeing for the considerable number of years of effort for the mobile ip work. that's another reason for carving off forwarding to be separate from higher-level (non-infrastructure) mobility support. At that point, forwarding becomes an optimization, rather than a necessity. PN>> On the other hand, domain names are not very good PN>> for security. DC>> I've been trained to prefer separating security from naming. DC>> Overloading the two gets confusing and often doesn't work very well. PN> With all respect, IMHO separating naming and security is a PN> serious mistake. All security is based on identifiability. PN> If you cannot securely identify you peers, you can't do much. I didn't mean that security wasn't important. I mean that separating the security mechanism from the name administration (and, therefore, the "meaning" of the name) is usually better. Clearly, the ability to hijack a name can be a very serious danger. DC>> In any event, please clarify what security concerns you have. PN> Well, I am mostly concerned secure identifiability. Is that PN> clear enough, or should I pursue the issue more? a bit more, please. remember that we are trying to understand why end-point identifiers are required, or at least what they are required for. i'm not seeing how security is a serious issue for that goal. PN> For now, it suffices to PN> notice that the immediate incentives for people to start PN> using decure DNS are fairly slim, at least compared to the PN> efford required. Alas, the IETF has an essentially unbroken track record of failing to gain large-scale use for any security technology created in the IETF. >> I am used to terminology use that derives from Shoch ASUS> Shoch convention of "names, addresses, routes" was ASUS> found to be ambigous in many contexts. Please refer ASUS> RFC 1498 - where Saltzer points out some of the ASUS> problems with shoch terminology. That's why I said "derived". 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>