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

Paul Vixie <paul@redbarn.org> Wed, 28 March 2018 00:17 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61FF8126C0F for <dnsop@ietfa.amsl.com>; Tue, 27 Mar 2018 17:17:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcP41uHqhG9P for <dnsop@ietfa.amsl.com>; Tue, 27 Mar 2018 17:17:07 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388D8120724 for <dnsop@ietf.org>; Tue, 27 Mar 2018 17:17:07 -0700 (PDT)
Received: from [10.1.10.176] (50-255-33-26-static.hfc.comcastbusiness.net [50.255.33.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id AAB777594C; Wed, 28 Mar 2018 00:17:06 +0000 (UTC)
Message-ID: <5ABADEFE.30806@redbarn.org>
Date: Tue, 27 Mar 2018 17:17:02 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.24 (Windows/20180302)
MIME-Version: 1.0
To: Matthew Pounsett <matt@conundrum.com>
CC: Ondřej Surý <ondrej@isc.org>, Suzanne Woolf <suzworldwide@gmail.com>, dnsop <dnsop@ietf.org>
References: <20180326154645.GB24771@server.ds9a.nl> <CA3D81B6-164F-4607-A7E6-B999B90C4DA8@gmail.com> <5852643C-B414-4C3E-A1B9-553054D3DD46@isc.org> <CAAiTEH8aA3J1j4iUQDisDHiUJXopykKkssuhOK=v+iVV_XZWyA@mail.gmail.com> <5ABAB891.3010306@redbarn.org> <CAAiTEH94S9VE0_QNEmUvVEkvxtBi2hoWo3DUVENJbEiXM+kkHw@mail.gmail.com>
In-Reply-To: <CAAiTEH94S9VE0_QNEmUvVEkvxtBi2hoWo3DUVENJbEiXM+kkHw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TEywWh7D0yo2WvSiUKJrjaOrnzw>
Subject: Re: [DNSOP] Current DNS standards, drafts & charter
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Mar 2018 00:17:08 -0000


Matthew Pounsett wrote:
>
>
> On 27 March 2018 at 17:33, Paul Vixie <paul@redbarn.org
> <mailto:paul@redbarn.org>> wrote:
>
>     i see no purpose in change documents, which would add to the set of
>     things a new implementer would have to know to read, and then to read.
>
>
> 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.

> 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.

-- 
P Vixie