John, Just to be clear, I was using DNS as an example. We can always question design decisions we've made. I believe that Andrew and others may be interested in doing just that, but not from the top down (as it were). Eliot On 1/9/14 12:50 PM, John C Klensin wrote: > > --On Tuesday, January 07, 2014 15:58 +0100 Eliot Lear > <lear@xxxxxxxxx> wrote: > >> Andrew, >> >> It's clear that I wasn't clear. Deciding on a tree structure >> has political implications, be that DNS, RPKI, or other (and >> there are other). To ignore those implications would be >> unwise. They are weighed against technical considerations, as >> always. >> ... > Eliot, > > In the hope of focusing the discussion a bit, I think it would > be more accurate to say that "having a tree structure...r > "having decided on a tree structure...". > > It feels a little strange for me to be defending the DNS design > because I've never been a huge fan of some aspects of it, but a > little bit of insight into the context of those decisions may be > helpful. > > I was not involved in the DNS design process, but I was doing > work on databases, including distributed databases, at the time > in the early to mid-1980s. Against the backdrop of the database > state of the art at the time, if one started with design > criteria of approximately: > > -- replacing the name-to-address and > name-to-limited-supplementary-information functions of > the Host Table without significant loss of functionality > -- having a hierarchical name structure (which does not, > itself, imply a hierarchical database) > -- having something that could be administratively > distributed at multiple levels of the name structure > -- having a distributed database that could be plausibly > implemented without lock-commit-acknowledge or > journal-based update facilities > -- having an arrangement that would facilitate local > caching, not just for performance but as a mechanism to > allow systems that were temporarily disconnected from > all or part of the network to keep functioning reasonably > -- The result needed to be plausible for non-specialists > to implement in a way that would interoperable. > > Most of the above are documented in the various pre-DNS papers. > Most are also pretty obvious. Given how bad some > implementations have been, there is a pretty good case to be > made that the design failed on the last criterion, but a > non-hierarchical alternative, especially given the then state of > the art, would have been much worse in that regard. > > There just were not a lot of choices other than a hierarchical > database system. The designers could have made some different > choices within the general hierarchical model, some of which I > hinted about in my earlier note. I don't know if those > alternatives were even considered (and suspect most of them were > not). But the decision to use a hierarchical model, again > given the state of the art, had to be pretty much determined by > those design criteria. > > I think a choice between something that meets the criteria and > is comparatively simple, robust, understandable, and > implementable and something that is much more complex and/or > that lacks robustness against network interruptions is an > engineering choice (and an obvious one). One could argue that > it is political, but that requires arguing either that every > decision the involves either implementation or operational > economics or other operational issues is political. > > One could also argue that the criteria were wrong and that "no > central administrative or coordination function" should have > been a requirement. But that requirement would be a very > difficult one technically even today and the environment at the > time -- IANA existed well before the DNS and was generally > trusted and the DNS design was a lot less centralized than its > predecessor-- just didn't call for it. So, except with extremes > of hindsight about what we might like to have had today given an > evolution path that certainly could not have been accurately > anticipated at the time, I think it is hard to argue that the > omission of a "no central..." criterion was political at the > time. > > Of course, one can say today that the technical/ engineering > decisions made then have political implications today but, given > the right set of conditions, that could be true of almost any > decision or fact, as the history of ignorant legislative efforts > to change PI or modify the speed of light amply illustrate. It > doesn't retroactively make the decisions themselves political as > others have implied. > > Finally, with regard to CLASSes just being treated as a another > level of the hiararchy, a sort of super-root... Again, I wasn't > there, no only not there for the DNS design effort but not > involved in the Chaosnet and Hesiod implementations that have > been the major examples of actually deployed and actively used > examples of CLASSes. But it is clear to me from both reading > the specs and what little I know of those implementations that > kre is correct and the capability is badly underspecified. I > think there are even some errors in what the spec does appear to > say. But getting from there to either "there is a political > problem because CLASSes don't work" in the presence of > counterexamples to "don't work" or "CLASSes just create another > level of the tree with the same properties in all CLASSes that > the CLASS=IN [sub]tree has" seems to me to be a huge stretch > that is not really justified by either implementation history or > the spec. > > Just my opinion, of course. > > best, > john > > >