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

[Matthew Pounsett <[e-mail]>]

On 27 March 2018 at 20:17, Paul Vixie <[e-mail]> 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?