RE: Spin bit discussion - where we're at

[Roni Even <[e-mail]>]

Hi Lars,

> -----Original Message-----
> From: Eggert, Lars [mailto:[e-mail]]
> Sent: יום ד 22 נובמבר 2017 14:35
> To: Roni Even
> Cc: Brian Trammell; Mark Nottingham; QUIC WG
> 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.)
[Roni Even]  I agree that there is was no consensus call in Singapore, there was no text to agree on. The issue is if we want a spin bit solution and the discussion on the list supports it.  From the discussion on the Microphone I noticed that some of the group members did not agree with the content of the presentation. So to me it look like that the only good thing that came out from the DT is that the spin bit does not add any security risks with regards to the security issues that were presented to them. 
I do not understand why spin bit issues in the github are "parked" 
>From my point of view I intend to try to expedite the needed text for the spin bit and hope that the expectation will be reasonable comparing to the requirements from other features in the protocol.   This is why I ask the chairs not to wait for IETF 101 if the interested parties will provide text. Even though you can add this text at any stage towards V1 I would not like to get it blocked because it did not get enough discussion since it came late and people need more time. Based on the interest I expect to discuss it also in the Interim if we have enough text.  I was not aware that the decision on what to discuss is based on the onsite participants
> 
> 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