Re: Proposed IESG Statement on the use of the “Updates” header

Paul Wouters <paul@nohats.ca> Tue, 11 September 2018 16:46 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E171130EFF; Tue, 11 Sep 2018 09:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 zdT0QM0M5fVN; Tue, 11 Sep 2018 09:46:04 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC4541293FB; Tue, 11 Sep 2018 09:46:03 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 428rQK2jqjzDmT; Tue, 11 Sep 2018 18:46:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1536684361; bh=n/vCsDzbfjXrcUUW9xL3NtZIhQT7tQMjciOfzLLVuFU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=tvy7BJhF0XKs4/y1QQD3pqwH348T14ZuALzN8oHjcHOc6rUlWy+jLKcQcD+gvVkqC 9RSQ9LOzxV8fVuEGHSlkTDxLOu7C4f0pR5nXjGgUJ/P7CVoe0KBfuvyuZwxHOoAQuC koakIy6rGUmRAARde+qXA3Syy4JR67Mxiu6YIUkM=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 8A0X3JCFaXEa; Tue, 11 Sep 2018 18:46:00 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 11 Sep 2018 18:45:59 +0200 (CEST)
Received: from [10.159.220.245] (unknown [199.119.233.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id BD26E9E1; Tue, 11 Sep 2018 12:45:57 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca BD26E9E1
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
Subject: =?utf-8?Q?Re:_Proposed_IESG_Statement_on_the_use_of_the_?= =?utf-8?Q?=E2=80=9CUpdates=E2=80=9D_header?=
From: Paul Wouters <paul@nohats.ca>
X-Mailer: iPhone Mail (15G77)
In-Reply-To: <59F6DED7-8D39-4206-8268-22AB6A99A876@nostrum.com>
Date: Tue, 11 Sep 2018 12:45:51 -0400
Cc: ietf@ietf.org, The IESG <iesg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1FA83DCD-AC0B-43FB-8529-092D551583F1@nohats.ca>
References: <59F6DED7-8D39-4206-8268-22AB6A99A876@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/JVQ6jfeXAQ7pmqjtBfdlyVcd1AY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Sep 2018 16:46:13 -0000

I always interpreted it as “don’t implement this RFC as-is without reading the RFC that updates this document”

So modular extensions would not need to update:

Sent from my iPhone

> On Sep 11, 2018, at 11:55, Ben Campbell <ben@nostrum.com>; wrote:
> 
> Hi Everyone,
> 
> There have been several discussions lately about the use and meaning of the “Updates” header in RFCs, and the resulting “Updates”/“Updated by” relationships. The IESG is thinking about making the following statement, and solicits feedback.
> 
> Thanks!
> 
> Ben.
> --------------------------------------------
> 
> There has been considerable confusion among the IETF community about the formal meaning of the “Updates” / "Updated by" relationship in IETF stream RFCs. The “Updates” header has been historically used for number of reasons of various strength. For example, the “Updates” header may be used to indicate critical normative updates (i.e. bug fixes), optional extensions, and even “additional information”.
> 
> The IESG intends these headers to be used to inform readers of an updated RFC that they need to be aware of the RFC that updates it. The headers have no formal meaning beyond that. In particular, the headers do not, by themselves, imply a normative change to the updated RFC, nor do they, by themselves, imply that implementers must implement the updating RFC to continue to comply with the updated one.
> 
> The specific reasons that a given RFC updates another should be described in the abstract and body of the new RFC. The level of detail may differ between the abstract and the body; typically an abstract should contain enough detail to help readers decide if they need to read the rest of the RFC. The body should contain enough detail for readers to fully understand the nature of the update.
> 
> The importance of including an “Updates” header depends on the nature of the update. Normative updates that do not use a known extension point should always include an “Updates” header. Extensions that do use known extension points do not typically need to include the “Updates” header, but may in cases where it’s important to make the extension known to readers of the original RFC. Other uses of “Updates” may be appropriate when it’s important for readers to know about them; for example a new RFC may expand security or operational considerations in a way that is not normative, but still important.
> 
> RFCs that fully replace other RFCs should typically use the “Obsoletes” header rather than the “Updates” header. The “Updates” header should be used to flag updates to published RFCs; it is not appropriate to “Update” an Internet-Draft.
> 
>