Re: [TUHS] core

Alas, no. It was a presentation at a group seminar, and used either hand-drawn transparencies, or a white-board - don't recall exactly which. I later tried to dig it up for use in Nimrod, but without success. As best I now recall, the concept was that instead of the namespace having a root at the top, from which you had to allocate downward (and then recurse), it built _upward_ - if two previously un-connected chunks of graph wanted to unite in a single system, they allocated a new naming layer on top, in which each existing system appeared as a constituent. Or something like that! :-) The issue with 'top-down' is that you have to have some global 'authority' to manage the top level - hand out chunks, etc, etc. (For a spectacular example of where this can go, look at NSAP's.) And what do you do when you run out of top-level space? (Although in the NSAP case, they had such a complex top couple of layers, they probably would have avoided that issue. Instead, they had the problem that their name-space was spectacularly ill-suited to path selection [routing], since in very large networks, interface names [adddresses] must have a topological aspect if the path selection is to scale. Although looking at the Internet nowadays, perhaps not!) 'Bottom-up' is not without problems of course (e.g. what if you want to add another layer, e.g. to support potentially-nested virtual machines). I'm not sure how well Dave understood the issue of path selection scaling at the time he proposed it - it was very early on, '78 or so - since we didn't understand path selection then as well as we do now. IIRC, I think he was mostly was interested in it as a way to avoid having to have an asssignment authority. The attraction for me was that it was easier to ensure that the names had the needed topological aspect. Noel