[DNSOP] New WG for document/protocol cleanup? Re: Current DNS standards, drafts & charter

Suzanne Woolf <suzworldwide@gmail.com> Wed, 28 March 2018 13:41 UTC

Return-Path: <suzworldwide@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4C96C1270AC for <dnsop@ietfa.amsl.com>; Wed, 28 Mar 2018 06:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id PuSmoGnGpnkI for <dnsop@ietfa.amsl.com>; Wed, 28 Mar 2018 06:41:38 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A04C1270A3 for <dnsop@ietf.org>; Wed, 28 Mar 2018 06:41:38 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id 132so2409104qkd.5 for <dnsop@ietf.org>; Wed, 28 Mar 2018 06:41:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fXoSkgy7a9BdtIYg30QKAJPl3YXUofT3KAjkkwM7PnY=; b=Qwwa5OXoHb4Aq1xvbQyng5YbU3aS+/Ez2h6nZMroisFeqmsObnWmEiPmLUCnI5eBP3 i9p5U9ar9OkWuUuvKlLi5ysQCU8VHOzmqw4uyXL3wkwNs1AcjujtxPcesRBx552JFKJm /LRKuMoUucuqucsdOEdCCz+iBLdRpaBpDhlzUXcQv8uVAMkrxM9RA1Itue5a/pPIaMtn 5PfbIr1tFAazsiTSaJIKHNQMOb6+gqGCFm6hLVpoZE4xOelptxgbOnPqKuLTtGjGpitF fmgm3d5o48sSeV5hdd2AkuwzTX85Lmhov3uCgS+m/iDfAR4J0kby85oD7+N8OFon4O3D JFTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fXoSkgy7a9BdtIYg30QKAJPl3YXUofT3KAjkkwM7PnY=; b=UCzObc5eu8wRwrkZQPTyMaH/tjxb9upa6UeifL8oWdOpGSyzMZm+0fP6s2rZqrthQg 1SAXqmQ77fFt60mFIQMa3YCkkdl526SYxgVBYG5vrWm0/Eb+8fcxk8HenOgYwX+zqECw PwKuNHaFa/AYKh2I9Ia50nWpN1Plx7DomVp/F5PK3FMNzU9SP2khxQC0wjt+Xjbkx24R S/ZkNSMS+w4OHub5ZgPOw2IVpGlvnf9eJUStAYVH3h1/yJTbcdrzTzw5zSuHOMiwsnCL A5wqN02ZkZsbk4MAlXl56znLKAW0JgTxgNC1iPraZ+/Rihx8m6oC5Z8l6y1+HvJS1nvp 58+Q==
X-Gm-Message-State: AElRT7E0PD0DeUWyXIcoCt1X/ZNqOLiN0ND6whEd6gHXZ3dmZuMOc83F t4CjlCt+13fkVsZQoEC/TOY7GWuS
X-Google-Smtp-Source: AIpwx49BokTP+csDYlMoc9ExA6dorS8QpgT6DbyMQJccGTy3quQScWTQsAC9WXtttT/NFua6a+HKxA==
X-Received: by with SMTP id q32mr5089111qkh.297.1522244496305; Wed, 28 Mar 2018 06:41:36 -0700 (PDT)
Received: from ?IPv6:2601:181:c300:3d20:9988:d86a:26c5:8170? ([2601:181:c300:3d20:9988:d86a:26c5:8170]) by smtp.gmail.com with ESMTPSA id n73sm450189qka.51.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 06:41:35 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Suzanne Woolf <suzworldwide@gmail.com>
In-Reply-To: <5852643C-B414-4C3E-A1B9-553054D3DD46@isc.org>
Date: Wed, 28 Mar 2018 09:41:34 -0400
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6B0E0B1E-A535-4170-9A41-8567B7F4D093@gmail.com>
References: <20180326154645.GB24771@server.ds9a.nl> <CA3D81B6-164F-4607-A7E6-B999B90C4DA8@gmail.com> <5852643C-B414-4C3E-A1B9-553054D3DD46@isc.org>
To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= <ondrej@isc.org>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/extWVfGgcyezykwqUtQ5uBF3CHg>
Subject: [DNSOP] New WG for document/protocol cleanup? Re: 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 13:41:40 -0000

Note this discussion has started to split into (at least) two: cleaning up the DNS standard (protocol, documents, or both), possibly in a new WG; and whether/how the existing DNSOP WG needs to adjust its efforts. 

> On Mar 27, 2018, at 3:49 AM, Ondřej Surý <ondrej@isc.org> wrote:
> Hi Suzanne,
>> If the WG feels that the previous view of how DNSOP should work has been overtaken by events, we can certainly work with our Area Director (hi Warren!) on a revised charter.
> I strongly believe that any work on cleaning up DNS protocol and/or rewriting RFC1034/RFC1035 and associated document would need a new WG with tightly defined charter.
> Hence, I will not request or I won’t support adopting my deprecating-obsolete-rr-types as a WG document - it might become one of the first documents for new WG, or it might end up as individual submission. While this work might be considered as “protocol maintenance”, I think it is bigger then simple protocol maintenance.
> Again, from experience from dnsext, I would strongly suggest that any work in this area is split into CHANGE documents and REWRITE documents, with strict scope. Documents rewriting existing RFCs while adding more stuff at the same time tend to not reach the finish line.

This all makes sense to me. 

I have no opinion (yet) on what the desired output should be (some new RFCs? A reference implementation/RFC set? Something else?), but agree it doesn’t fit DNSOP.

Personally I think it’s within charter for DNSOP to facilitate this discussion, permit it to stay on the WG mailing list, etc. while people work out how they want to approach it, in substance and process. For instance, DNSOP helped get DPRIVE going by having a session at an IETF meeting on the DPRIVE drafts and adopting one of them (QNAME minimization). The important thing should be whether there’s an identifiable work item and whether the will exists to get it done, not how to charter a WG or otherwise work the process machinery. There are quite a few DNSOP (and IETF) regulars who are current or past WG chairs, ADs, and document editors, with experience of making the IETF machinery turn, who would be happy to advise proponents. This includes the current DNSOP chairs and AD.

I do have to say I support the warnings about getting bits committed to documents (and possibly code). As another anecdote to add to the stack, I remember (as I assume Paul Vixie, Matt Larson, Rob Austein, Ed Lewis, and Roy Arends do) the effort it took to get the DNSSEC RFCs done: a series of interop workshops, a couple of open source companies sponsoring development in well-known code bases, and money to support production of both code and documents. Resources committed as an afterthought were not getting it done. 

This is a different project, and I think it’s doable, but it’s not a weekend undertaking.