jiebi/TextFlow huggingface dataset:
Original text:
it I-D.ietf-quic-recovery.  The sender implementation MUST either delay sending the frame until the controller allows it or drop the frame without sending it (at which point it MAY notify the <del> application). </del>  Implementations can optionally support allowing the application to specify a sending expiration time, beyond which a congestion-

Reviewer comments:
Warn against the pathological case of dropping packets due to pacing.
Early in our VPN implementation, we sent QUIC datagrams without any queueing, assuming that if a datagram gets dropped, then we exceeded the cwnd (and thus the estimated channel capacity), so it would likely not reach the peer anyways. In practice, this turned out to be a terrible idea that lead to underutilization of the channel; our implementation always does pacing, so if you don't queue the datagram, it will get dropped unless it just happens to fit into the current pacing quantum. Because pacing is RECOMMENDED for QUIC, I believe some form of queueing should be RECOMMENDED for datagrams, otherwise the users risk running into the same hard-to-debug problem that we had.
I think adding a note about pacing to the "Congestion Control" subsection makes sense to me.
+1, if you're in the bucket of implementations that have insight into their pacing algorithm, it should be reasonable to expect that you'd avoid dropping your own datagrams unless you make a queue and then build up too much in that queue.
Thanks!

Revised text:
it I-D.ietf-quic-recovery.  The sender implementation MUST either delay sending the frame until the controller allows it or drop the frame without sending it (at which point it MAY notify the  <ins> application).  Implementations that use packet pacing SHOULD support delaying the transmission of DATAGRAM frames for at least the time it takes to send the paced packets allowed by the congestion controller to avoid dropping frames excessively. </ins> Implementations can optionally support allowing the application to specify a sending expiration time, beyond which a congestion-
Original text:
timing of these acknowledgements is not used for loss recovery. As with any ack-eliciting frame, when a sender suspects that a packet <del> containing only DATAGRAM frames has been lost, it MAY send probe packets to elicit a faster acknowledgement as described in Section 6.2.4 of RFC9002. </del>  If a sender detects that a packet containing a specific DATAGRAM frame might have been lost, the implementation MAY notify the

Reviewer comments:
RFC 9002 doesn't equivocate regarding whether probes are sent: ack-eliciting packet in the packet number space as a probe. This text uses "MAY", which strongly suggests that probes are discretionary. That's not true.

Revised text:
timing of these acknowledgements is not used for loss recovery. As with any ack-eliciting frame, when a sender suspects that a packet  <ins> containing only DATAGRAM frames has been lost, it sends probe packets to elicit a faster acknowledgement as described in Section 6.2.4 of RFC9002. </ins> If a sender detects that a packet containing a specific DATAGRAM frame might have been lost, the implementation MAY notify the
Original text:
is important to note that acknowledgement of a DATAGRAM frame only indicates that the transport-layer handling on the receiver processed the frame, and does not guarantee that the application on the <del> receiver successfully processed the data.  Thus, this signal SHOULD NOT replace application-layer signals that indicate successful </del>  processing. 5.3.

Reviewer comments:
The use of "SHOULD NOT" implies that a) this is discretionary, and b) that applications might be able to rely on it in some cases. I don't believe that either is true unless the protocol were specified entirely differently. (And that alternative specification wouldn't be practical anyway.)

Revised text:
is important to note that acknowledgement of a DATAGRAM frame only indicates that the transport-layer handling on the receiver processed the frame, and does not guarantee that the application on the  <ins> receiver successfully processed the data.  Thus, this signal cannot replace application-layer signals that indicate successful </ins> processing. 5.3.
Original text:
handshake, which has a basic packet loss retransmission timer. This can allow loss recovery to occur more quickly for QUIC data. <del> QUIC datagrams, while unreliable, can support acknowledgements, allowing applications to be aware of whether a datagram was successfully received. </del>  <del> QUIC datagrams are subject to QUIC congestion control, allowing applications to avoid implementing their own. These reductions in connection latency, and application insight into the delivery of datagrams, can be useful for optimizing audio/video streaming applications, gaming applications, and other real-time network applications. </del>  Unreliable QUIC datagrams can also be used to implement an IP packet tunnel over QUIC, such as for a Virtual Private Network (VPN).

Reviewer comments:
Drop the text on acknowledgments. Then modify the congestion control thing to make the benefit clearer. A unified congestion controller can be more efficient.
-- URL This is not an application-layer signal. While the peer might have received the packet and processed it at the QUIC layer, this does not guarantee that the DATAGRAM frame contents were processed by the application. The draft already acknowledges this in . However, the treatment in the motivation could be misleading. Consider dropping this item.
-- URL Isn't it the case that they are acknowledged? (This one is just a nit, the next issue will be more serious.)

Revised text:
handshake, which has a basic packet loss retransmission timer. This can allow loss recovery to occur more quickly for QUIC data.  <ins> QUIC datagrams are subject to QUIC congestion control.  Providing a single congestion control for both reliable and unreliable data can be more effective and efficient. </ins>  <ins> These features can be useful for optimizing audio/video streaming applications, gaming applications, and other real-time network applications. </ins> Unreliable QUIC datagrams can also be used to implement an IP packet tunnel over QUIC, such as for a Virtual Private Network (VPN).
Original text:
transmitted with the DATAGRAM frame, like the STREAM frame, MUST be protected either by 0-RTT or 1-RTT keys.  7. This document registers a new value in the QUIC Transport Parameter

Reviewer comments:
I put this in Security Considerations, but I can see that is another good choice (perhaps a better one).
I agree this could also be its own subsection of section 5, but given that this really is just reiterating an existing requirement, it's also OK where it is.
Application protocols that use QUIC are required to define how 0-RTT is used. This draft doesn't really change that, but it does add to what 0-RTT can carry. In an abundance of caution, it should link to .

Revised text:
transmitted with the DATAGRAM frame, like the STREAM frame, MUST be protected either by 0-RTT or 1-RTT keys. <ins> Application protocols that allow DATAGRAM frames to be sent in 0-RTT require a profile that defines acceptable use of 0-RTT; see Section 5.6 of RFC9001. </ins> 7. This document registers a new value in the QUIC Transport Parameter
Original text:
require a profile that defines acceptable use of 0-RTT; see Section 5.6 of RFC9001.  7. This document registers a new value in the QUIC Transport Parameter

Reviewer comments:
Thank you!
Rephrasing what I mentioned at the mic, imagine a scenario where an application uses DATAGRAM to send a single fixed message ("fire the missile"). An adversary on path can start selectively dropping packets and checking to see whether or not they're retransmitted to learn whether or not this special message was sent. (Retransmission detection could be done by looking at the size of the QUIC packet carrying the DATAGRAM, for example.) I don't claim this is easy to do in practice, or useful, but I think it does raise interesting questions about how this new frame affects QUIC's security posture. Perhaps some text in the security considerations is needed? (Issue copied from , by NAME on 2019-11-19)
from NAME on 2020-02-21: How would that be different from streams in ordinary QUIC? Here you can also drop packets and look for retransmissions of a specific size? If there is overlap, this issue belongs to QUIC transport security considerations in general.
I think the key here is that, in dropping the special datagram frame and not seeing anything retransmitted, one could learn something about what was sent.
If we take my recommendation in to always at least send out a PING frame/packet for PTOs or losses of DATAGRAM frame/packets then, it may mitigate this leakage some. There would always be something sent out on these selective losses. I'm not sure how hard it would be to determine if the lost packet was a DATAGRAM or not with this behavior. My guess is that it would be implementation dependent.
PING doesn't really cut it here, because presence and size matter.
Does the attacker have a way of knowing that the packet that was dropped contained a DATAGRAM, vs some other non-retransmitted frame, such as PADDING or PING or ACK?
Probably not, though I would say that the retransmission logic for those three frames could be different enough that the choice of frame might leak. Nothing much doing here, though we might note that retransmission logic might expose information that can be used for traffic analysis.

Revised text:
require a profile that defines acceptable use of 0-RTT; see Section 5.6 of RFC9001. <ins> The use of DATAGRAM frames might be detectable by an adversary on path that is capable of dropping packets.  Since DATAGRAM frames do not use transport-level retransmission, connections that use DATAGRAM frames might be distinguished from other frames using the different response to loss. </ins> 7. This document registers a new value in the QUIC Transport Parameter
Original text:
DATAGRAM frames contain the following fields: <del> A variable-length integer specifying the length of the datagram in bytes.  This field is present only when the LEN bit is set.  If the LEN bit is not set, the datagram data extends to the end of the QUIC packet.  Note that empty (i.e., zero-length) datagrams are allowed. </del>  The bytes of the datagram to be delivered.

Reviewer comments:
and a bit of editorializing of thee text to match RFC 9000.
If you're receptive to this suggestion I am happy to file a PR
Oh wow I hadn't realized that we never updated to the new style. A PR would be lovely please!

Revised text:
DATAGRAM frames contain the following fields:  <ins> A variable-length integer specifying the length of the Datagram Data field in bytes.  This field is present only when the LEN bit is set to 1.  When the LEN bit is set to 0, the Datagram Data field extends to the end of the QUIC packet.  Note that empty (i.e., zero-length) datagrams are allowed. </ins> The bytes of the datagram to be delivered.
Original text:
5.1. DATAGRAM frames belong to a QUIC connection as a whole, and are not <del> strongly associated with any stream ID at the QUIC layer.  However, it is expected that applications will want to differentiate between </del>  specific DATAGRAM frames by using identifiers, such as for logical flows of datagrams or to distinguish between different kinds of datagrams.

Reviewer comments:
From list discussion: What does "strongly associated" mean in this context? We should remove "strongly".
I agree, removing strongly seems best
Thank you!

Revised text:
5.1. DATAGRAM frames belong to a QUIC connection as a whole, and are not  <ins> associated with any stream ID at the QUIC layer.  However, it is expected that applications will want to differentiate between </ins> specific DATAGRAM frames by using identifiers, such as for logical flows of datagrams or to distinguish between different kinds of datagrams.
Original text:
places a limit on the maximum size of DATAGRAM frames, that limit can be further reduced by the max_packet_size transport parameter and the Maximum Transmission Unit (MTU) of the path between endpoints. <del> DATAGRAM frames cannot be fragmented, therefore application protocols need to handle cases where the maximum datagram size is limited by other factors. </del>  5.1.

Reviewer comments:
could also do s/,/; but whatever.
I'm not qualified to handle this level of copy-editing, this sounds like something best suited for the RFC editor.

Revised text:
places a limit on the maximum size of DATAGRAM frames, that limit can be further reduced by the max_packet_size transport parameter and the Maximum Transmission Unit (MTU) of the path between endpoints.  <ins> DATAGRAM frames cannot be fragmented; therefore, application protocols need to handle cases where the maximum datagram size is limited by other factors. </ins> 5.1.
Original text:
deliver the data to the application immediately, as long as it is able to process the frame and can store the contents in memory. <del> DATAGRAM frames MUST be protected with either 0-RTT or 1-RTT keys. </del>  Note that while the max_datagram_frame_size transport parameter places a limit on the maximum size of DATAGRAM frames, that limit can

Reviewer comments:
Section 5: says DATAGRAM frames MUST be protected with either 0-RTT or 1-RTT keys. I would suggest to add the "otherwise what happens" part. One/two like explanation will be helpful and I think that will improve the understanding of this requirement.
Almost all QUIC frame types are like this. I would suggest saying "Like STREAM frames, ..." to make this obvious for the rationale.

Revised text:
deliver the data to the application immediately, as long as it is able to process the frame and can store the contents in memory.  <ins> Like STREAM frames, DATAGRAM frames contain application data and MUST be protected with either 0-RTT or 1-RTT keys. </ins> Note that while the max_datagram_frame_size transport parameter places a limit on the maximum size of DATAGRAM frames, that limit can
Original text:
7. Clients that act upon a request to rate limit are potentially re- <del> identifiable (see Section 7.1 of DNS-PRIVACY) because they react to </del>  information that might only be given to them.  Note that this might apply to other fields too (e.g.  Retry-After).

Reviewer comments:
RFC6973 Section 5.2.1 would be a better reference.
Ok, thanks URL

Revised text:
7. Clients that act upon a request to rate limit are potentially re-  <ins> identifiable (see Section 5.2.1 of PRIVACY) because they react to </ins> information that might only be given to them.  Note that this might apply to other fields too (e.g.  Retry-After).
Original text:
The RateLimit-Policy field (see ratelimit-policy-field), might contain information on the associated time window. <del> This field MUST NOT occur multiple times and can be sent in a trailer section. </del>  3.2. These examples show multiple policies being returned: <del> This field MUST NOT occur multiple times and can be sent in a trailer section. </del>  3.3. The field is an Item and its value is a non-negative Integer expressed in service-limit.  Parameters are not allowed. <del> This field MUST NOT occur multiple times and can be sent in a trailer section. </del>  Clients MUST NOT assume that a positive RateLimit-Remaining field value is a guarantee that further requests will be served. it mitigates the risk related to thundering herd when too many clients are serviced with the same timestamp. <del> This field MUST NOT occur multiple times and can be sent in a trailer section. </del>  An example of RateLimit-Reset field use is below.

Reviewer comments:
According to URL there is no need to specify that information.
This text appears in relation to Item fields. By their nature Items can only occur on one field line (the proper terminology, btw), so this requirement is extraneous, and should be removed.
... and it's also on RateLimit-Policy, even though that is a List field.

Revised text:
The RateLimit-Policy field (see ratelimit-policy-field), might contain information on the associated time window.  <ins> This field can be sent in a trailer section. </ins> 3.2. These examples show multiple policies being returned:  <ins> This field can be sent in a trailer section. </ins> 3.3. The field is an Item and its value is a non-negative Integer expressed in service-limit.  Parameters are not allowed.  <ins> This field can be sent in a trailer section. </ins> Clients MUST NOT assume that a positive RateLimit-Remaining field value is a guarantee that further requests will be served. it mitigates the risk related to thundering herd when too many clients are serviced with the same timestamp.  <ins> This field can be sent in a trailer section. </ins> An example of RateLimit-Reset field use is below.
Original text:
5.2. <del> As is the ordinary case for HTTP caching (HTTP-CACHING), a response with RateLimit fields might be cached and re-used for subsequent requests.  A cached response containing RateLimit fields does not modify quota counters but could contain stale information.  Clients interested in determining the freshness of the RateLimit fields could rely on fields such as the Date header field and on the time window of a quota policy. </del>  6.

Reviewer comments:
It would be better to say that rate limiting information in what we used to call non-firsthand responses (basically, anything with an Age header) should be ignored.
Is the following text ok?
Looks good, just a few suggested tweaks:

Revised text:
5.2.  <ins> HTTP-CACHING defines how responses can be stored and reused for subsequent requests, including those with RateLimit fields.  Because the information in RateLimit fields on a cached response may not be current, they SHOULD be ignored on responses that come from cache (i.e., those with a positive current_age; see Section 4.2.3 of HTTP- CACHING). </ins> 6.
Original text:
Clients MUST NOT assume that a positive RateLimit-Remaining field value is a guarantee that further requests will be served. <del> A low RateLimit-Remaining field value is like a yellow traffic-light for either the number of requests issued in the time window or the request throughput: the red light may arrive suddenly (see providing- ratelimit-fields). </del>  For example:

Reviewer comments:
This should be specified without resorting to a metaphor that some may find confusing.
I'm ok to removing this line.

Revised text:
Clients MUST NOT assume that a positive RateLimit-Remaining field value is a guarantee that further requests will be served.  <ins> When the value of RateLimit-Remaining is low, it indicates that the server may soon throttle the client (see providing-ratelimit-fields). </ins> For example:
Original text:
exceeds that limit, it MAY not be served. The field is an Item and its value is a non-negative Integer referred <del> to as the "expiring-limit".  Parameters are not allowed. </del>  The expiring-limit MUST be set to the service limit that is closest to reaching its limit, and the associated time window MUST either be: client. The field is an Item and its value is a non-negative Integer <del> expressed in service-limit.  Parameters are not allowed. </del>  This field can be sent in a trailer section. it mitigates the risk related to thundering herd when too many clients are serviced with the same timestamp.  This field can be sent in a trailer section. An example of RateLimit-Reset field use is below.

Reviewer comments:
Parameters are not allowed, and if they appear they MUST be ignored.
Why not just 'If Parameters appear they MUST be ignored'?
NAME we wanted to stress the fact that servers are not expected to provide parameters, otherwise some clients could just consider the whole field value malformed and ignore it.
The normal way to do that is something like:
Ok, I'll rebase this PR tomorrow :) Late night now in Italy. Thanks for all this support :)
In a few places, the specification says "Parameters are not allowed" but does not spell out what should happen if they appear.

Revised text:
exceeds that limit, it MAY not be served. The field is an Item and its value is a non-negative Integer referred  <ins> to as the "expiring-limit".  This specification does not define Parameters for this field.  If they appear, they MUST be ignored. </ins> The expiring-limit MUST be set to the service limit that is closest to reaching its limit, and the associated time window MUST either be: client. The field is an Item and its value is a non-negative Integer  <ins> expressed in service-limit.  This specification does not define Parameters for this field.  If they appear, they MUST be ignored. </ins> This field can be sent in a trailer section. it mitigates the risk related to thundering herd when too many clients are serviced with the same timestamp. <ins> This specification does not define Parameters for this field.  If they appear, they MUST be ignored. </ins> This field can be sent in a trailer section. An example of RateLimit-Reset field use is below.
Original text:
3.3. <del> The "RateLimit-Remaining" field response field indicates the remaining quota units defined in service-limit associated with the client. </del>  The field is an Item and its value is a non-negative Integer expressed in service-limit.  This specification does not define 3.4. The "RateLimit-Reset" field response field indicates the number of <del> seconds until the quota resets. </del>  The field is a non-negative Integer compatible with the delay-seconds rule, because:

Reviewer comments:
clarify that we return only the values related to the quota policy identified by the expiring-limit
If there are multiple policies in effect, which is reflected in these fields? RateLimit-Limit has advice about this, but these do not.
Ok, we should clearly state that all the three basic fields return the values associated to the expiring-limit.

Revised text:
3.3.  <ins> The "RateLimit-Remaining" response field indicates the remaining quota units associated to the expiring-limit. </ins> The field is an Item and its value is a non-negative Integer expressed in service-limit.  This specification does not define 3.4. The "RateLimit-Reset" field response field indicates the number of  <ins> seconds until the quota associated to the expiring-limit resets. </ins> The field is a non-negative Integer compatible with the delay-seconds rule, because: