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

Sean Turner <sean@sn3rd.com> Wed, 12 September 2018 14:33 UTC

Return-Path: <sean@sn3rd.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 9D7C4130E27 for <ietf@ietfa.amsl.com>; Wed, 12 Sep 2018 07:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
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 j_P5N23SA702 for <ietf@ietfa.amsl.com>; Wed, 12 Sep 2018 07:33:35 -0700 (PDT)
Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (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 04DAF128CB7 for <ietf@ietf.org>; Wed, 12 Sep 2018 07:33:34 -0700 (PDT)
Received: by mail-qt0-x243.google.com with SMTP id o15-v6so2045578qtk.6 for <ietf@ietf.org>; Wed, 12 Sep 2018 07:33:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RwydX5a01inOTMf6IxznD4YmpJ0CD9dfmXSE4hSZngE=; b=jsOUG5zY1YB4G0qQhEns62prkr+Jra4EERdGsOT+YDdJ+3tJRFL58gMg/12rZ156gX a25PrrLi9qUg2/22kdGi3EV45kTk5Aed+nA9ngvwYxQXLxc9ughn69vUpNDD9n+F7cMt jw35nG9u+uwwWWczxo4KLwVU5cd7wSrUGoUEs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RwydX5a01inOTMf6IxznD4YmpJ0CD9dfmXSE4hSZngE=; b=eDS5u9cA0znKplCug8rXWuZ48Qw9FR7LSv6cKFWRp+NIBo9VbQn7xK6AkM9WkmusQg ZNodTBjZ8R89bOXIyYKgteGwZZ8d5VRPGZN/W6yTXmAoMSXsnYZRIEMZYcZ1+dM2H+NE VvBQPU3JTuS7dOLzAbjpX1G1ikn/ls5NRh6GdSO8fqsZ/sNp67+B26sak/wNtzkrhCxA KSzLbI0gZw3vUa5PCbYB7cPFmVUZ+kX7dJ2TzCJMKg32Elnu5rGMGkittaA0/2N+szDZ 6ai+zVDCSBZiWwFoXM2/tkiBw1SNPfoL+WKOhBYi1SQ7wfvBp/rSTejPbbJ3WjCCKONt bGdQ==
X-Gm-Message-State: APzg51DCN8xfHyNoRGOy7CkT/arxnWoWTQj1WIt634E5ch7z0pfjxjdX Fl2KLPxFFIWePqESNV7JSl+kJv57Eh0=
X-Google-Smtp-Source: ANB0VdbdKEgdIB9SfOHqaaVfcL1FwmUtXe2xI5zK2NsVXmerx/6knsProgJV1s59ihGXje/WxZfogA==
X-Received: by 2002:a0c:d19b:: with SMTP id e27-v6mr1658451qvh.41.1536762814119; Wed, 12 Sep 2018 07:33:34 -0700 (PDT)
Received: from [172.16.0.18] ([96.231.216.107]) by smtp.gmail.com with ESMTPSA id z34-v6sm694443qtj.19.2018.09.12.07.33.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Sep 2018 07:33:33 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
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?=
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <59F6DED7-8D39-4206-8268-22AB6A99A876@nostrum.com>
Date: Wed, 12 Sep 2018 10:33:31 -0400
Cc: ietf@ietf.org, The IESG <iesg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <8DA3AA49-BB06-4DA6-A028-F487FC9822EB@sn3rd.com>
References: <59F6DED7-8D39-4206-8268-22AB6A99A876@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/K1aEJ_5yaWj_a8pdV3zWJq9LKGM>
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: Wed, 12 Sep 2018 14:33:37 -0000

Thanks for taking one for the team ;). More below.

> 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.

I like to say that I hate the whole list the reasons why in the abstract.  I understand that we also say what RFCs are updated in the abstract because there are some tools that don’t display the meta-data and that we do it so readers will know whether or not to keep reading.  That’s great for an RFC that’s updating one RFC and it keeps in line with keep the abstract succinct plus the boiler plate on the 1st page.  But, when you’ve got an RFC that’s going to update say eight (8) RFCs that this is kinda crazy.

> 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.

I generally agree with this, but I can see the last sentence sometimes being a thing.  The example you have sounds perfectly reasonable to me, but that’s not why we need these rules ;). Some want their RFC to be “part of” the base specification, and they do it by trying to “link in” with the base specification.  Is “whether it’s import to know about” other RFCs going to become a question in the shepherd write-up or something the IESG asks during it’s evaluation?

> 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.

Just checking - I seem to remember a time when there was draft (not an RFC) that “updated” another draft in the RFC editor’s queue.  I suspect the idea of pulling it back was way more painful that just doing the “updates” header.  That’s still okay right?

Finally, any thought given to going back and retroactively applying these rules to previously published RFCs’ meta-data?

spt