Re: names, addresses, routes
Dave Crocker wrote: DC uh oh. when discussion starts including dictionary definitions, it is DC often worth stepping back and making sure that the right issue is being DC discussed. My apology. I was merely trying to be precise. Sorry for the detour. DC And that observation was only intended to be DC relevant as an indicator that we (the community) probably do not have DC sufficient commonality to our use of the terms... I see. And tend to agree. Furthermore, for me and perhaps a number of other non-natives the issues are sometimes fairly difficult since we often don't know the everyday meanings of many words. That is, at least I sometimes know a word from a very specific technical (linguistic) context and have no idea about its everday meaning and connotations. Identifier may be one such word. 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. DC Apologies, but I am still not understanding well enough, I think. ... DC DC Some mappings between strings and objects are by arbitrary assignment. DC Some have a semantic process so that the string actually can be DC analyzed. ... I completely agree. My thinking about identifiers (as names that identify) is that an identifier is a different from a mere name in the sense that an identifier does have such a semantic process associated with it. For example, consider IP addresses. They can be considered to be identifiers for topological locations. In that sense, the IP address can be analyzed and understood to act as a pointer to a certain topological location. Let me take another example, public cryptographic keys. A public key can be analysed and understood as a pointer to (the sole holder of) the corresponding private key. Thus, we can say that IP addresses are identifiers for locations and public keys are identifiers for (the holders of) private keys. 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. Let me take this the other way around. It seems to be a fairly common practise in computer science to create an identifier space, and then to make the assumption that the set of potentially identifiable entities is isomorphic with the set of identifiers. That is, you first create a set of identifiers, and then define that the world consist of a subset of the set of entities that can be named with those identifiers. This seems to be the case with IP addresses. Even though we have NAT today, we still seem to think that the set of topological locations in the Internet is the set of locations that can be given a unique globally routable IP address. The same more or less applies to public keys. If we use the set of public keys as the set of identifiers, then the set of identifiable entities consists of things that are able to hold and process corresponding private keys. PN Well, as I wrote above, I think that a name can be re-bound PN while an identifier should not be re-bindable. DC In the Internet context. what would be an example of an identifier that DC cannot be re-bound? As I wrote, identifiers *should* not be re-bindable, not that it is impossible to re-bind them. The desired property can be achieved by at least two ways: - through some administrative procedure that ensures uniqueness - by using the reverse process, as described above, i.e. by defining identity from identifiers and not vice versa. Take the public keys example above. If you define that the identity of an entity is intrinsically bound to the private key, then if you move the private key to another device, the entity and its identity move at the same time, too. DC (And let me alert you to my belief that all of them DC can be. ... In other words, all this stuff depends DC on precise -- and often arbitrary -- definitions and policy.) We seem to agree :-) --- [Moving from the definition of identifiers and identity to mobility.] --- DC I'm finding myself viewing multi-homing as a simple (ie, degenerate) DC case of mobility. Well, I tend to view multi-homing as a dual of mobility. If you are mobile, your topological presense spans several locations over time. If you are multi-homed, your topological presense spans several locations over space. 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. DC In the long term,
Re: names, addresses, routes
Dave, 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, DC I had not run into this distinction before. Now that you raise the DC point, I guess I have been thinking of identifier as an intentionally DC fuzzy, general term, with name being a more specific reference. Merriam-Webster on-line defines as follows: identifier:one that identifies identify (1b): to conceive as united identify (2a): to establish the identity identity (1b): sameness in all that constitutes the objective reality of a thing Etymology: probably from Latin identidem repeatedly, contraction of idem et idem, literally, same and same My perhaps flawed understanding is that at least some epistemological texts use the term identity to denote the stable and distinguishable existence of entities. Respectively, identify is used to denote the process of establishing the previously learned and recorded identity of an entity, and identifier is used for such names that can be used to unambigously denote the identity of entities that can be identified. [My apologies if the text above is hard to parse, but it starts to be late here, and English *is* a foreign language to me.] DC I do not understand intrinsically bound, but it sounds interesting. Well, in my thinking a specific identifier is only able to denote a specific entity. That is, the relationship between an identifier and the corresponding identity should be a function, i.e., there must not be any identifiers that denote more than one entities. Typically the relationship is (or should be) bijective. DC I am used to terminology use that derives from Shoch I have no difficulty with your terminology, perhaps other than that I sometimes use the term name in a perhaps more generic sense. Furthermore, I think that a name always requires some name space where the name is defined. Most of the existing name spaces are local, or bound to a restricted context, while some are global, or usable in some fairly generic and well understood context. When using the more generic sense of the term, a name can be considered to be *bound* to an entity. Furthermore, usually names can be re-bound. Hence, only the triple context, name, bindings identifies the entity. (Alternatively, the bindings can be considered to be a part of the context.) Hence, a single name can denote different entities depending on the context (and bindings). The same applies to identifiers, of course, since I consider the category of identifier sets to be a subcategory of the category of name sets. There is one exception, though. It should not be possible to re-bind identifiers. That is, if an identifier has been created to denote a specific entity, the same identifier should not be used to denote any other entity at any other point of time. 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. Well, as I wrote above, I think that a name can be re-bound while an identifier should not be re-bindable. Consequently, using an identifier implies that the referred entity remains the same (as long as the identifier is valid) while a name does not necessarily have this property. On the other hand, we have to remember that sameness (i.e. identity) is a semantic property, and depends on the (overall, epistemological) context. PN However, [IP addresses] PN are not end-point identifiers but identifiers for topological PN locations within the routed network. DC In trying to think about mobility, I have been finding this point DC extremely helpful. IP addresses define a point of attachment -- a DC network interface -- rather than a host interface, as we are used to DC saying. As the host interface moves, relative to network attachments, it DC needs new IP addresses. Very true. We also have to remember the reason for this, that is, the scalability limitations of the current routing technology. In a micro-mobility solution, it may make sense to use IP addresses more like topology-unrelated names, and record a route for each address separately. For example, consider Cellular IP. 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. I concur. Furthermore, not only (macro)mobility mechanisms but also multi-address multi-homing mechanisms. 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. DC DC I probably need to see some examples, here, to understand your point. Rendezvous is needed for two purposes: - to allow initial connections - to resolve the loss of working addresses caused by simultaneous movement
Re: names, addresses, routes
On woensdag, sep 3, 2003, at 17:33 Europe/Amsterdam, Dave Crocker wrote: 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. Funny, I would assume the opposite. I'm sure there are truckloads of people who have the name John Smith in their passport (although I have no idea what parents called Smith are thinking when they name their poor offspring John), but unless there is a serious screwup somewhere, each passport uniquely identifies the bearer, traditionally using such distinguishing properties such as date and place of birth, height, hair and eye color and so on. I assume that these days everyone has their country's take on the social security number in there too. When we translate this to IP, we notice that there are indeed many systems with identical canonical names, but the domain name system comes to the rescue and provides us with a naming hierarchy that makes it possible to turn locally used canonical names into globally unique names. However, it's important to note that an FQDN often isn't the real name of that which is referred to, but rather a compromise between the properties that make for good names in the real world and on the net, and, of course, availability of the desired name. I don't think we have any real identifiers in IP. If there is something you want to identify, it's usually possible to find some handle to do this. A host can be identified by its fully qualified domain name or its attachment to the network, for lack of a property that really identifies a host, if something is even possible. (Think about it: which part constitutes the essence of a host, the part that you can't take away without changing its identity?) But all of this is subject to change. So we should probably be pragmatic and use existing identifying properties if they are usable, or create new ones where necessary. It seems silly to identify a host by the mathematical property of the contents of a small file on the file system, but it works very well for SSH. The same thing for the highest or lowest IP address that a box has, but BGP and OSPF seem to thrive on it. FQDNs and IP addresses make more sense but lack a property that is sometimes important: they identify something, but don't don't bring enough information about the nature of what they identify with them. Does a FQDN point to a host or a service? Does an IP address point to a point of attachment or a host? Usually we don't care, but sometimes we do. 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. Everything is relative to a starting point. Globally unique just means we agree on the starting point. PN In other words, an identifier implies sameness and stability of PN the identified entity, Obviously the stability of the identifier is limited by that of the entity being identified. And an identifier is what you make it. PN while a name does not have those connotations to the same extent. Yes, names can change, but that doesn't disqualify them as identifiers automatically. PN From this point of view, IP addresses are identifiers. So what do they identify for what purpose? I have no trouble identifying my webserver by its IP address, which hasn't changed in three years. Not so much with my laptop, as its address changes several times a day. PN However, they PN are not end-point identifiers but identifiers for topological PN locations within the routed network. In other words, addresses are addresses. 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. Do they? What is the point of attachment? The subnet or the individual address? I don't think it can be the latter (within this context) as the interface brings as much to the table as the network in this case, in IPv6 at least. (64 bit prefix learned from a router + EUI-64. Guess what the I in EUI stands for, BTW.) 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. Very good point.
Re: names, addresses, routes
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:[EMAIL PROTECTED] Brandenburg InternetWorking http://www.brandenburg.com Sunnyvale, CA USA tel:+1.408.246.8253, fax:+1.866.358.5301
Re: names, addresses, routes
Dave; This being a technical discussion, we had better have some useful, technical definitions. Technical definitions? On the problems, yes. On the terminology, no. Then we can switch to having a debate about problems and solutions. It is a useful approach to continue the debate forever. However, to solve the problem, anyone proposing a solution may use any terminology, as long as it is clearly defined. There is technical history to the terms at issue, here. However they suffer different definitions in different technical discussions. Different technology needs different definitions. We really suffer, if you try to unify them. Masataka Ohta
