From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: tuhs-bounces@minnie.tuhs.org X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.1 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id c2cf36d7 for ; Mon, 18 Jun 2018 14:52:03 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 54561A19F9; Tue, 19 Jun 2018 00:52:01 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 031BAA19D3; Tue, 19 Jun 2018 00:51:34 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 72A67A19D3; Tue, 19 Jun 2018 00:51:29 +1000 (AEST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by minnie.tuhs.org (Postfix) with ESMTPS id C94F59EC27 for ; Tue, 19 Jun 2018 00:51:28 +1000 (AEST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id BB45318C08A; Mon, 18 Jun 2018 10:51:27 -0400 (EDT) To: tuhs@tuhs.org Message-Id: <20180618145127.BB45318C08A@mercury.lcs.mit.edu> Date: Mon, 18 Jun 2018 10:51:27 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Subject: Re: [TUHS] core X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: jnc@mercury.lcs.mit.edu Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" > From: Tony Finch > Was this written down anywhere? 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