Re: [DNSOP] Current DNS standards, drafts & charter

[Paul Vixie <[e-mail]>]

Matthew Pounsett wrote:
>     there's a carrier wave in that time series, which has its own wave
>     form. at the end of each epoch, we'll be back where we are today,
>     without a coherent or complete document set. we'd be moving from
>     failing to plan, to planning to fail. let's make a better move.
>
> That's a pretty cynical view.  Do you not think the specifications being
> written today are better than they used to be?

mine have gotten better, but are still not as good as 1033, 1034, and 
1035 were. i won't speak to my perception of the quality of others' 
work. however, i have noticed that each DNS-related IETF WG has had 
times of high process discipline and times of expediency -- and i think 
that's because we're doing it with humans, and i know that we will 
continue to do this with humans. i don't experience this as cynicism.

>     to achieve the goals you stated earlier, there would have to be both
>     the time series of changes, and the timeless document full of
>     lineouts. bert's "DNS Illustrated" github site is an example of the
>     latter, and a starting point for it, if we wish.
>
> If we had a better baseline, and if our Updates documents were clearer
> about what they change in older documents, that line-out would be a
> pretty trivial document to maintain, and might not even be necessary.

that supposition depends on what the future DNS-related WG's are, who 
chairs them, who attends meetings, what the culture is, who the AD's 
are, who the rest of the IESG and IAB are... many things we cannot 
predict now and will not be able to control then.

furthermore, the IETF would have to update some STD document every time 
a new DNS-related RFC was published, just to enumerate the full set of 
things a new implementer should study and consider. that STD could be 
just a list of RFC's, or could mention specific sections and say they 
are "in" or "out", or could repeat the relevant text. i could argue for 
any of those three approaches. but your model requires one of those, or 
else, "read them all and let the market sort it out" is our guidance to 
new implementers. that's what's not working now, and won't work, ever.

-- 
P Vixie