On Wed, Feb 2, 2022 at 3:14 PM David Schinazi <[email protected]> wrote:
> Hi Warren, > > Thanks for your comment. It's unfortunate that some folks > have a mental association from "datagram" to "UDP", but > at the end of the day that's not necessarily the target > audience. This document is aimed at implementers of > QUIC who do know top-of-mind that you can build a reliable > transport over UDP, and have unreliable transmission > outside of UDP. I understand what you're trying to accomplish > with your proposed text, but unfortunately I suspect that'll > introduce more confusion, because in some cases you > can tunnel UDP inside QUIC datagrams. > John Scudder suggested that "For clarity, in this document we are using 'datagram' with its normal sense of 'a self-contained unit of data transmitted in a packet-switched network'. One example of a type of datagram is UDP; however, this specification is not restricted to any particular variety of datagram." might work. It still seems to me that *some* warning to help people not trip over the pointy bits would help, but also (clearly) I'm not going to die on this hill... W > > Thanks for the reminder about the opsdir review, I just > replied to that. > > Cheers, > David > > On Wed, Feb 2, 2022 at 11:31 AM Warren Kumari via Datatracker < > [email protected]> wrote: > >> 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/ >> >> >> >> -- The computing scientist’s main challenge is not to get confused by the complexities of his own making. -- E. W. Dijkstra
