Dow Street allegedly wrote on 03 29 2009 4:38 PM: >> locator A locator is a name that has topological sensitivity and >> must >> change if the point of attachment changes. By convention, >> a locator refers to layer 3 by default. It is also >> possible to have locators at other layers. Locators may >> have other properties, such as their scope (local or global >> (default)) and their lifetime (ephemeral or permanent >> (default)). >> >> identifier An identifier is the name of an object; identifiers have no >> topological sensitivity, and do not change, even if the >> object changes its point(s) of attachment within the >> network topology. Identifiers may have other properties, >> such as the scope of their uniqueness (local or global >> (default)), the probability of their uniqueness >> (statistical or absolute (default)), and their lifetime >> (ephemeral or permanent (default)). >> >> address An address is a name that is both an interface locator and an >> endpoint identifier. > > As a starting point, I think we can say that a system has objects and > names for those objects.
and functions that act on those objects and names for the functions. > A given name could be a locator, an identifier, or both. Whether it is > considered to be a locator or identifier depends on *how the name is > used*. I'm so pleased to meet a fellow believer in the wilderness. Usage is the primary issue. However, _intended_ usage can also apply (for example, if I pass you a message which has a field in it that contains something I want you to use as a locator, it's a locator). And some names can only be usefully used a particular way due to the way they are constructed or administered. > A name alone is just a name - it is the binding of name to use > (i.e. role) that makes it a locator or identifier. As such, it is quite > possible that a name can serve various roles, or be used in different > ways, by different components of the system at the same time. > Furthermore, the scope and/or nature of the named object can differ > between different users of the name. (Is this the name of an IP > interface, a stack, a host, etc?) > > So, what makes a name into a locator? > > "A name is defined to be a "locator" when it is used in the context of, > or perhaps by, a system that has a notion of geography, topology, or > distance, and the value of the name, combined with a location in the > system, produces a vector of relevance to that system's geography or > topology." > > Looking at Tony's definitions above, there is something about the phrase > "must change if the point of attachment changes" that does not seem > quite right. (Still trying to figure out why, though...) Noel Chiappa allegedly wrote on 03 29 2009 5:13 PM: > > From: Dow Street <[email protected]> > > > So, what makes a name into a locator? > > When it has _structure_ which relates to _where_ the named thing is. > > I.e. MAC is not a locator, even when used in a bridging system, because > there's no structure in it - MACs are just identifiers for the interface. Right, it is administered in such a way that it cannot be used effectively as a locator. That limits its use ... but if tomorrow I enforced assignment of my MACs hierarchically and dynamically, suddenly <Ta Da> they could be locators. It's not a property of the thing itself, just how it is used. > > "A name is defined to be a "locator" when it is used in the context of, > > nor perhaps by, a system that has a notion of geography, topology, or > > distance, and the value of the name, combined with a location in the > > system, produces a vector of relevance to that system's geography or > > topology." > > I _think_ this says the same thing as the above , but in a mathematical way, > but I'm not sure. > > > there is something about the phrase "must change if the point of > > attachment changes" that does not seem quite right. > > Well, one thing is that a locator may change, even if the physical location > the entity is plugged in hasn't changed, if the structure of the network has > been rearranged (e.g. a chunk of topology has been re-homed, e.g. to a > different ISP). I think that falls under "change in topological location". The topology changes so the topological location changes, even if the attachment point hasn't. _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
