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

Benjamin Kaduk <kaduk@mit.edu> Fri, 14 September 2018 02:27 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 A2D4A130DFA; Thu, 13 Sep 2018 19:27:38 -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 Mw57Y9Zt3bBY; Thu, 13 Sep 2018 19:27:37 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 D25FC130DDE; Thu, 13 Sep 2018 19:27:36 -0700 (PDT)
X-AuditID: 1209190c-b61ff700000066d5-c0-5b9b1c970b76
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 04.04.26325.79C1B9B5; Thu, 13 Sep 2018 22:27:35 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w8E2RXso029981; Thu, 13 Sep 2018 22:27:34 -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 w8E2RTPk031699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Sep 2018 22:27:31 -0400
Date: Thu, 13 Sep 2018 21:27:29 -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: <20180914022728.GF48265@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> <20180913133411.GX48265@kduck.kaduk.org> <6c53ae18-a827-aff6-d0b2-0d04f95ed106@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6c53ae18-a827-aff6-d0b2-0d04f95ed106@gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmleLIzCtJLcpLzFFi42IR4hTV1p0uMzvaYMsNWYv5nafZLdou7mOy mPFnIrPFs43zWRxYPHbOusvusWTJTyaPWTufsAQwR3HZpKTmZJalFunbJXBlLJm0lbXgoFDF zSM72BsYN/J1MXJySAiYSFya/Zmli5GLQ0hgMZPEqwX7GUESQgIbGSWaJwpDJK4ySVycfYQd JMEioCpxbc0EFhCbTUBFoqH7MjOILSJgLNHYdZoVxGYW8JaY8+sW2CBhgXyJT39vMIHYvEDb dk79wwaxoIVJ4s+WUIi4oMTJmU9YIHq1JG78ewlUzwFkS0ss/8cBEuYUsJX4/r8PbIyogLLE 3r5D7BMYBWYh6Z6FpHsWQvcCRuZVjLIpuVW6uYmZOcWpybrFyYl5ealFuoZ6uZkleqkppZsY wSEsybOD8cwbr0OMAhyMSjy8Ds9nRQuxJpYVV+YeYpTkYFIS5S1cCxTiS8pPqcxILM6ILyrN SS0+xCjBwawkwrs+FCjHm5JYWZValA+TkuZgURLnPas7OVpIID2xJDU7NbUgtQgmK8PBoSTB e1tqdrSQYFFqempFWmZOCUKaiYMTZDgP0PATIDW8xQWJucWZ6RD5U4zGHG3H+ycxc/x5P3US sxBLXn5eqpQ4b500UKkASGlGaR7cNFAaksjeX/OKURzoOWHefpAqHmAKg5v3CmgVE9Cqz3tm gKwqSURISTUwZr3ReWArH+lr1zXzTIFN0ubcb5r38mNiL/L3qdzMN9SNk94odqqNVbaX58E5 nZ3z9n6WmFlXy+VdMTuw0Dpq9Q6zu8tczlmsjkh5sLRqd8C1H9tsQ4X1RCJav9yU5nNeG1Fz Zubblmah6fmf+yUeu/ZyqL1OqJPecnDzcTfG+asMi0Uv599WYinOSDTUYi4qTgQATe31WR4D AAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/np5p58Ea631XsBInJyGSBF_UxrM>
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: Fri, 14 Sep 2018 02:27:39 -0000

On Fri, Sep 14, 2018 at 08:59:53AM +1200, Brian E Carpenter wrote:
> Hi Ben,
> 
> On 2018-09-14 01:34, Benjamin Kaduk wrote:
> > 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?
> 
> There's a subtlety in this phrase:
>   "would need to be updated to accommodate the extension."
> Even though I'm a co-author of RFC6709, I'm not 100% sure what this means.
> I think it means "if an implementor adds the extension to the code, she must
> also modify the base code". The IAB text seems to be saying that if you add
> a feature that does not *require* a change to the existing code, it's
> not an update. I'm not sure I even agree with that, and I don't think
> the IESG text does either. (If it does, we need a new tag "Extends:".)

Ah, I see what you mean -- thanks.  Our situation seems to be similar to
the distinction between the converse and contrapositive in logic, though --
just because an Updates header is not necessary for this reason, does not
a priori prevent an Updates header from being used for some other reason.

-Ben