You are confusing transport address (describing a location in a topology) with an object name (a book, a computer, a process running on a computer).

An object name like an ISBN does not need to be hierarchical because they do not describe discrete locations. Introducing hierarchy improves managability and efficiency of databasing. Many hierarchies can be imposed on object names.

If there isn't, there should be a theory in computer science with enough levels of indirection you can solve any problem, i.e. ISBN->Call Number->Shelf Location. Trick question: Does a LC Call number describe a location in a topology or an object name? Many hierarchies can also be imposed on an object's location, especially when that location is connected by a rich topological mesh.

Remember: at each level of naming there can be different and completely disjoint hierarchies. There are scalability implications in all of them, most notably when the names used have size limits or are distributed non-hierarchically (like ethernet addresses or the COM domain). However, the important thing is that when a name is used as a LOCATOR in a topology, in order to be scalable that name must be related to that topology and in large networks must lend itself to aggregation in order to reduce the amount of information needed to have that locator be used throughout the network.

Another axis of the problem is the stability of the names used as locators. Otherwise you have just moved the problem up a level, translating the object name to its instantaneous location. Love that indirection. Propagating the change in object name->locator name when a route flaps, or every corporate merger or acquisition, doesn't scale well any better than the current system. Who is going to tell Bert or Bernie that all those MCI customers need to renumber when they merge their respective networks? Geographic addressing only has the advantages in that continental drift moves at a much slower pace than the changes in most network topologies. How you get to Cleveland might change, but Cleveland tends to remain in the same relative position. However, strict hierarchies have the disadvantage you can wipe out a subtree by simply targeting a higher level node. Being able to wipe out Cleveland by disrupting the Cleveland NAP is not a desirable feature of geographic hierarchical addressing. So you need some redundancy between the subtrees (i.e. a mesh), which means you have to keep track of that redundant information. Since that redundant information is likely based on the providers' facilities in and out of Cleveland, it looks like topological addressing. So do you name objects based on how you get to Cleveland, or based on their presence in Cleveland? But I think everyone has heard this argument before. Trade-offs, trade-offs. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation