On 31 March 2018 at 22:02, Paul Vixie <p...@redbarn.org> wrote: > > 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. >
No. None of that is required by my suggestion. "Scan the Introduction" perhaps, but not "read them all." All that would have been required to make our current situation less problematic is a few phrases like "this RFC obsoletes section X.Y of RFC Z" or "this RFC should be read as if it is section A.B.D after section A.B.C in RFC Z" in anything with Updates meta-data. And your assertion that we'd need some STD to be repeatedly updated is obviated by something like "this RFC (is|is not) considered mandatory to implement for the DNS protocol." Non-IETF documents that summarize RFCs, collect them into useful categories, or cherry-pick sections to create a "core" standard are useful to us now because we didn't deal with these things while writing the RFCs that we have today. Adding a bit of rigour to what we submit to last call could make those things optional tomorrow. External documentation might always have some use as a primer, summary, walkthorugh, or historical context, but unless you're giving up on the IETF entirely I think it's a worthy goal to try to produce a document set that doesn't *require* external documentation to make it clear. And if you're going to say that external documentation will always be required, and that we can't possibly create documents that don't require it, then I think that's giving up on the IETF and we might as well skip this process and use that one instead. I, for one, would rather only work on the documents once.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
