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

Paul Vixie <paul@redbarn.org> Sat, 31 March 2018 21:27 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 730AC1241F3 for <dnsop@ietfa.amsl.com>; Sat, 31 Mar 2018 14:27:21 -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 1W4aKzRwbKuX for <dnsop@ietfa.amsl.com>; Sat, 31 Mar 2018 14:27:20 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080E4120725 for <dnsop@ietf.org>; Sat, 31 Mar 2018 14:27:20 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:dd04:78fb:edc1:47b1] (unknown [IPv6:2001:559:8000:c9:dd04:78fb:edc1:47b1]) (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 AF17B7594D; Sat, 31 Mar 2018 21:27:19 +0000 (UTC)
Message-ID: <5ABFFD35.1020502@redbarn.org>
Date: Sat, 31 Mar 2018 14:27:17 -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> <5ABADEFE.30806@redbarn.org> <CAAiTEH9=rmhmRqCQyEbBFKF3BgKbe8bx+G3eAqhdqKEC55eA4A@mail.gmail.com> <5ABBE389.5020008@redbarn.org> <CAAiTEH8bLcvfnhB3=Hzds=q8ppMQOZw6vXY7h3CO-MdYW3BFCg@mail.gmail.com>
In-Reply-To: <CAAiTEH8bLcvfnhB3=Hzds=q8ppMQOZw6vXY7h3CO-MdYW3BFCg@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/A7Tb1j99NMZBuYHTW3OvoWMaISA>
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: Sat, 31 Mar 2018 21:27:21 -0000


Matthew Pounsett wrote:
>
>
> On 28 March 2018 at 14:48, Paul Vixie <paul@redbarn.org
> <mailto:paul@redbarn.org>> wrote:
>
>     matt, the rfc document set is innately time-series. this was seen as
>     a strength compared to some "document set in the sky" that would be
>     updated periodically with lineouts and additions, like for example
>     legal codes or the ARIN PPML. i think you're very close to saying we
>     need the latter in addition to the former, and if so, then i agree
>     with you, but this is an IETF problem not a DNSOP problem. --paul
>
>
> I think the RFC series as a whole needs to contain both, but I'm not
> saying that both should exist simultaneously for any given set of
> documents within the RFC series.

i think you are.

> I think we've reached a point where the time series for DNS has
> become so complex and convoluted that it's time for a reset to make
> it readable again.  We can then carry on patching that with
> time-series documents if we want, but the rewrite will give us a new
> baseline that's coherent and complete, which we don't have today.

there's a carrier wave in that time series, which has its own wave form. 
at the end of each epoch, we'll be back where we are today, without a 
coherent or complete document set. we'd be moving from failing to plan, 
to planning to fail. let's make a better move.

to achieve the goals you stated earlier, there would have to be both the 
time series of changes, and the timeless document full of lineouts. 
bert's "DNS Illustrated" github site is an example of the latter, and a 
starting point for it, if we wish.

-- 
P Vixie