Warren Kumari has entered the following ballot position for draft-ietf-quic-datagram-08: No Objection
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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Something that would make this document *much* more understandable, especially for those of us who are not so bright, is that QUIC datagrams are not just QUIC carrying UDP. The document says: "In the past, these applications have built directly upon UDP [RFC0768] as a transport, and have often added security with DTLS [RFC6347]. Extending QUIC to support transmitting unreliable application data provides another option for secure datagrams, with the added benefit of sharing the cryptographic and authentication context used for reliable streams." Even though I knew that this isn't just tunneling UDP over QUIC, the above description and use of the term "datagram" (which has become synonymous with UDP) keeps making me forget that. I don't have any suggested text, but something like a "Note: This is a QUIC transport to carry unreliable data natively, and does not encapsulate UDP packets" or something. Also, much thanks to Jürgen Schönwälder for his OpsDir review of -07, and the authors for addressing the comments. I wanted to confirm that the authors had seen that Jürgen followed up with an additional review of -08 (much thanks Jürgen!) at https://datatracker.ietf.org/doc/review-ietf-quic-datagram-08-opsdir-telechat-schoenwaelder-2022-01-31/
