Subject: Lars Eggert's No Objection on draft-ietf-quic-datagram-08: (with COMMENT)

From: Lars Eggert via Datatracker <[email-masked]>
Date: Thu, 03 Feb 2022 02:30:16 -0800

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?

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.

"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".

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 03 Feb 2022 09:13:06 -0800

Hi Lars,

Thanks for the review! Responses inline.

> On Feb 3, 2022, at 2:30 AM, Lars Eggert via Datatracker <[email-masked]> wrote:
> 

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.

> Do not mix variants of the same word ("acknowledgment" and "acknowledgement")

Hm, not sure what this one is supposed to mean =)

Best,
Tommy