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

[Ben Campbell <[e-mail]>]

(Oops ignore the empty message—itchy mousepad finger. Or maybe I want to make sure Martin gets everything twice.)

> On Aug 16, 2017, at 1:22 AM, Martin Thomson <[e-mail]> wrote:
> 
> On 16 August 2017 at 15:41, Adam Roach <[e-mail]> wrote:
>> On 8/16/17 12:09 AM, Martin Thomson wrote:
>>> 
>>> p.s., It's been a while since I've been on the receiving end of the
>>> old "your code doesn't matter, you took a risk implementing an I-D"
>>> argument.  As an argument it kinda stinks.  I'm embarrassed to confess
>>> that I've used it in the past, despite reminding myself not to.  I'd
>>> be interested in learning whether the IESG has an opinion on the
>>> subject.  A statement of policy might be valuable.
>> 
>> Given that the alternative is effectively forbidding breaking changes after
>> WG adoption -- which is clearly untenable -- I'm not sure what kind of
>> policy you're looking for here. Can you clarify?
> 
> (Hmm, I got this message twice...)
> 
> The usual exchange goes a: "I have code", b: "you implemented an I-D,
> that's your problem".
> 
> Some guidance about how to manage this situation would be appreciated.
> 
> I'm not looking for a prohibition on changes at any point in the
> process.  That's ludicrous, after all, people do understand what it
> means to implement an I-D.  But statements like "there is code" or
> "there is deployed code" are valid and useful input to a discussion
> and not just as proof that a given thing is possible.  That means
> potentially affecting the outcome of a decision.
> 
> In this particular case, the arguments presented weren't problematic,
> because the real arguments was actually "well, this change doesn't
> seem that bad to me".  But it's not the first time someone has opened
> with that argument and it annoyed me enough to comment.

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.

 It’s reasonable to argue that, while a new feature may be of value, implementors will not deploy it because <arguments>. That seems to happen more often with security features than other things, maybe because the IETF as a whole cares more about security than many deployment communities. But that’s not really an “existing code” argument per se (although existing code can contribute to it.)

There’s a difference between when we choose to standardize something already in wide deployment, vs when we invent something new and people deploy code based on drafts. But even that doesn’t mean we can’t change anything (see principle 1)

 But in any case, I agree that existing implementations/deployments and their scope are proper inputs to the discussion. But they are not trump cards.