Re: Call for Adoption: Invariants

Christian Huitema <huitema@huitema.net> Mon, 05 February 2018 18:19 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B5312D892 for <quic@ietfa.amsl.com>; Mon, 5 Feb 2018 10:19:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iv93JZ-OOOWh for <quic@ietfa.amsl.com>; Mon, 5 Feb 2018 10:19:49 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A5A12D88E for <quic@ietf.org>; Mon, 5 Feb 2018 10:19:39 -0800 (PST)
Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1eilM5-0000Pm-ID for quic@ietf.org; Mon, 05 Feb 2018 19:19:09 +0100
Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1eilLg-0001gb-S3 for quic@ietf.org; Mon, 05 Feb 2018 13:18:40 -0500
Received: (qmail 14502 invoked from network); 5 Feb 2018 18:18:13 -0000
Received: from unknown (HELO [192.168.200.65]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender <huitema@huitema.net>) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for <ianswett@google.com>; 5 Feb 2018 18:18:13 -0000
Content-Type: multipart/alternative; boundary="Apple-Mail-7EC7A3F8-6ED0-4673-9916-0A768309CE2A"
Mime-Version: 1.0 (1.0)
From: Christian Huitema <huitema@huitema.net>
X-Mailer: iPhone Mail (15C202)
In-Reply-To: <CAKcm_gM4tv8=9UaWVV0B251w_Jbi+ANSpoSZsSkTk3cMF4LsMA@mail.gmail.com>
Date: Mon, 05 Feb 2018 08:18:10 -1000
Cc: "Brian Trammell (IETF)" <ietf@trammell.ch>, Lars Eggert <lars@eggert.org>, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>, QUIC WG <quic@ietf.org>, Mark Nottingham <mnot@mnot.net>
Content-Transfer-Encoding: 7bit
Message-Id: <3761ABF1-6BE5-46F6-B8BD-958365B71A6D@huitema.net>
References: <C35C3AB6-F0FC-4D83-9C97-DD0B605A863F@mnot.net> <DB6PR10MB17667AAB19D4A9288FD5BAF3ACFE0@DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM> <FDFA0988-1FB4-4AFC-8958-1A6B16068FE5@trammell.ch> <CAKcm_gM4tv8=9UaWVV0B251w_Jbi+ANSpoSZsSkTk3cMF4LsMA@mail.gmail.com>
To: Ian Swett <ianswett@google.com>
Subject: Re: Call for Adoption: Invariants
X-Originating-IP: 168.144.250.230
X-AntiSpamCloud-Domain: xsmtpout.mail2web.com
X-AntiSpamCloud-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.14)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5qXXpqj00edi0rmbKqIisYMXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fsYay3JbAQaXjRPLmDkDLz8B98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXtfZdf1siwYNJirk4ABKayRZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Xq4ax6KvrI/nhOyr4XmBA0QaRU5G7TB9RBnrQ7zv+k CstDAjCNidMNTTT2l8YX9HmUTmj0QZk3SQ/TbYRr7yfbx6JvzKixj8PC+OqalCFkmpH+vpUDIZeJ XjrpEEsmd+8wbu9lcViFVxDhGp2PwufGcyNBJprCgmabT8JgPqpM5kvKSvC0LDy5UGAFpFuWjTgS aara5b+hdT6nDe+yMl3p9u7OTA2dS2mw7K5brBO3Qlz1pRXWhjh9fdbl44I0Df0tN9eq0V0hlrWD EiOHLhiBfcoxmrjechJW+9VrFT0uBx3h1vgDbEdmhrg3iVBpdRY15+ZZmMZUyV9HJAkRDrR5GpIO PepTCxFMvIavjx/iA3YOJbgNLT0Ix6mdJEErnNhWBb39uS1TjWG2Inx+Ts2QvrhVVD6SNHfaCiIW OOQAkvVDEoFOK6EAWKQ3WFIxRUtYANHDTJAVnZcGvok0a1Vj
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/kMfRIfAsXnmrNc8MuN0rffgRCvg>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Feb 2018 18:19:51 -0000

Yes, invariants are useful, and the draft too.

Take the example of the omit CID bit in the short header. If it were version dependent, you could not understand it without first retrieving the connection context to find which version is used. But to do that you need to parse the CID, so you need to know whether it is present.

That said, what about the 17 bytes CID PR?

-- Christian Huitema 

> On Feb 5, 2018, at 4:04 AM, Ian Swett <ianswett@google.com> wrote:
> 
> I support adoption of the invariants draft.
> 
>> On Mon, Feb 5, 2018 at 3:33 AM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
>> Hi, all,
>> 
>> I support adoption of the invariants draft.
>> 
>> > On 5 Feb 2018, at 08:51, Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> 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.
> 
> From the perspective of someone intending to deploy draft versions, the invariants need to be stable, ideally at least in a last call state, sooner than the version 1 spec, otherwise there's no guarantee a server can migrate from one version to another.
> 
>> 
>> > 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 <quic-bounces@ietf.org> on behalf of Mark Nottingham <mnot@mnot.net>
>> > 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
>> >
>> > 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/
>> 
>