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

"Roni Even (A)" <roni.even@huawei.com> Thu, 13 September 2018 06:57 UTC

Return-Path: <roni.even@huawei.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 E652012D7F8; Wed, 12 Sep 2018 23:57:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 3mKT-jiQtZMF; Wed, 12 Sep 2018 23:57:19 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DEA1130FDF; Wed, 12 Sep 2018 23:57:17 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 83A95EAEF31D4; Thu, 13 Sep 2018 07:57:11 +0100 (IST)
Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 13 Sep 2018 07:57:12 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.23]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0399.000; Thu, 13 Sep 2018 14:57:08 +0800
From: "Roni Even (A)" <roni.even@huawei.com>
To: Robert Sparks <rjsparks@nostrum.com>, Ben Campbell <ben@nostrum.com>, "ietf@ietf.org" <ietf@ietf.org>
CC: The IESG <iesg@ietf.org>
Subject: RE: Proposed IESG Statement on the use of the “Updates” header
Thread-Topic: Proposed IESG Statement on the use of the “Updates” header
Thread-Index: AQHUSegcpKEcdTo6e02xOQBzrgz3x6Tq2wcAgALp9PA=
Date: Thu, 13 Sep 2018 06:57:07 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8D9CEC@DGGEMM506-MBX.china.huawei.com>
References: <59F6DED7-8D39-4206-8268-22AB6A99A876@nostrum.com> <9a505c33-3327-a13f-f5ce-4fac360169b1@nostrum.com>
In-Reply-To: <9a505c33-3327-a13f-f5ce-4fac360169b1@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.202.55]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/161iDxA7xTZpPW3vTCrO5PpuXBM>
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: Thu, 13 Sep 2018 06:57:25 -0000

I am OK with Ben proposal.
I take the word "update" literally, and see the value of "updated by" as a forward reference for anyone who read the updated RFC .  Having "update" in an RFC provides motivation to read the updated RFC and some text about how this new RFC updates the previous one will be helpful. I understand that an RFC can have in the text a statement about updating another RFC with normative reference but it is simpler for a person that is new to a topic to see the linkage between RFCs
 
I am not worried about  implementation issues, "update" is about the content it does not require implementations.

As for  " I would prefer Update be restricted to the cases where you are changing the protocol defined in the updated document in an essential way",  I do not like the term "essential" it may open a can of worms. How do we quantify "essential".  For example a new extension may be "essential" to one usage but may not be totally useless to others. 

Roni


-----Original Message-----
From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Robert Sparks
Sent: Tuesday, September 11, 2018 9:09 PM
To: Ben Campbell; ietf@ietf.org
Cc: The IESG
Subject: Re: Proposed IESG Statement on the use of the “Updates” header

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