Re: [Webpush] Breaking Changes (was Re: Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT))

Ted Hardie <ted.ietf@gmail.com> Wed, 16 August 2017 16:10 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: webpush@ietfa.amsl.com
Delivered-To: webpush@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13951132630; Wed, 16 Aug 2017 09:10:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 EKIN2c3YgmTi; Wed, 16 Aug 2017 09:10:33 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 C97A11321A0; Wed, 16 Aug 2017 09:10:32 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id d207so713205qkg.2; Wed, 16 Aug 2017 09:10:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eQSnHSQrKxI/TpHCmKtV6Wh8zO3vAJquCLm4pOTRtfQ=; b=Ai1jFz1yLqdC6tPK9xA3hHh5/mX0kotZXwGx5TbgV80iEW5+MNXOrap5e4M4GyeZdh 0fLYw8GcicdRP6Y7+IE0hxN2LzBPMeOcc/Z0qLbqmYnzdAQFlMlyTrANktR158LZI+AL WBCxYb35KePgZEl+i4Oaka6hPWHiJkClPiK3L3s9kV0ikK1FUM0doW/BeshSZIascTWN U4KLn33wC3EgpApJBEcX9E6Dp7L15HbAZxczhjobVPgpexJAD9YCHpfY+G1IIQ7kNOuQ O32aTzuriQojrOQ6MSGCWL8oQhi45gvyvAB+JPeXtNFKBv6hSB84ImQBpUrjWgdAFf47 cSFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eQSnHSQrKxI/TpHCmKtV6Wh8zO3vAJquCLm4pOTRtfQ=; b=YvmikGJaOdmXz4JLqiwKeoQhy7ddAWYJP+UTsvoM8v28CVfsWojjsHl0bMTjN9fYVy qWeGJB5GnDqvsdWmh66W+Y9YqaS5pMvNvwWJkALjTkl4ro7xL+vyyHmu4v/zyF7Bp29F 2xNkb2iKujzS44BLrXEeXZLxR2t1tR+DG898cQF6DcOLe4qyMXZy79Pkk53b4tpa+1Xw MNNVpn10HhEyPcG4SQVTW0PGTBMbJORj3wu+tcDV1og0bFgqSLkjXxwL60qR9tyYB7t/ LeeEz5A1RZs/O1vKNs6wtY6CCvR1kkaR0Jg+P3P9jhaumBhnPGEsXtVyCKAiQLf0rnV5 R2Zw==
X-Gm-Message-State: AHYfb5idegCrpCcleZkSCI8v082HfqMX7iXjaoKhHrfjI8LN1APHwk7v bNAAeNVPCK9YpaA3/GQHoz0D9ImzSA==
X-Received: by 10.55.20.220 with SMTP id 89mr2792938qku.94.1502899831760; Wed, 16 Aug 2017 09:10:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.59.248 with HTTP; Wed, 16 Aug 2017 09:10:01 -0700 (PDT)
In-Reply-To: <B97F4F26-346B-45EB-8830-412110700BBD@nostrum.com>
References: <150284054989.12518.11340069078773708886.idtracker@ietfa.amsl.com> <CABkgnnXwUpp4A=V6gNXoK+Q6LatCHFoB59+xVd0RxQ96Y5gfaQ@mail.gmail.com> <CABcZeBP1Ej2Dd7rPTn6Sq3uVLA1gPHBSRSQR2Fam_mxJqcQgig@mail.gmail.com> <4125C183-E369-47EA-999A-0080BDF01B4A@nostrum.com> <716e5820-e57f-b7c9-b3b4-3cf387409575@nostrum.com> <CABkgnnWG8dDMAZe0MdAf0D7WE1jzA+yPJEAMsH9siL56cNbz1Q@mail.gmail.com> <972ccc4e-da47-cb56-addc-ba7b02b94e67@nostrum.com> <CABkgnnWqCct9J+SrC+_=Pyf-V0WsCyvStBmxZh3F-OV5QXwDzA@mail.gmail.com> <B97F4F26-346B-45EB-8830-412110700BBD@nostrum.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 16 Aug 2017 09:10:01 -0700
Message-ID: <CA+9kkMAFXZsxhciviLS+kbdnoSxpc9PFi=8Q9_cFkHF-4uRrOQ@mail.gmail.com>
To: Ben Campbell <ben@nostrum.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Eric Rescorla <ekr@rtfm.com>, Adam Roach <adam@nostrum.com>, draft-ietf-webpush-vapid <draft-ietf-webpush-vapid@ietf.org>, Phil Sorber <sorber@apache.org>, The IESG <iesg@ietf.org>, webpush-chairs@ietf.org, "webpush@ietf.org" <webpush@ietf.org>
Content-Type: multipart/alternative; boundary="001a1144c1949aedb00556e12299"
Archived-At: <https://mailarchive.ietf.org/arch/msg/webpush/b51BF7j1afLObjQbqf-0i9GISvw>
Subject: Re: [Webpush] Breaking Changes (was Re: Eric Rescorla's Discuss on draft-ietf-webpush-vapid-03: (with DISCUSS and COMMENT))
X-BeenThere: webpush@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <webpush.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webpush>, <mailto:webpush-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webpush/>
List-Post: <mailto:webpush@ietf.org>
List-Help: <mailto:webpush-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webpush>, <mailto:webpush-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Aug 2017 16:10:35 -0000

On Wed, Aug 16, 2017 at 8:03 AM, Ben Campbell <ben@nostrum.com>; wrote:

> From a general policy perspective, I think there are two principles:
>
> 1. The IETF maintains change control on IETF stream documents. That
> suggests we can change things at any time.
>
> 2. Working code matters.
>
> How you balance the two depends on the context. We encourage early code.
> But that’s not necessarily the same as encouraging going production with
> early code. It’s reasonable to push back on gratuitous changes if code
> demonstrates things already work well. But I think the usual basis of such
> an argument is that the existing protocol has been proven to work as is,
> not that the weight of that code makes it too hard to change.
>
>
I think one way of looking at the context is to look at the reason for the
code.

Code built explicitly to test a particular approach can change at any time
that the approach needs to change; we get to presume that sort of code
doesn't underpin any running systems and that the friction to change is
thus very low.

Code that is currently deployed in production systems can be very difficult
to change and deciding to change it may break interoperability. In some
cases it may permanently change the community of use for a protocol (some
changes to JSEP, for example, would break its ability to interoperate with
deployed non-browser systems, thus changing the community of use).

The reality is that there almost no code purely in category one and a lot
of IETF draft code hasn't been deployed at scale enough to be in category
two.   Lars' and Christian's implementation of QUIC demonstrate that one
isn't gone completely, but almost all code written for IETF standards is
intended for production systems eventually.  It lives in a gray area
between the two poles above; changing it requires resources and time but
does not change deployed systems.  Changes are costs, in other words, that
are incurred by the developer prior to getting to deploy.

 Pushing back on changes to "gray code" is entirely normal, and you can see
that play out inside working groups as different parties determine whose
code has to change to meet a requirement or solve a problem.  Inside a
working group, the weight of the code does matter.  A two-line changes to a
server may result in the same behavior as a new module for the client, and
the working group should take that into account.

Where the IESG analysis is a bit different is that it has to take into
account the value of the change not just to the current writers of code,
but for anyone implementing the spec later and to the users of the
protocol.  That change in context of interpretation tends to make the IESG
a bit more willing to require changes to gray code than a working group
would be; its collective thumb is lightly on the scale of the future
implementers and users.

I personally think that's a reasonable result and part of the division of
labor, but I also think the IESG has to do so knowingly and make that
transparent to the community.  That means that we probably should drop "you
paid your money and knew the risks" as messaging for late code change.
Perhaps "we recognize the costs here but believe they are balanced,
especially when considering new implementations which may arise" would be
better PR.

Take that advice with a large grain of salt, though, as no one has ever
suggested I was good at PR.

regards,

Ted