On Fri, Feb 4, 2022 at 4:56 PM Tommy Pauly <[email protected]> wrote: > > 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]> > 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. >
Okey dokey, W > 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]> 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 > > > -- The computing scientist’s main challenge is not to get confused by the complexities of his own making. -- E. W. Dijkstra
