Warren Kumari's No Objection on draft-ietf-quic-v2-06: (with COMMENT)

Warren Kumari via Datatracker <noreply@ietf.org> Thu, 27 October 2022 01:20 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: quic@ietf.org
Delivered-To: quic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D869C1526FB; Wed, 26 Oct 2022 18:20:46 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-quic-v2@ietf.org, quic-chairs@ietf.org, quic@ietf.org, matt.joras@gmail.com, matt.joras@gmail.com, lana.wubo@huawei.com, opsdir@ietf.org
Subject: Warren Kumari's No Objection on draft-ietf-quic-v2-06: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 8.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Warren Kumari <warren@kumari.net>
Message-ID: <166683364650.48332.8975670709269111331@ietfa.amsl.com>
Date: Wed, 26 Oct 2022 18:20:46 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/2ib6n4SLhgyQZqHLRDqv1itQ2vo>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 27 Oct 2022 01:20:46 -0000

Warren Kumari has entered the following ballot position for
draft-ietf-quic-v2-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-quic-v2/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Quoting Rob Wilton:
"Thank you.  Another well written, easy to read, draft from the QUIC WG." -
Thank you for this, and also thanks to Bo Wu for the OpsDir review.

I'd note that the start of the Abstract ("This document specifies QUIC version
2, which is identical to QUIC version 1 except for some trivial details.") made
me schnort, and got me some odd looks from seat-mate on a plane...

A few (very much non-blocking) comments:
Section 3.  Differences with QUIC Version 1
"QUIC version 2 endpoints MUST implement the QUIC version 1 specification as
described in [QUIC], [QUIC-TLS], and [QUIC-RECOVERY].  However, the following
differences apply in version 2." This feels like a fragment / truncated
paragraph - perhaps there is a better way to word this (like "The remainder of
this section lists the differences", or perhaps just changing the final period
to a colon would help.

Section 3.1:
"The Version field of long headers is 0x709a50c4." and "initial_salt =
0xa707.... ", "secret = 0x3425c20cf..."  -- it seems like it would be friendly
to the reader to point at how this was derived (otherwise someone is going to
assume something like that there have already been 1889161411 prior versions
:-)). "It's to prevent ossification / grease" describes *why*, but not *how*.
I'd thought I'd seen some useful text in some other draft/document that could
be stolen, but perhaps it was just in a presentation... Especially when there
are things like salts and magic security parameters, providing some sort of
explanation helps avoid the "that was chosen by TLA to make <insert hand-wavy
attack> easier" conspiracy...