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

Donald Eastlake <d3e3e3@gmail.com> Wed, 12 September 2018 03:31 UTC

Return-Path: <d3e3e3@gmail.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 D70BA130DDF; Tue, 11 Sep 2018 20:31:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jisYNxwray0p; Tue, 11 Sep 2018 20:30:59 -0700 (PDT)
Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 13EB4130DC1; Tue, 11 Sep 2018 20:30:59 -0700 (PDT)
Received: by mail-it0-x22f.google.com with SMTP id u13-v6so1191824iti.1; Tue, 11 Sep 2018 20:30:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=A02UjEwGUVIWdyXfU94dBS4g3i2xSHifnAzRjb0sQTo=; b=dUJL6t3fp3g1VwVeXjiFN8QyaJ5kYFybTcLJNeM5tjUFGMiyPcSk+FP07rKEZqqLdm lVUsfuSJU16jkCQK9z2DsfyNld4dz17cxzoc+NDNrGOgfK+TjtK2Au12rarA0e6cNyz4 zYccIvpKdfHn0WlrErmX2zhqN7f6Di2K14PKKY+cMRslYA/eVG8BwSX5Faey7/eoqJO0 lSZDkUlt19z33TELuUqhQ4GnwhtdFced/xkWpwupWLhqaIDJdeYJ2dyd7bvwiHqYrS04 qngWcyI9yHeQvkaQ+70R60s1xXsTxhLVM4b0vnWXXEJWBNnB4wzWOLsyoKN/iccQdHeN P5tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=A02UjEwGUVIWdyXfU94dBS4g3i2xSHifnAzRjb0sQTo=; b=sxk2f2Ih66NggQH0RahwzDweqKHOCcTFKcBI2fqmz6AmPb96Ao9zZmJ7pA/0hYYR1Q dQ/xEW9rvyuZKHOr9M84cGde4LzObCZX5P2yR+0EIDDaEPT0XBzgcTl7e1ZJkTL+1AYD jE5es93GW2yvelJ61yS48hDZkuP73yG1ux+FQW80F4XhlsVoTPclI9nOliJEopbKlzie 2SaQU4SZVFOUgOXenblplaerEeVhC6fmXHB8lbVGkpRBoEIL3/cFnI8TMeRq8E6C29u6 dbVWqPDQOyKKprC92Zj/wp2N0Xy6fO7TDlkh0+sVnYGk+5wD9RiehbhepVvGue8yp971 Aeaw==
X-Gm-Message-State: APzg51DEaU293W0iGp5mdpduZF3JOfbmHWrKNoftO8Jn2MIxfDmv2PNa vjJGmCwEQ769UFU+VfoCF1epKD2a+lWDu1oFuFgI3g==
X-Google-Smtp-Source: ANB0VdYEfcLYXczePnGKXfozq9hD9rsnjTJPW0akHyp+R+U3ToYnD9OsaQQ6n+JyGr6keACVQplzleXhkHw6G/2TdYE=
X-Received: by 2002:a24:17d2:: with SMTP id 201-v6mr249319ith.0.1536723057878; Tue, 11 Sep 2018 20:30:57 -0700 (PDT)
MIME-Version: 1.0
References: <59F6DED7-8D39-4206-8268-22AB6A99A876@nostrum.com> <9a505c33-3327-a13f-f5ce-4fac360169b1@nostrum.com> <5d328d01-1ed6-3d0a-d250-d70fdaad00ff@gmail.com>
In-Reply-To: <5d328d01-1ed6-3d0a-d250-d70fdaad00ff@gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, 11 Sep 2018 23:30:45 -0400
Message-ID: <CAF4+nEFi7yOxgNi63ji1A8BeC_Y7qmH5hmep4jUJpJ59b4BPWA@mail.gmail.com>
Subject: =?UTF-8?Q?Re=3A_Proposed_IESG_Statement_on_the_use_of_the_=E2=80=9CUpd?= =?UTF-8?Q?ates=E2=80=9D_header?=
To: IETF Discussion <ietf@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/pf9KUqYca7X7tZL3TZOdDSh6SJU>
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 03:31:01 -0000

This does document a change that has occurred. In the past, it was
common for important extension RFCs to have an Updates header pointing
to the RFC that they extended.

I don't object to the change in Updates but I do object to the loss of
the ability to have a simple title page pointer on a RFC to RFCs it
updates in a important way. Please add an optional "Extends:" header
to the title page to preserve the previous functionality.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e3e3@gmail.com

On Tue, Sep 11, 2018 at 4:57 PM Brian E Carpenter
<brian.e.carpenter@gmail.com>; wrote:
>
> On 2018-09-12 06:08, Robert Sparks wrote:
> > 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 IAB already opined indirectly on this topic.
> https://tools.ietf.org/html/rfc6709#page-5 says:
>
> >>>    Extension designers should examine their design for the following
> >>>    issues:
> >>>
> >>>    1.  Modifications or extensions to the underlying protocol.  An
> >>>        extension document should be considered to update the underlying
> >>>        protocol specification if an implementation of the underlying
> >>>        protocol would need to be updated to accommodate the extension.
> >>>        This should not be necessary if the underlying protocol was
> >>>        designed with a modular interface.
>
> (followed by more detailed discussion).
>
> I'm not sure the IESG text is 100% compatible with this.
>
> > nor do they, by themselves, imply that implementers must implement the updating RFC to continue to comply with the updated one.
>
> seems to be going to far. It may be the intent of the update that
> implementations *need* to be updated, because the update fixes a bug.
> In that case, "updates" really means "partially obsoletes".
>
> Another point: the statement is scoped to the IETF stream. But it would
> be much better if all RFC streams use the same semantics. I'd like to
> hear from the RFC Series Editor on this.
>
>      Brian
>
> > 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.
> >>
> >>
> >
> >
>