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

[Ted Hardie <[e-mail]>]

On Wed, Aug 16, 2017 at 8:03 AM, Ben Campbell <[e-mail]> 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