Benjamin Kaduk has entered the following ballot position for draft-ietf-quic-datagram-08: Discuss
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/blog/handling-iesg-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-datagram/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 5 refers to a "max_packet_size" transport parameter but I do not see that parameter defined in the registry or RFC 9000. It seems that a transport parameter of that name was present in earlier versions of draft-ietf-quic-transport, but got renamed to max_udp_payload_size in the -28, so hopefully this is just a trivial rename. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I put some editorial suggestions (including the presumed resolution of the DISCUSS) on github at https://github.com/quicwg/datagram/pull/76 . Section 2 * QUIC uses a more nuanced loss recovery mechanism than the DTLS handshake, which has a basic packet loss retransmission timer. This is true of DTLS 1.2 and prior versions, which technically is right now the current version of DTLS. However, it's not quite true of DTLS 1.3, which includes an explicit ACK message to supplement the retransmission timer. DTLS 1.3 stands a pretty decent chance of being published as an RFC prior to this document (per ekr, it should have the last technical changes from the WG finalized this weekend and then go into the "real" AUTH48 state), so I think we ought to speak to the mechanisms of DTLS 1.3 here. Section 3 For most uses of DATAGRAM frames, it is RECOMMENDED to send a value of 65535 in the max_datagram_frame_size transport parameter to indicate that this endpoint will accept any DATAGRAM frame that fits inside a QUIC packet. It's interesting to compare this to the RFC 9000 max_udp_payload_size default of 65527, the maximum permitted UDP payload. Indeed, the QUIC 1-RTT packet header does not even contain a length field that would limit the frame size. So I'm not entirely sure what motivates the 65535 value specifically. (I do see the subsequent discussion about how there are other factors, including max_packet_size/max_udp_payload_size, that can further limit what is usable.)
