it is worth bearing in mind that the namespace of wide use before DNS was email, and for many had already been made a tree. explicit hop-paths persisted alongside initiatives like honey-danber and user@host forms, the latter having adopted dot-separated labels under a tree form, well before widespread adoption of port 53. almost all conversations around 'how do we glue this external mail service in' wound up assuming a new top-level domain such as .BITNET to create a clean tree entrypoint for an otherwise unconstrained/unknown namespace.
On Fri, Jan 10, 2014 at 3:48 AM, John C Klensin <john-ietf@xxxxxxx> wrote:
--On Thursday, January 09, 2014 15:47 +0100 Eliot Lear
<lear@xxxxxxxxx> wrote:Certainly we can, and should, question design decisions we've
> 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).
made, if only to learn from them. For the same reason, I also
think it is appropriate to review and question the goal and
constraint decisions that drive those design decisions
But I think two points are relevant when we start doing so:
(1) The observation that a decision may have political
implications -- at present or at some point in the future-- does
not make the decision itself political rather than technical.
For the IETF's work, political considerations are best
incorporated into goal and constraint spaces rather than leading
us into an argument about the basis on which those decisions are
made.
(2) Unless one is either trying to learn in the hope of doing a
better job on future designs or likes purely theoretical
discussions about the circumstances that would prevail in some
alternate reality, it seems to me that discussions of the
implications of trying to deploy redesigned versions of
something should be considered as part of the constraint space
for any results of questioning design decisions. Our track
record for deployment of incompatible replacements for things
that work even moderately well has been, IMO, poor enough to
give us considerable pause if, e.g., someone proposes to take
"questioning design decisions" toward an effort to redesign,
reimplement, and redeploy the DNS. My own hypothesis about that
is that the DNS we have is pretty much the DNS we are going to
have and that it would serve the broader community well if we
both accepted that and because more aggressive about saying "not
a good idea, find some other facility to use as a base" when
ideas come along that require violations of important principles
of the design.
best,
john