RE: Invariants draft

[Roni Even <[e-mail]>]

Hi,
I think that the document needs some more information about why these fields are invariants.
For example, we can have a new version with a message type that will mean that the header format from the next message changes and the connection ID will be in a different position from the next message with higher packet number.  I assume that this is not something we want if there is a need to support routing based on connection ID by intermediary who will not support this new version. So if routing support is mandatory it will be good to mention it in this document.

Roni

> -----Original Message-----
> From: QUIC [mailto:[e-mail]] On Behalf Of Martin Thomson
> Sent: יום ו 01 דצמבר 2017 06:10
> To: QUIC WG
> Subject: Invariants draft
> 
> I've just submitted a personal draft that describes the invariants that I think
> we agreed to in Singapore.
> 
> https://datatracker.ietf.org/doc/html/draft-thomson-quic-invariants
> 
> This is just me for the moment (though Jana and Mike were very helpful in
> reviewing an even draftier draft).  It also assumes a few things about the
> current drafts that aren't yet true, and may not even become true.  Don't
> focus too much on the specific content of what is in or out, because that sort
> of detail is easy to fix.
> 
> More than content, I'd like to concentrate on the general approach and
> scope.  My hope is that we can agree that those are more or less correct.
> And then adopt the draft.  A draft like this should help address questions
> people have been asking about what can and cannot change between QUIC
> versions.