Re: Proposed IESG Statement on the use of the “Updates” header
Ben Campbell <ben@nostrum.com> Tue, 11 September 2018 16:40 UTC
Return-Path: <ben@nostrum.com>
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 3D7B9130F19; Tue, 11 Sep 2018 09:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3xgUUmxT1Z9; Tue, 11 Sep 2018 09:40:56 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40CC91293FB; Tue, 11 Sep 2018 09:40:56 -0700 (PDT)
Received: from [10.0.1.95] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (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 ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.95]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <F97F111E-D401-4585-B5EF-BA5F4CD870E1@nostrum.com>
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: Re: Proposed IESG Statement on the use of the “Updates” header
Date: Tue, 11 Sep 2018 11:40:48 -0500
In-Reply-To: <007801d449ec$e850b5a0$4001a8c0@gateway.2wire.net>
Cc: "ietf@ietf.org" <ietf@ietf.org>, The IESG <iesg@ietf.org>
To: tom petch <daedulus@btconnect.com>
References: <59F6DED7-8D39-4206-8268-22AB6A99A876@nostrum.com> <007801d449ec$e850b5a0$4001a8c0@gateway.2wire.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Uu5HG_iu-g4XJxmhv3bbQ2IgEwE>
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:41:04 -0000
> On Sep 11, 2018, at 11:31 AM, tom petch <daedulus@btconnect.com> 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. Thanks! Ben. > > Tom Petch > > > ----- Original Message ----- > From: "Ben Campbell" <ben@nostrum.com> > To: <ietf@ietf.org> > Cc: "The IESG" <iesg@ietf.org> > 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. >
- Proposed IESG Statement on the use of the “Update… Ben Campbell
- Re: Proposed IESG Statement on the use of the “Up… tom petch
- Re: Proposed IESG Statement on the use of the “Up… Ben Campbell
- Re: Proposed IESG Statement on the use of the “Up… Paul Wouters
- Re: Proposed IESG Statement on the use of the “Up… tom petch
- Re: Proposed IESG Statement on the use of the “Up… Robert Sparks
- Re: Re: Proposed IESG Statement on the use of the… Michael Richardson
- Re: Proposed IESG Statement on the use of the “Up… Kathleen Moriarty
- Re: Proposed IESG Statement on the use of the “Up… Bob Hinden
- RE: Proposed IESG Statement on the use of the “Up… Adrian Farrel
- Re: Proposed IESG Statement on the use of the “Up… Ben Campbell
- Re: Proposed IESG Statement on the use of the “Up… Ben Campbell
- RE: Proposed IESG Statement on the use of the “Up… Christer Holmberg
- Re: Proposed IESG Statement on the use of the “Up… Ben Campbell
- RE: Proposed IESG Statement on the use of the “Up… Adrian Farrel
- Re: Proposed IESG Statement on the use of the “Up… Ben Campbell
- Re: Proposed IESG Statement on the use of the “Up… Brian E Carpenter
- Re: Proposed IESG Statement on the use of the “Up… Robert Sparks
- Re: Proposed IESG Statement on the use of the “Up… Donald Eastlake
- Re: Re: Proposed IESG Statement on the use of the… Michael Richardson
- Re: Proposed IESG Statement on the use of the “Up… Sean Turner
- Re: Proposed IESG Statement on the use of the “Up… Paul Hoffman
- Re: Proposed IESG Statement on the use of the “Up… Julian Reschke
- Re: Proposed IESG Statement on the use of the “Up… Michael Richardson
- Re: Proposed IESG Statement on the use of the “Up… Adam Roach
- Re: Proposed IESG Statement on the use of the “Up… Stephen Farrell
- Re: Proposed IESG Statement on the use of the “Up… Adam Roach
- Re: Proposed IESG Statement on the use of the “Up… Ted Lemon
- Re: Proposed IESG Statement on the use of the “Up… Paul Hoffman
- Re: Proposed IESG Statement on the use of the “Up… Stephen Farrell
- Re: Proposed IESG Statement on the use of the “Up… Brian E Carpenter
- Re: Proposed IESG Statement on the use of the “Up… Heather Flanagan (RFC Series Editor)
- Re: Proposed IESG Statement on the use of the “Up… Heather Flanagan (RFC Series Editor)
- Re: Proposed IESG Statement on the use of the “Up… Spencer Dawkins at IETF
- Re: Proposed IESG Statement on the use of the “Up… Heather Flanagan
- Re: Proposed IESG Statement on the use of the “Up… Lars Eggert
- RE: Proposed IESG Statement on the use of the “Up… Roni Even (A)
- Re: Proposed IESG Statement on the use of the “Up… Benjamin Kaduk
- Re: Proposed IESG Statement on the use of the “Up… Brian E Carpenter
- Re: Proposed IESG Statement on the use of the “Up… Ben Campbell
- Re: Proposed IESG Statement on the use of the “Up… Robert Sparks
- Re: Proposed IESG Statement on the use of the “Up… Brian E Carpenter
- Re: Proposed IESG Statement on the use of the “Up… Benjamin Kaduk
- Re: Proposed IESG Statement on the use of the “Up… Abdussalam Baryun
- Re: Proposed IESG Statement on the use of the “Up… Ben Campbell