Re: Alissa Cooper's Yes on draft-ietf-httpbis-http2-16: (with COMMENT)

On Fri, Jan 23, 2015, at 09:20, Greg Wilkins wrote:
>
> On 23 January 2015 at 17:33, Nicholas Hurley
> <hurley@todesschaf.org> wrote:
>> Well, yes, you're right there, it absolutely is too late to be
>> hammering on this. Not only are you just moving complexity from one
>> state to another (that actually means the same thing, with a
>> different name),
>
> A state that has behaviour that is conditional on the the entry into
> the state is not one state. A state that changes behaviour after a
> timeout is not one state. As I have frequently said, this state
> machine is a fantasy that does not represent reality. All
> implementations are going to have a state change within closed state
> as they expire the undefined timeout and change behaviour.

If we accept your assertion that the state machine is a fantasy that
doesn't represent reality, then there are likely a lot more changes that
should be made to the state machine than just this one, and I haven't
seen anyone making PRs for other state machine changes.

I don't accept that assertion, though. I think the state machine
represents reality just as much as any protocol state machine you see
does - there are *always* hidden details in the way things work. It's
not a failure of this WG, though, that's just the way of the world.

>> you're adding more normative text and changing the behavior of the
>> protocol. Given that we're past WGLC and well into dealing with the
>> IESG's feedback, I don't see how adding a "rst ack" could possibly
>> have any chance of meeting the high bar for changes to be accepted at
>> this point.
>
> All true and good process arguments for not making this good technical
> change. But I'd say it is a pretty fundamental failure of the process
> that we have such a broken state machine this late in the process.

I would argue that the amount of interoperability we have going on
here indicates that the state machine is far from broken. Large and
complex (as most protocol state machines are), perhaps, but definitely
not broken.

>> I'm a solid -1 on this, and I'm confident in saying there is no
>> argument that will change my mind on this one.
>
> What if I split the PR into two parts.
>
> The first would simply define the reset state and the behaviour
> associated with it. The "a short period" timeout would then be used to
> move to closed state. This would not change the wire protocol, but
> would improve the description of the current behaviour.
>
> The second part would be the "rst ack", which we can put on hold until
> a subsequent iteration

This would remain a -1 from me. The reset state in this separated PR in
fact adds complexity to the state machine in the form of more states.
(And, if the state machine is so horribly broken as you assert, then
making this one change isn't going to fix the horrible brokenness.)
Furthermore, it forces changes on implementations that explicitly
implement the state machine as a state machine, which does, in fact,
invalidate interop testing (even though the protocol on the wire doesn't
change) - not something we should be doing this late in the game (unless
it meets the aforementioned incredibly high bar.)
--
Peace, -Nick