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 thingEtymology: 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
Making an initial connection does not require identifiability (in the sense of sameness), and indeed does not imply it unless the parties can use identity authentication. Resolving the new location of a party after loss of working addresses can be based on a mere name of the party; the name does not need to be an identifier. Upon reconnection, the parties can authenticate the identity of each other even without stable identifiers, as you have even shown yourself.
PN> [referencing objects outside of any context]
DC> What I meant by 'context' was an existing relationship between the two DC> entities. When I first contact a server, there is no context. DC> Afterwards there might be. How do I find the server that first time? DC> Is there -- or can there be -- any difference in how I find it later? DC> DC> The simple example of my finding a server is the difference between DC> using its domain name versus using its IP address (in the TCP control DC> block or, at least, the client DNS cache.
Well, when you learn the domain name of the server, you already enter a relation with the server. This relation may be a weak one, but IMHO it creates a (communication) context, as you define it. Learning the IP address of the server then creates another, related context. (I would call your definition for context as a communication context, while my definition above could be called a naming context.)
From the client point of view, there is no intrinsic difference between these relationships. For the client, both the domain name and the IP address act as names, referring to the server in their respective (naming) contexts.
The difference lies in the stability of the names. In a typical case, the domain name may be more stable, as it better identifies the server at the level of application semantics.
DC> It's worth noting that client-side mobility is a very different problem DC> from peer-to-peer mobility. Hence, something like MAST is entirely DC> adequate when it is only the client that is moving around. The client DC> can re-find the server the same way it originally did. With P2P, that DC> does not work, unless each moving host updates its entry in the DC> mechanism used to find it. So, we might consider using dynamic DNS for DC> this, though I suspect it's not the right solution.
As you write, the difference between client-side mobilty and P2P mobility lies in rendezvous. On the other hand, we also have to remember that more and more servers are becoming mobile, in some way or another (re-hosting, network re-numbering, etc). Hence, I would not consider these two types of mobility that different.
IMHO, more important than client-side vs. p2p is time granularity. Mobility that involves rapidly changing IP addresses is different from one where the IP addresses only occasionally change. The rate of simultaneous movements will be different, as well as the ability of possibly using proxy packet forwarders at the old addresses.
In both cases the parties need to have some kind of a name-to-address resolving mechanism for rendezvous. Whether the name is a domain name or some different name depends mostly on whether DynDNS is fast enough compared to the rate of mobility.
DC> If the mobility is rapid and frequent, the extra traffic and delay of DC> DNS queries is likely not to be the right answer.
Obviously, I concur.
DC> However note that the Internet infrastructure has no problem sending DC> consecutive packets to different places, as long as they have different DC> IP addresses. Hence, the infrastructure can handle mobility just fine DC> (as long as we ignore the question of forwarded packets that arrive DC> after the recipient has moved.)
No problem here. On the other hand, if we had proper and secure identifiers, packet forwarding would not be an architectural problem, either. That is, if a mobile host sends packet forwarding instructions to a previous access router, and if the access router is able to authenticate them, setting up a temporary forwarding path does not cause any architectural problems. In fact, Jari and I have written an I-D describing exactly that (using CGAs), but we haven't bothered to publish it, since we don't want to add more cooks to the already fairly foul tasting FMIP soup. (My apologices to anyone who may take offence; I am merely stating my personal opinions, and not any objective judgements.)
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.
With all respect, IMHO separating naming and security is a serious mistake. All security is based on identifiability. If you cannot securely identify you peers, you can't do much. Even opportunistic but secure identification is better than nothing; see our 2002 Cambridge Security Protocols Workshop paper for details.
There is another angle in security, namely real world semantics, that is best left separated from naming. (With real world sementics I mean things like database access control, Chinese wall or Clark Wilson security policies, etc.) However, as long as we are discussing routing, addressing, rendezvous, etc., real world semantics don't count much. The cyberlaws rule.
DC> In any event, please clarify what security concerns you have.
Well, I am mostly concerned secure identifiability. Is that clear enough, or should I pursue the issue more?
PN> .... and unfortunately PN> our strawman economic analysis shows that secure DNS may be PN> economicly infeasibile.
DC> huh?
That's a topic of a completely different thread, or perhaps even a paper, later. For now, it suffices to notice that the immediate incentives for people to start using decure DNS are fairly slim, at least compared to the efford required.
--Pekka Nikander