Subject: Re: [Last-Call] Opsdir telechat review of draft-ietf-quic-datagram-08

From: David Schinazi <[email-masked]>
Date: Wed, 2 Feb 2022 12:13:24 -0800

Hi Jurgen, thanks for your review! Responses inline.
David

On Mon, Jan 31, 2022 at 12:00 AM Jürgen Schönwälder via Datatracker <
[email-masked]> wrote:

> - In the description of the DATAGRAM frame below Figure 1, perhaps
>   also describe the Type: field explicitly. Yes, the field is
>   described in the text preceding Figure 1, but it is usually a good
>   idea to describe all protocol fields separately, this makes it
>   easier to find and quote the relevant bits and pieces.  The text
>   above the figure can then likely be shortened. (Perhaps there is
>   also no need to name the LEN bit by just referring to the frame
>   type, or are there are frame times that have a LEN bit?)
>
>     Type: The DATAGRAM frame type takes values 0x30 or 0x31. If the
>        frame type is 0x31, the Length field is present. Otherwise, if
>        the frame type is 0x30, the Length field is absent and the
>        Datagram Data field extends to the end of the packet.
>

We've decided that consistency with RFC 9000 was preferable here, as
the target audience has already read that document.
https://datatracker.ietf.org/doc/html/rfc9000#section-19.8

- Perhaps add some text motivating why having both frame type values
>   is useful and detailing what implementations should do if things are
>   inconsistent, e.g., the Length field is larger than Datagram Data.
>

Similarly, this matches how QUIC STREAM frames work - the length
can be omitted to save bytes when it is not necessary.
https://datatracker.ietf.org/doc/html/rfc9000#section-19.8