> On Feb 3, 2022, at 7:36 AM, Warren Kumari <[email protected]> wrote: > > > > On Wed, Feb 2, 2022 at 3:14 PM David Schinazi <[email protected] > <mailto:[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...
The editors discussed this, and we feel that this kind of statement might end up being more confusing in context. The document currently defines what is carried as “unreliable application data”; specifically, bringing in any definition that refers to “packet-switched networks” would start to imply that this frame is only meant for tunneling data blobs that would otherwise be transmitted directly. Section 2, which covers the motivation, explains several use cases — real time applications, media content, and tunneling of entire IP packets. We feel that this list (and the fact that it never mentions trying to tunnel UDP payload content) is sufficient to avoid making it seem that this can only contain what would otherwise be UDP payloads. Best, Tommy > > 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] <mailto:[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/ > <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/ > <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/ > > <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
