RE: Call for Adoption: Invariants

["Lubashev, Igor" <[e-mail]>]

+1 for the adoption.

The adoption does not mean that the draft will be published exactly like it is right now.  But, as Jana said, I really hope we can settle this one before we settle v1 drafts.

From: Jana Iyengar [mailto:[e-mail]]
Sent: Monday, February 05, 2018 3:16 PM
To: Mikkel Fahnøe Jørgensen <[e-mail]>
Cc: Brian Trammell (IETF) <[e-mail]>; Mark Nottingham <[e-mail]>; QUIC WG <[e-mail]>; Mike Bishop <[e-mail]>; Lars Eggert <[e-mail]>
Subject: Re: Call for Adoption: Invariants

+1 for adoption.

As Ian pointed out, once published, any changes to the invariants will be a significant uphill task for active deployments. That's the entire point of having these invariants. I would very much like to publish the invariants ahead of the rest of the documents, so that active deployment of IETF-QUIC can start, but that's a matter for a different thread, not this one.

On Mon, Feb 5, 2018 at 11:05 AM, Mikkel Fahnøe Jørgensen <[e-mail]<mailto:[e-mail]>> wrote:
It could be called QUID ...

________________________________
From: Mike Bishop <[e-mail]<mailto:[e-mail]>>
Sent: Monday, February 5, 2018 8:00:53 PM
To: Brian Trammell (IETF); Mikkel Fahnøe Jørgensen
Cc: Lars Eggert; Mark Nottingham; QUIC WG
Subject: RE: Call for Adoption: Invariants

I support adoption.  The way to change the invariants will be to mint a new protocol, and not claim that your new protocol is a version of QUIC.  If it happens to be startlingly similar, all well and good.

-----Original Message-----
From: QUIC [mailto:[e-mail]] On Behalf Of Brian Trammell (IETF)
Sent: Monday, February 5, 2018 12:34 AM
To: Mikkel Fahnøe Jørgensen <[e-mail]<mailto:[e-mail]>>
Cc: Lars Eggert <[e-mail]<mailto:[e-mail]>>; Mark Nottingham <[e-mail]<mailto:[e-mail]>>; QUIC WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: Call for Adoption: Invariants

Hi, all,

I support adoption of the invariants draft.

> On 5 Feb 2018, at 08:51, Mikkel Fahnøe Jørgensen <[e-mail]<mailto:[e-mail]>> wrote:
>
> Only concern is when it takes effect since it likely needs adjustments.

I'd presume that invariants is published simultaneously with the version 1 spec.

> And perhaps a procedure to handle invariant changes since everything changes.

Noted, though the point of declaring something an invariant is to say "the meaning of this part of the wire image, expressed as a bit offset, will never change". You can add constraints to the invariants, but if you think you might remove a constraint, then it's not an invariant by definition.

Cheers,

Brian

> From: QUIC <[e-mail]<mailto:[e-mail]>> on behalf of Mark Nottingham <[e-mail]<mailto:[e-mail]>>
> Sent: Monday, February 5, 2018 7:07:45 AM
> To: QUIC WG
> Cc: Lars Eggert
> Subject: Call for Adoption: Invariants
>
> At the Melbourne meeting, there was strong support for adopting Martin's invariants draft:
>
> https://tools.ietf.org/html/draft-thomson-quic-invariants-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dthomson-2Dquic-2Dinvariants-2D00&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=KX7z_74_SmfCNCCfwbvGUrj14akhnYWFa_jYUsJ9b4s&s=bwNKnbE0d5ngNnELVEa6-RApXxOsA3r9ZZJ9OF448lk&e=>
>
> Any objections / concerns about doing so? Unless we hear otherwise, we'll adopt at the end of the week.
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mnot.net_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=KX7z_74_SmfCNCCfwbvGUrj14akhnYWFa_jYUsJ9b4s&s=WabB1dQco52dWkhJg2dixu9nSahr_7BJChphDgHF-Cs&e=>