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

Ben Campbell <> Tue, 11 September 2018 16:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3D7B9130F19; Tue, 11 Sep 2018 09:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d3xgUUmxT1Z9; Tue, 11 Sep 2018 09:40:56 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 40CC91293FB; Tue, 11 Sep 2018 09:40:56 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id w8BGeoGf040336 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 11 Sep 2018 11:40:51 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: Ben Campbell <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_76110DF9-347E-48AB-81D4-26753639CC5B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: =?utf-8?Q?Re=3A_Proposed_IESG_Statement_on_the_use_of_the_?= =?utf-8?Q?=E2=80=9CUpdates=E2=80=9D_header?=
Date: Tue, 11 Sep 2018 11:40:48 -0500
In-Reply-To: <007801d449ec$e850b5a0$>
Cc: "" <>, The IESG <>
To: tom petch <>
References: <> <007801d449ec$e850b5a0$>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Sep 2018 16:41:04 -0000

> On Sep 11, 2018, at 11:31 AM, tom petch <> wrote:
> Ben
> I don't understand it! In particular
> 'Normative updates that do not use a known extension point should always
> include an “Updates” header.'
> leaves me ignorant.
> 'Normative' I am well familiar with from I-D references but that meaning
> does not seem to apply here (since Normative as a Reference means you
> must understand the referenced work)..
> '..known extension point..' I am not familiar with except for a rather
> technical discussion which I read - but did not understand - on this
> list recently.

A known extension point is any mechanism in the original RFC designed to allow extensibility without modifying the RFC. IANA registered code points are a common approach. Feature negotiation mechanisms also come to mind.

Can you suggest a better term for this?

> To give a practical problem; when an I-D adds new entries to an existing
> registry, is that an 'Updates'?  I have seen ADs firmly tell WG Chairs,
> holding the contrary opinion, that it is not, and I thought that that
> was settled, but applying this statement to that situation leaves me in
> ignorance.

The intent is that these are usually not “Updates”. But they can be if there are special circumstances, which I presume would be documented in the text that describes the nature of the update. An individual AD may or may not agree with an argument that a particular update is “special” in this sense, but I believe we all agree that such special cases are in the realm of possibility.



> Tom Petch
> ----- Original Message -----
> From: "Ben Campbell" <>
> To: <>
> Cc: "The IESG" <>
> Sent: Tuesday, September 11, 2018 4:55 PM
> 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.