On 27 March 2018 at 20:17, Paul Vixie <p...@redbarn.org> wrote: > I think we're discussing the same idea from different perspectives. >> > > i think so, yes. > > I think writing a new document that references other documents to say >> "here's the sections in each of these you need to implement" without >> actually making any of them clearer is unhelpful, and just adds to the >> pile of documents that an implementer needs to read. >> > > that's not what i heard bert propose, and it's not what i'm thinking. > where an older document is not clear, its intent should be restated in > modern language with modern understanding. where an older document is > clear, we can refer back to it. if the balance ever tips, then some future > generation of protocol developers can obsolete older documents in their > entirety, because the useful parts have all been restated or cut and pasted.
So yes.. we are on roughly the same page. I'm not a huge fan of meta-RFC reading lists, even for documents that are fairly clear, but it's hugely preferable to the current situation. One of the things I have never liked about the RFC series is the lack of clarity in an Update document. I always thought an RFC that Updates another should be required to state unequivocally which sections of the older document are obsoleted or, which "new" sections of the older document the new document creates. Changing a section in part should never have been allowed. Creating those references where they don't already exist and putting them in a new RFC potentially increases clarity, but also increases the complexity of the reading material; I'd much prefer we reduce both. > > > While I recognize there's already been one failed attempt at this, >> I'd still much prefer we replace as much of that stack as possible >> with a smaller set of clearer documents. >> > > this is what i want. we should aim for a living RFC that's reissued from > time to time as the mandatory-to-implement subset inevitably grows. i have > no appetite for obsoleting 1035, but i do want a new implementer to be > referring to it as directed by a more modern document, rather than reading > it and wondering what parts are still in effect. > I think 1035 is the prime candidate for being obsoleted by new documents. It's been updated and clarified so many times, and there are so many undocumented workarounds of its underspecification, that the reading required to understand what parts of it are in force is incredibly discouraging. There are lots of more modern documents that can stand on their own as long as they are updating a clear core specification, but we're missing that clear core specification in the first place. Now here's a document series process question... if RFCs B & C update A, and D is written to combine and obsolete A & B, what do you do with the meta-data on C?
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
