[dnsdir] Dnsdir last call review of draft-ietf-quic-version-negotiation-10

Petr Špaček via Datatracker <noreply@ietf.org> Tue, 11 October 2022 08:54 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dnsdir@ietf.org
Delivered-To: dnsdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9905C15949D; Tue, 11 Oct 2022 01:54:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Petr Špaček via Datatracker <noreply@ietf.org>
To: dnsdir@ietf.org
Cc: draft-ietf-quic-version-negotiation.all@ietf.org, last-call@ietf.org, quic@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166547846194.62670.9247668997915247015@ietfa.amsl.com>
Reply-To: Petr Špaček <pspacek@isc.org>
Date: Tue, 11 Oct 2022 01:54:21 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsdir/swTm6QGRLQqnsVC87asXiedii9s>
Subject: [dnsdir] Dnsdir last call review of draft-ietf-quic-version-negotiation-10
X-BeenThere: dnsdir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: DNS Directorate <dnsdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsdir>, <mailto:dnsdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsdir/>
List-Post: <mailto:dnsdir@ietf.org>
List-Help: <mailto:dnsdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsdir>, <mailto:dnsdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Oct 2022 08:54:22 -0000

Reviewer: Petr Špaček
Review result: Ready with Nits

The document contains no direct or indirect reference to the DNS.

I'm unfamiliar with QUIC protocol details and thus not qualified to make
detailed comments on the protocol. On the surface, it looks good.

The document is clearly motivated, and the proposed mechanism's description
contains helpful examples throughout the whole document.

A list of nits follows, very likely as a matter of personal taste - feel free
to ignore:

>From my perspective, the document overuses forward references to itself, which
makes it harder to follow.

a) Section 8 Special Handling for QUIC Version 1
It would be nice if this section were mentioned in the beginning. For a while,
I thought the proposed protocol could not work because I did not notice special
handling in the Table of contents. I would put it forwarding, possibly as a
subsection of the Version Information section.

b) The first mention of "transport parameter" could use a reference to RFC 9000
sec. 7.4 to make it easier for the reader.

c) Also, section 5.  Server Deployments of QUIC forward could appear earlier, 
possibly as a subsection of the Version Information section.

For me personally more logical text flow would be:

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Version Information . . . . . . . . . . . . . . . . . . . . .   8
      8.  Special Handling for QUIC Version 1 . . . . . . . . . . . . .  15
      5.  Server Deployments of QUIC  . . . . . . . . . . . . . . . . .  11
   2.  Version Negotiation Mechanism . . . . . . . . . . . . . . . .   4
   4.  Version Downgrade Prevention  . . . . . . . . . . . . . . . .  10

With enough jumping back and forth, the document makes sense, so again, feel
free to ignore me.