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

From: Matthew Pounsett <[email-masked]>
Date: Sun, 1 Apr 2018 17:39:53 -0400

On 31 March 2018 at 22:02, Paul Vixie <[email-masked]> 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.

---

From: Matthew Pounsett <[email-masked]>
Date: Sun, 1 Apr 2018 17:51:49 -0400

On 31 March 2018 at 17:34, bert hubert <[email-masked]> wrote:

> First, I agree it is necessary. I don't think anyone would really disagree.
> The issue is the stupendous amount of work it would be and if we are going
> to do it.
>
> A secondary question is how hard we are going to make this on ourselves if
> we do it. This comprises a number of things: 1) which RFCs would be
> obsoleted
> by the rewrite (2181?)and which ones are we going to leave in place (403x?)
>
> 2) What 'optional' things are we going to move into scope of DNS basics. In
> other words, what will 1034/1035-bis say about DNSSEC?
>
>
> I think that's another question of organization in here too, which is
whether the document is operations or implementation, and if it's
implementation what part of the architecture is being implemented (e.g.
client, server, authority, recursion, ...).

I can't decide whether it makes more sense to split up things like stubs,
full resolvers, or authoritative servers into separate documents, or to try
to describe the whole beast in one document like 1035 did.  But, for the
core, I'm leaning toward the former.

---

From: Richard Gibson <[email-masked]>
Date: Sun, 1 Apr 2018 21:19:08 -0400

I'd like to see something similar to what was done with HTTP (cf. 
https://tools.ietf.org/html/rfc7230#section-1 ), in which one or two 
foundational documents lay out the core concepts and data structures and 
then cross-link with others that flesh out more specialized aspects with 
an intent to preserving comprehensibility as things evolve (e.g., 
defining client, resolver, and authoritative server behavior pertaining 
to the same purpose in the same document with the expectation that 
changes like EDNS, EDNS options, and DNSSEC will affect them together).

I am also willing to participate in such an effort.

On 04/01/2018 05:51 PM, Matthew Pounsett wrote:
>
>
> On 31 March 2018 at 17:34, bert hubert <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     we do it. This comprises a number of things: 1) which RFCs would
>     be obsoleted
> implementation what part of the architecture is being implemented 
> (e.g. client, server, authority, recursion, ...).
>
> I can't decide whether it makes more sense to split up things like 
> stubs, full resolvers, or authoritative servers into separate 
> documents, or to try to describe the whole beast in one document like 
> 1035 did.  But, for the core, I'm leaning toward the former.
>
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=KCMaykGkoSDoh1eUUzUUET6wMGHCiDHvTIsdLKul6sk&s=GO61zxKm4_ZtgzXT3lz_56L_8uzVWuhO4IKQ0SV74-g&e=