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

tom petch <> Tue, 11 September 2018 16:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7B45130E5F; Tue, 11 Sep 2018 09:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.188
X-Spam-Level: ***
X-Spam-Status: No, score=3.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d5OfOGiJKO0n; Tue, 11 Sep 2018 09:58:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 16449124BE5; Tue, 11 Sep 2018 09:58:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=doDMXYED/gejlB0zE0AGf+bpIz+CWUXbKEGrQQeznGY=; b=PbizBEUKUms2yWd1H+xt0xfWbeyL7ZHhv/l3NdCI7oIPBc2xj0ZW9yAju5FI4ayLzKLqQ4QlkRYgQCEEQBQm2ovmaIw4bI9Hr6ERLaOYXKwXUHHBoPmVOTkvJXgWTKQ6e09BSDUg0HvbMdNa1XceMGct3ld8ctd3naBBytxFRXg=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1143.8; Tue, 11 Sep 2018 16:58:42 +0000
Received: from ([fe80::31e4:54f6:8b2b:fbf5]) by ([fe80::31e4:54f6:8b2b:fbf5%3]) with mapi id 15.20.1143.010; Tue, 11 Sep 2018 16:58:42 +0000
From: tom petch <>
To: Ben Campbell <>
CC: "" <>, The IESG <>
Subject: =?utf-8?B?UmU6IFByb3Bvc2VkIElFU0cgU3RhdGVtZW50IG9uIHRoZSB1c2Ugb2YgdGhl?= =?utf-8?B?IOKAnFVwZGF0ZXPigJ0gaGVhZGVy?=
Thread-Topic: =?utf-8?B?UHJvcG9zZWQgSUVTRyBTdGF0ZW1lbnQgb24gdGhlIHVzZSBvZiB0aGUg4oCc?= =?utf-8?B?VXBkYXRlc+KAnSBoZWFkZXI=?=
Thread-Index: AQHUSezvqzsZpbqxFU20jPn/VvpW3Q==
Date: Tue, 11 Sep 2018 16:58:42 +0000
Message-ID: <010901d449f0$aad12940$>
References: <> <007801d449ec$e850b5a0$> <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-clientproxiedby: LNXP265CA0053.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5d::17) To (2603:10a6:203:e::7)
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2433; 6:3uTgXyXVUbThn696LL4WL+sfubxqFx9s2+f7RQw41+MbQkd47wdqPKP1BBBUApohIZpkTBKGT8MQHa8N6mF4S3xVLLlO/SHygfoq3UiIQax/0sp7nUTET8UYLVHlKpXpUCM8kax4+aAIBlBNDg1JuADdGIuSUTYaaFRN8wiGs2VnnefqQAsT4GosAZvXcxnVAR3xzbZHtPMRTDTwWa9erNX6H1oYhjW31ZTc9ap6jLSGkg7NwiWrg7mOGT2Z2ZHQPHR/OMJGzcOSNkWr8fN0W3kwVJWzGN+3wjV/+8SCdusMQSoOvEuUQLHECg0m06SUszpKH626yD8U7IbTFfCHHpKM8UQxLwqYTU4OENW9Pfz/f7a4m6Ydt55B9+Znba1bq5W9mbShv1AWwFTUPNZJCK0g5dIg109CkSvb/cjUPFCc38ja9X1tPKfPHEFiTmxA16qpawizv4UcmFzjQMuzBg==; 5:rIGJ/1lIx3ovylNFv6J86/lYB00B7JsuRnuULjukMTCe7cf7qbBjcbsUmP6Gp14LrrkvPx4wrFpGyyN3f24kvYRyu84G1gSEWPmeOLVSUJvfhJOfUgBF3wlu5Pmj5r2wv903iW+Vmx6JCZeKH2D+t4GKyPL6bJyTuDKd15MBE3o=; 7:KGtRgmM4ot2JFj4cEH7JW6Spx3Z4RJEOa8q5y1z4zgBfV9UtZZBkA4XWhFQj+fUSrUKVzHGm0kC6dsNaWkM0vwu4Sgf4sg10CM/KOZ15Fbz6EPZGr9OCItI0HWvR2DCcJqj2fEpyEw3IE6hjPAJTUY4DX6YIkSRhlMEfvzRm1dllipEN+wq9eGbAo6Mt3dDLDr/a1zxo5Zc/zDnbIrSdHe3LZWeHscLXzrcxLIsbsM07EsQXbAOd+ceU7iI+PNbJ
x-ms-office365-filtering-correlation-id: 215747d8-04f5-4564-9ee8-08d61807d412
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7193020); SRVR:AM5PR0701MB2433;
x-ms-traffictypediagnostic: AM5PR0701MB2433:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(178726229863574)(192374486261705)(219612443155931)(788757137089);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231311)(944501410)(52105095)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699050); SRVR:AM5PR0701MB2433; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2433;
x-forefront-prvs: 0792DBEAD0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(346002)(396003)(366004)(39860400002)(199004)(189003)(13464003)(53754006)(6116002)(446003)(2906002)(6916009)(68736007)(3846002)(106356001)(66066001)(105586002)(5250100002)(99286004)(2900100001)(5660300001)(14496001)(186003)(26005)(486006)(6506007)(53546011)(386003)(102836004)(54906003)(15650500001)(476003)(4326008)(6246003)(33896004)(25786009)(7736002)(305945005)(84392002)(14454004)(478600001)(76176011)(44736005)(6436002)(86362001)(86152003)(9686003)(6512007)(316002)(6486002)(256004)(229853002)(14444005)(8936002)(97736004)(81156014)(53936002)(81166006)(1556002)(52116002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2433;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: VbOdfesIGXF8SLLA+cbKedanKB1abah2IiZqd+A6ZAYshW0OSAvEOIpcSl3dC5zS6gJWlSUq38Kah+w4yoPzb1WE+EOubP4ViaNE0URq0HD+mznJJpiDQt8evGHXYXOYZZ4Jwyp5yDIWHV7cBXIqEjJ26RPMQJJaU1flLYjfjS92xlCqpM+kwpYSwlq+hD/vbIuQ16VsKSVm/k8H92mkiLZafe0HWqZt8w8jmOVd3niKBGqy9rYTK5ipOISy7sMHGHhsYMG5dS3zIH9evS0A1Bi1VzOYQ8loojfxZzqhHTyzbBunHR5byf5OFufTWLisgbbTkvH8o06s1kACfeUiS+83QUbMRrz8NGAi3DHexiY=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 215747d8-04f5-4564-9ee8-08d61807d412
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2018 16:58:42.3675 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2433
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:58:48 -0000

----- Original Message -----
From: "Ben Campbell" <>
Sent: Tuesday, September 11, 2018 5:40 PM

> On Sep 11, 2018, at 11:31 AM, tom petch <>
> Ben
> I don't understand it! In particular
> 'Normative updates that do not use a known extension point should
> include an “Updates” header.'
> leaves me ignorant.
> 'Normative' I am well familiar with from I-D references but that
> 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?


No:-(  I understand your explanation and see that concept in many
places, but do not know of any generic term for it.  (Thus I think of
YANG augments, but that term would probably not make sense to those not
versed in YANG). Rather, I would like to see your sentence of
explanation or something like it in the statement.

Tom Petch

> To give a practical problem; when an I-D adds new entries to an
> registry, is that an 'Updates'?  I have seen ADs firmly tell WG
> holding the contrary opinion, that it is not, and I thought that that
> was settled, but applying this statement to that situation leaves me
> 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
> 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
> formal meaning of the “Updates” / "Updated by" relationship in IETF
> stream RFCs. The “Updates” header has been historically used for
> of reasons of various strength. For example, the “Updates” header may
> 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,
> 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
> 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
> the update. Normative updates that do not use a known extension point
> should always include an “Updates” header. Extensions that do use
> extension points do not typically need to include the “Updates”
> 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
> 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
> header rather than the “Updates” header. The “Updates” header should
> used to flag updates to published RFCs; it is not appropriate to
> “Update” an Internet-Draft.