RE: Spin bit discussion - where we're at

[Salvatore Loreto <[e-mail]>]

Hi Lars, Mark

One clarification question about the process specifically for the Spin Bit proposal and the time frame for the consensus call

While it is clear to me that a more comprehensive writeup (as detailed in the original email.) is a necessary
condition, it is not clear if it is also a sufficient one for a consensus call.

Indeed in the original mail Mark is on one side proposing to discuss it in London (instead that into the next interim)
but at same time is leaving open the possibility to postpone the final decision until right before shipping the protocol to the IESG
While I agree with Mark assessment that we can tip this into the short header relatively late in the game, 
I am concerned for this huge potential delay for a proposal that I would argue is already clear to all people actively involved in the QUIC design.

Can you please which are the next steps you are going to follow here?

Sal 


-----Original Message-----
From: QUIC [mailto:[e-mail]] On Behalf Of Eggert, Lars
Sent: den 22 november 2017 13:35
To: Roni Even <[e-mail]>
Cc: Brian Trammell <[e-mail]>; Mark Nottingham <[e-mail]>; QUIC WG <[e-mail]>
Subject: Re: Spin bit discussion - where we're at

Hi Roni,

On 2017-11-22, at 13:15, Roni Even <[e-mail]> wrote:
> I was surprised to read the chairs email and agree with Brian's comments.
> My impression is that the email reflects a view that manageability is not important (and not blocking) and this is the reason for not doing the spin bit based on issue 609 as a PR.

there hasn't been a consensus call on the Spin Bit proposal. Contributors have expressed their views on the results presented by the DT on the list, as requested by the chairs in the session in Singapore. But that is not the same as a consensus call, and I apologize if it was misunderstood as one.

In order to hold an informed consensus call on the Spin Bit in the future, we're asking for a more comprehensive writeup (as detailed in the original email.) As I've said before, I think the material for that already exists in some form or other, but it's currently in several places, not all of which may be public (e.g., the DT mailing list.)

For *other* proposals that intend to address manageability by adding information to the cleartext wire image, we're asking for a similarly comprehensive description, so that the WG can begin discussing a concrete contribution.

> My product development experience is that lack of tools to manage and 
> maintain a product will prevent its distribution. I understand that 
> the developer  of the protocol care only about the protocol and not 
> about making it easy to support in the field. Yet the network product 
> manufacturers and the service providers gave a clear message that RTT  
> is crucial for deployment.  I provided use cases from TCP in service 
> providers networks in 
> https://tools.ietf.org/id/draft-even-quic-troubleshooting-video-delive
> ry-00.txt I expect that the WG chair and AD will treat protocol 
> maintenance and management the same as the protocol itself. What 
> emphasis my point is the effort the WG does on 
> https://tools.ietf.org/html/draft-ietf-quic-manageability-01

Lars