Secdir last call review of draft-ietf-quic-datagram-07

Carl Wallace via Datatracker <noreply@ietf.org> Wed, 22 December 2021 18:52 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 F17903A086F; Wed, 22 Dec 2021 10:52:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Carl Wallace via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-quic-datagram.all@ietf.org, last-call@ietf.org, quic@ietf.org
Subject: Secdir last call review of draft-ietf-quic-datagram-07
X-Test-IDTracker: no
X-IETF-IDTracker: 7.41.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164019915492.5710.15723155597958890951@ietfa.amsl.com>
Reply-To: Carl Wallace <carl@redhoundsoftware.com>
Date: Wed, 22 Dec 2021 10:52:34 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/x04tQtuZmSO4f26pzSIVUD5Fr_Q>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 22 Dec 2021 18:52:35 -0000

Reviewer: Carl Wallace
Review result: Ready

This is a well written document. My only comments are likely due to my lack of
familiarity with QUIC.

1) Section 5 states "this frame SHOULD be sent as soon as possible, and MAY be
coalesced with other frames." It was not clear to me how this squared with
Section 4's "if this bit is set to 0, the Length field is absent and the
Datagram Data field extends to the end of the packet." Should the MAY be other
packets instead of frames? Or is at most one datagram frame with no length
present permitted in a packet, with it being last?

2) Section 3 may benefit from including words a la section 4.6.2 of RFC 9001
regarding resetting state when max_datagram_frame_size is rejected. On first
read, it was not clear to me why this value did not latch.