Hi Lars, Thanks for the review! Responses inline.
> On Feb 3, 2022, at 2:30 AM, Lars Eggert via Datatracker <[email protected]> > wrote: > > Lars Eggert 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: > ---------------------------------------------------------------------- > > Section 5.2. , paragraph 5, comment: >> If a sender detects that a packet containing a specific DATAGRAM >> frame might have been lost, the implementation MAY notify the >> application that it believes the datagram was lost. >> >> Similarly, if a packet containing a DATAGRAM frame is acknowledged, >> the implementation MAY notify the sender application that the >> datagram was successfully transmitted and received. Due to > > Being able to emit these notifications seem to depend on structuring the API > between the implementation and the application so that not only opaque > datagram > blobs are exchanged, but that they are also associated with some sort of > identifier? I think this is an area where we probably are better off not going into detail, since it becomes very implementation- and language-specific. It is possible to do this with datagram blob identifiers on the send() calls that get associated with events, with index values, or just a completion block associated with the send call. For example, in the API that I work with, the application can pass event blocks along with specific send() calls such that the relationship is captured implicitly. > > Thanks to Meral Shirazipour for their General Area Review Team (Gen-ART) > review > (https://mailarchive.ietf.org/arch/msg/gen-art/7_tXP9y1m0RYcb-8k6P8IbyTMGc). > > ------------------------------------------------------------------------------- > All comments below are about very minor potential issues that you may choose > to > address in some way - or ignore - as you see fit. Some were flagged by > automated tools (via https://github.com/larseggert/ietf-reviewtool), so there > will likely be some false positives. There is no need to let me know what you > did with these suggestions. > > "Table of Contents", paragraph 2, nit: >> . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . >> ^^^^^^^^^^^^^^^ > Do not mix variants of the same word ("acknowledgment" and "acknowledgement") > within a single text. Hm, not sure what this one is supposed to mean =) Best, Tommy > > "Table of Contents", paragraph 2, nit: >> s, and each frame type defines whether or not the data it contains will be r >> ^^^^^^^^^^^^^^ > Consider shortening this phrase to just "whether". It is correct though if you > mean "regardless of whether". > > >
