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

"Adrian Farrel" <> Tue, 11 September 2018 18:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 92A37130EEF; Tue, 11 Sep 2018 11:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4zchn45w9BP7; Tue, 11 Sep 2018 11:38:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E4330130EDF; Tue, 11 Sep 2018 11:38:57 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id w8BIctxW005063; Tue, 11 Sep 2018 19:38:55 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id B9EE622044; Tue, 11 Sep 2018 19:38:55 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS id A446D22042; Tue, 11 Sep 2018 19:38:55 +0100 (BST)
Received: from 950129200 ( []) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id w8BIcqcG009688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Sep 2018 19:38:54 +0100
Reply-To: <>
From: "Adrian Farrel" <>
To: "'Robert Sparks'" <>, "'Ben Campbell'" <>, <>
Cc: "'The IESG'" <>
References: <> <>
In-Reply-To: <>
Subject: =?UTF-8?Q?RE:_Proposed_IESG_Statement_on_t?= =?UTF-8?Q?he_use_of_the_=E2=80=9CUpdates=E2=80=9D_header?=
Date: Tue, 11 Sep 2018 19:38:50 +0100
Message-ID: <013501d449fe$b0c8fdb0$125af910$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-gb
Thread-Index: AQDV+m6+F4wv1k2JYB5bOMwfBLmDPgHiGAhXptjzgqA=
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--29.965-10.0-31-10
X-imss-scan-details: No--29.965-10.0-31-10
X-TMASE-Result: 10--29.964700-10.000000
X-TMASE-MatchedRID: oCj5caaCQynxIbpQ8BhdbPSG/+sPtZVkmX+W7bzPOQFaW2Ktn+I8/pyZ alSnLCVIph/OzJf/7bkxZ8+oiE3cnh0QUKM89Lf/cFEiuPxHjsWpS1IcgR2OVeeU0qFv58B+2sw xlZZYMJb6fh7Gby2lhmSUuunL25rMnlErTusSGI7huXUWQoMQt0bxaqRa2zEnIzZoH7yD1jkh9V qlLDyFJ6cQbFf5rB7Z5BXdEa+ce6AYGe03I+tEG/HkpkyUphL9Ud7Bjfo+5jRm60OoujMOyD11q DA2H+Xs2kRzGl6S5/yWEQ+RJFzGePR3YoE94O3maK+MsTwM+1m7nrAU9KQxUQO8d6V+7Z3kLF9j bxvK1+0ulO0XeElYFDgdvawbawJhCvn9xYwhrzdz66p2XXyYb4yzstdwoG+PnvbaEOoeixMDh5X rP5wcJ9uby94P6riX2EO1L5PxD2540l79WciJA0g5Iem1vm3HSuH+GfgmQGfB/4XKmNIF87zEmY k5Fxj0rQMtru+Y0LfebkARRkUORIdM1kFwmWfIsTcWkxuDrdJBrawMcuRDTh9Oluq8LbzVBpNqU zwLvvcriEKQi78d2LkHhjsSvLOTzgwQym5ivaV/a81MWY5txdFqG4/BpDVagrAXgr/AjP1avhXz gDZvO/7rO/qa2ByAX7bicKxRIU23sNbcHjySQSs3zPQeiEbe+gtHj7OwNO0CpgETeT0ynA==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
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 18:39:01 -0000

Pretty much agree with Robert here.

Can live with it, and some rule will be more helpful than no rule.

But there may be an issue caused by talking about "complying with an RFC". What we want to do is implement protocols in a way that ensures interoperability. So what Robert says about "changing the protocol defined in the updated document in an essential way" is the language I'd prefer. 

I guess people are worried that their "compliant" implementation will suddenly be declared "non-compliant" by the publication of an "Update". That's a good worry, but we should recall that if a spec is broken, then the implementation is also broken and claiming compliance won't help. So, yes, adding features in a backward compatible way is not an Update.

As I said, and just like Robert, I can live with what's proposed. Just would prefer it different.


> -----Original Message-----
> From: ietf [] On Behalf Of Robert Sparks
> Sent: 11 September 2018 19:09
> To: Ben Campbell;
> Cc: The IESG
> Subject: Re: Proposed IESG Statement on the use of the “Updates” header
> I can live with this statement, but I don't like it.
> I'm in the camp that prefers the more specific "This changes the code
> you need to write" camp - I would prefer Update be restricted to the
> cases where you are changing the protocol defined in the updated
> document in an essential way. The use of extension points doesn't cross
> that bar. So, count me as against everything in the second paragraph
> beyond the first sentence.
> That said, I again note that I can live with what's proposed.
> RjS
> p.s. I assume you've rehashed previous IESGs discussions of adding a
> "See Also" relationship?
> On 9/11/18 10:55 AM, Ben Campbell 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.
> >
> >