Subject: Re: [secdir] Secdir last call review of draft-ietf-quic-datagram-07

From: Tommy Pauly <[email-masked]>
Date: Mon, 03 Jan 2022 09:11:17 -0800

Hi Carl,

Thanks for the review!

To reply to your two comments:

1) DATAGRAM frames behave much like STREAM frames—they have a form with a length that can be a “middle” frame in the packet, and the have a form without a length that can only be the last frame in a packet, because the frame will extend to the end of the packet. Both forms MAY be coalesced with other frames, since there can be other frames (like a PING, ACK, etc) that go before the DATAGRAM frame. And, DATAGRAM frames that contain the length can always be put before other DATAGRAM frames.

2) I think the notion of rejecting that you refer to is more specific to 0-RTT, and isn’t a general property of transport parameters. The comment in RFC 9001 about ignoring previous transport parameter values when 0-RTT is rejected applies to all future transport parameters, including max_datagram_frame_size (which has a default of 0).

Best,
Tommy

> On Dec 22, 2021, at 10:52 AM, Carl Wallace via Datatracker <[email-masked]> wrote:
> 
> 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.
> 
>