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

Michael Richardson <mcr@sandelman.ca> Wed, 12 September 2018 12:42 UTC

Return-Path: <mcr@sandelman.ca>
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 79C89130E2F; Wed, 12 Sep 2018 05:42:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 2ZM79LW_rW9M; Wed, 12 Sep 2018 05:42:22 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2568130DEE; Wed, 12 Sep 2018 05:42:21 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6EAA620491; Wed, 12 Sep 2018 09:01:18 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 03205230; Wed, 12 Sep 2018 08:42:20 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id F418712F; Wed, 12 Sep 2018 08:42:20 -0400 (EDT)
From: Michael Richardson <mcr@sandelman.ca>
To: Donald Eastlake <d3e3e3@gmail.com>
cc: IETF Discussion <ietf@ietf.org>, "iesg\@ietf.org" <iesg@ietf.org>
Subject: Re: Re: Proposed IESG Statement on the use of the =?utf-8?B?4oCc?= =?utf-8?B?VXBkYXRlc+KAnQ==?= header
In-Reply-To: <CAF4+nEFi7yOxgNi63ji1A8BeC_Y7qmH5hmep4jUJpJ59b4BPWA@mail.gmail.com>
References: <59F6DED7-8D39-4206-8268-22AB6A99A876@nostrum.com> <9a505c33-3327-a13f-f5ce-4fac360169b1@nostrum.com> <5d328d01-1ed6-3d0a-d250-d70fdaad00ff@gmail.com> <CAF4+nEFi7yOxgNi63ji1A8BeC_Y7qmH5hmep4jUJpJ59b4BPWA@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Wed, 12 Sep 2018 08:42:20 -0400
Message-ID: <3084.1536756140@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/4fYHS4sIx-woz5DatVPARTf3HdI>
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 12:42:49 -0000

Donald Eastlake <d3e3e3@gmail.com>; wrote:
    > 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 think that the IESG proposes to remove this use.
I think that they intend to explicitely support it.
However, not every allocation by document Y of a registry from document X, is
an Updates: to X.

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