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

Benjamin Kaduk <kaduk@mit.edu> Thu, 13 September 2018 13:34 UTC

Return-Path: <kaduk@mit.edu>
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 C10DC12DD85; Thu, 13 Sep 2018 06:34:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 NYKNMyNWiX3e; Thu, 13 Sep 2018 06:34:25 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 D6B69130DD1; Thu, 13 Sep 2018 06:34:24 -0700 (PDT)
X-AuditID: 12074424-239ff700000025eb-ca-5b9a675d66dd
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 9F.88.09707.E576A9B5; Thu, 13 Sep 2018 09:34:23 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w8DDYHH3025800; Thu, 13 Sep 2018 09:34:18 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w8DDYBhL025217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Sep 2018 09:34:14 -0400
Date: Thu, 13 Sep 2018 08:34:11 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Ben Campbell <ben@nostrum.com>, ietf@ietf.org, The IESG <iesg@ietf.org>
Subject: Re: Proposed IESG Statement on =?utf-8?Q?t?= =?utf-8?B?aGUgdXNlIG9mIHRoZSDigJxVcGRhdGVz4oCd?= header
Message-ID: <20180913133411.GX48265@kduck.kaduk.org>
References: <59F6DED7-8D39-4206-8268-22AB6A99A876@nostrum.com> <9a505c33-3327-a13f-f5ce-4fac360169b1@nostrum.com> <5d328d01-1ed6-3d0a-d250-d70fdaad00ff@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5d328d01-1ed6-3d0a-d250-d70fdaad00ff@gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42IRYrdT141PnxVtsHQ1u8X8ztPsFm0X9zFZ zPgzkdni2cb5LA4sHjtn3WX3WLLkJ5PHrJ1PWAKYo7hsUlJzMstSi/TtErgy9py/ylKwib9i ztFNLA2Mv7m7GDk5JARMJB78Ws7axcjFISSwmEli3+EfzCAJIYGNjBIX/5RC2FeZJD5szgax WQRUJfbd+sUEYrMJqEg0dF8GqxcRMJZo7DrNCmIzC3hLzPl1ixHEFhbIl/j09wZYPS/Qsrmb ljJBLFvGKNG2pxcqIShxcuYTFohmLYkb/14CxTmAbGmJ5f84QExOAVuJF2tdQSpEBZQl9vYd Yp/AKDALSfMsJM2zEJoXMDKvYpRNya3SzU3MzClOTdYtTk7My0st0jXXy80s0UtNKd3ECA5g F5UdjN093ocYBTgYlXh4b4jMjBZiTSwrrsw9xCjJwaQkytuzGyjEl5SfUpmRWJwRX1Sak1p8 iFGCg1lJhHd96KxoId6UxMqq1KJ8mJQ0B4uSOO953cnRQgLpiSWp2ampBalFMFkZDg4lCd7g NKBGwaLU9NSKtMycEoQ0EwcnyHAeoOF2qSDDiwsSc4sz0yHypxiNOdqO909i5vjzfuokZiGW vPy8VClx3qMgpQIgpRmleXDTQElIInt/zStGcaDnhHlngizlASYwuHmvgFYxAa36vGcGyKqS RISUVANjukVWsFXosU7l1WIlc7bsDW2Lzvj8bx5P8u+QbXxFL7mYwp7GvU2f+nFHa8IuP6af j0/NXinR/zv/waL7eWb5FrVVTI7BMT/ubM4SLe2Jrud7dsNuU1r3/ZOLJjg9KF7NdaBn0QQv /qVs7X257TYX8kydp25IEJzBMW31O7NLT3616d1e8HuREktxRqKhFnNRcSIAep9IRh0DAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/j9iYIkTnUGrgOXH5iPvdA4yixVw>
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 13:34:27 -0000

On Wed, Sep 12, 2018 at 08:56:23AM +1200, Brian E Carpenter 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.

I believe it was intended to be, and I'm not sure what incompatibility you
are seeing; could you say more?

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

Is there anything stopping the body text of the document from saying "this
document updates [foo] by obsoleting the completely broken bits that do
[bar]"?

Namely, the *keyword* does not indicate that you must update
implementations.  The body text can try really hard to say that you should
do so, though.

-Ben