[dnsext] Re: [Technical Errata Reported] RFC4035 (8037)

Paul Hoffman <phoffman@proper.com> Tue, 30 July 2024 18:48 UTC

Return-Path: <phoffman@proper.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDB5C180B5E for <dnsext@ietfa.amsl.com>; Tue, 30 Jul 2024 11:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVdYcHOsgjNa for <dnsext@ietfa.amsl.com>; Tue, 30 Jul 2024 11:48:38 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85D4CC169412 for <dnsext@ietf.org>; Tue, 30 Jul 2024 11:48:38 -0700 (PDT)
Received: from [10.32.60.169] (76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] (may be forged)) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id 46UImLVl027540 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Jul 2024 11:48:23 -0700 (MST) (envelope-from phoffman@proper.com)
X-Authentication-Warning: mail.proper.com: Host 76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] (may be forged) claimed to be [10.32.60.169]
From: Paul Hoffman <phoffman@proper.com>
To: Elias Heftrig <elias.heftrig@sit.fraunhofer.de>
X-Mailer: MailMate (1.14r6048)
Message-ID: <A123EBD2-55B3-4EAF-8676-F726FDD377B5@proper.com>
In-Reply-To: <dddfa1d7-fdd4-413f-a2a7-5bda3da5a46c@sit.fraunhofer.de>
References: <20240718154431.808BD7FA60@rfcpa.rfc-editor.org> <A1D2718C-186F-4D80-A148-C4A9973F78B6@hactrn.net> <51FBDFB8-263C-41D8-9BDF-BD67A26DF998@nist.gov> <b705f274-3e69-4dcd-98b0-023165aee7d3@sit.fraunhofer.de> <B75EDCC4-87AF-4733-A63A-E7A1515BEF9E@nist.gov> <dddfa1d7-fdd4-413f-a2a7-5bda3da5a46c@sit.fraunhofer.de>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
X-MailFrom: phoffman@proper.com
X-Mailman-Rule-Hits: max-recipients
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsext.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-size; news-moderation; no-subject; digests; suspicious-header
Message-ID-Hash: YHDP6Z7NTHKTCAEB736MEUK7TA3WJAGT
X-Message-ID-Hash: YHDP6Z7NTHKTCAEB736MEUK7TA3WJAGT
X-Mailman-Approved-At: Wed, 31 Jul 2024 11:06:49 -0700
CC: "Rose, Scott W. (Fed)" <scott.rose@nist.gov>, Rob Austein <sra@hactrn.net>, RFC Errata System <rfc-editor@rfc-editor.org>, sra@isc.org, massey@cs.colostate.edu, ek.ietf@gmail.com, evyncke@cisco.com, ogud@ogud.com, dnsext@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [dnsext] Re: [Technical Errata Reported] RFC4035 (8037)
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsext/qJzYPn3f2uRxkQmss2F_N3-qOlI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsext>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Owner: <mailto:dnsext-owner@ietf.org>
List-Post: <mailto:dnsext@ietf.org>
List-Subscribe: <mailto:dnsext-join@ietf.org>
List-Unsubscribe: <mailto:dnsext-leave@ietf.org>
Date: Tue, 30 Jul 2024 18:48:39 -0000
X-Original-Date: Tue, 30 Jul 2024 11:48:20 -0700

On 29 Jul 2024, at 13:48, Elias Heftrig wrote:

> as I take it from the IETF120 hallway discussions on the errata an update to the RFCs is a viable way to deal with these flaws as well. Since updates seem to take quite a while until published, the errata, as reported, offer some benefit of warning new implementers about the flaws in the meantime (albeit their visibility being somewhat limited). Serving that purpose, from my own perspective, an errata status of "Held for Document Update" might be the way to go, or else a "Rejected", but with a very clear comment that the reported flaws (errata 8037 and 8038) are in fact an issue and need to be dealt with by an update to the according RFCs. "Held for Document Update" might be a bit clearer in that regard.
>
> If I missed out on any discussions behind the scenes and things have become clearer in the meantime, please don't hesitate to send me an update.

Errata are the wrong way to propose technical changes to a protocol, which is what this errata report does. They cannot be marked as "Held for Document Update" because that presumes that the WG will later fully agree with the proposed changes to the protocol.

The IETF update process is indeed somewhat heavyweight. The decision to make it that way balances long-term protocol stability against flexibility. Regardless, using the errata process (which is poorly defined and not all that well executed) as a way to propose protocol changes is not a good alternative to doing the hard work of proposing updates.

--Paul Hoffman