jiebi/TextFlow huggingface dataset:
Original text:
Broker (RS) via the CONNECT control message after the TLS handshake. This is similar to an earlier proposal by Fremantle et al. fremantle14.  Alternatively, the token may be used for the TLS <del> session establishment as described in the I-D.gerdes-ace-dtls- </del>  authorize.  In this case, both the TLS PSK and RPK handshakes MAY be supported.  This may additionally require that the Client transports the token to the Broker before the connection establishment.  To this

Reviewer comments:
fixed ID reference to ietf-ace-dtls-authorize doing this first so it'll build from makefile (
The correct reference is I-D.ietf-ace-dtls-authorize and not I-D.gerdes-ace-dtls-authorize.

Revised text:
Broker (RS) via the CONNECT control message after the TLS handshake. This is similar to an earlier proposal by Fremantle et al. fremantle14.  Alternatively, the token may be used for the TLS  <ins> session establishment as described in the I-D.ietf-ace-dtls- </ins> authorize.  In this case, both the TLS PSK and RPK handshakes MAY be supported.  This may additionally require that the Client transports the token to the Broker before the connection establishment.  To this
Original text:
2.5. <del> In the case of a Client DISCONNECT, due to the Clean Session flag, the Broker deletes all session state but MUST keep the retained messages.  By setting a RETAIN flag in a PUBLISH message, the </del>  publisher indicates to the Broker that it should store the most <del> recent message for the associated topic.  Hence, the new subscribers can receive the last sent message from the publisher of that particular topic without waiting for the next PUBLISH message.  The Broker MUST continue publishing the retained messages as long as the associated tokens are valid. </del>  In case of disconnections due to network errors or server disconnection due to a protocol error (which includes authorization

Reviewer comments:
I believe this " if you're happy with it now we're (assumed) targetting MQTT v5.0 we should refer to Clean Start acknowledge that RETAINed messages could be made irrelevant by further publishes
yes, that's much better, thanks! (see e46a8d)
Section 2.5 - The last sentence in the first paragraph could be state more clearly. Specifically there would appear to be some ambiguity on who the associated tokens are attached to. "messages as long as the publisher token for that message remains valid." Might be better.
Better working might to "the retailed message until the token for that message has expired," That avoids the question if all of the tokens have expired or just the one with the message.

Revised text:
2.5.  <ins> In the case of a Client DISCONNECT, due to the Clean Start flag (or Clean Session flag with MQTT v3.1.1), the Broker deletes all session state but MUST keep the retained messages and token expiry information.  By setting a RETAIN flag in a PUBLISH message, the </ins> publisher indicates to the Broker that it should store the most  <ins> recent message for the associated topic.  Hence, new subscribers can receive the most recent message from the publisher of that particular topic without waiting for the next PUBLISH message.  The Broker MUST continue publishing each retained message until the token for that message has expired, or another RETAIN message is published on the associated topic. </ins> In case of disconnections due to network errors or server disconnection due to a protocol error (which includes authorization
Original text:
there is none. The MUD file permits access to a particular Internet service, but <del> the name of that service resolved to something that was not permitted. </del>  The administrator overrode the recommendations in the MUD file.

Reviewer comments:
I added a container to report ACL violation dropped packets. I am not sure how the l3l4info is going to be used. The YANG model was fixed (I think some parens missing). Please check and let me know you agree with these changes. Thanks, Ranga

Revised text:
there is none. The MUD file permits access to a particular Internet service, but  <ins> the name of that service has not been resolved (or name resolution failed). </ins> The administrator overrode the recommendations in the MUD file.
Original text:
array of the MUD file. Second, the "mud" container is augmented with a container that points <del> to where to report and how often. </del>  This is done as follows:

Reviewer comments:
Added a default packet classification. Removed the generated txt file ( can always be generated from Makefile). Please reject pull request if you disagree. Thanks.
Reworked yang model. Mostly implemented (except for json serialization).
Reduced the amount of information in the YANG model to something manageable. Mostly implemented (except for some JSON serialization issues). At least it is feasible to implement this. Removed frequency (should be left to administrator - not manufacturer).

Revised text:
array of the MUD file. Second, the "mud" container is augmented with a container that points  <ins> to where to report. The frequency of reporting is impelementation dependent. Impelemntations are encouraged to report when ever packet drops are noticed at the enforcement point; however, this is not a strict requirement. </ins> This is done as follows:
Original text:
This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of <del> several different media types into a single message, such as a CoAP request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. </del>  1. This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of <del> several different media types into a single message, such as a CoAP RFC7252 request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. </del>  This simple and efficient binary framing mechanism can be employed to create application specific request and response bodies which build RFCthis <del> Applications that need to combine representations of potentially several media types into one, e.g., EST-CoAP </del>  N/A

Reviewer comments:
WFM
Oops, I'd missed that. I will change that instance as well.
It should not preclude 0, 1 or 2, therefore: s/several/zero or more/
Maybe just "representations of different media types"?

Revised text:
This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of  <ins> zero or more different media types into a single message, such as a CoAP request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. </ins> 1. This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of  <ins> zero or more different media types into a single message, such as a CoAP RFC7252 request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. </ins> This simple and efficient binary framing mechanism can be employed to create application specific request and response bodies which build RFCthis  <ins> Applications that need to combine representations of zero or more different media types into one, e.g., EST-CoAP </ins> N/A
Original text:
This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of <del> several different media types into a single CoAP message-body with minimal framing overhead, each along with a CoAP Content-Format identifier. </del>  1. This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of <del> several different media types into a single CoAP RFC7252 message-body with minimal framing overhead, each along with a CoAP Content-Format identifier. </del>  This simple and efficient binary framing mechanism can be employed to create application specific request and response bodies which build

Reviewer comments:
Sure. Apologies, I had completely misunderstood the gist of your comment (and Carsten's reply).
-> s/message-body/request or response body/
I still don't understand why the only permissible use of this representation format is inside a CoAP payload. Can't I transfer the CBOR structure over HTTP or store it in a file?

Revised text:
This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of  <ins> several different media types into a single message, such as a CoAP request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. </ins> 1. This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of  <ins> several different media types into a single message, such as a CoAP RFC7252 request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. </ins> This simple and efficient binary framing mechanism can be employed to create application specific request and response bodies which build
Original text:
Applications that need to combine representations of zero or more different media types into one, e.g., EST-CoAP <del> N/A </del> 

Reviewer comments:
Carsten adds:
Yes. (Where is the rest of that change?)
As we speak there's no PR, only this issue.
NAME would you mind writing the missing text? I'm not comfortable messing around with media type registration procedures :-)

Revised text:
Applications that need to combine representations of zero or more different media types into one, e.g., EST-CoAP  <ins> The syntax and semantics of fragment identifiers specified for "application/multipart-core" is as specified for "application/ cbor".  (At publication of this document, there is no fragment identification syntax defined for "application/cbor".) </ins>
Original text:
After completing the handshake, endpoints have agreed to enable multipath feature and can start using multiple paths.  This document <del> does not discuss when a client decides to initiate a new path.  We delegate such discussion in separate documents. </del>  This proposal adds one multipath control frame for path management:

Reviewer comments:
Attempt at moving Further, it is out of scope for this document if the old address can also be used for multipath after a client has migrated to the address provided in the preferred_address transport parameter. However, it SHOULD NOT be assumed that it is possible to use both addresses simultaneously without further confirmation from the other host. In the beginning of section where I think it would be more appropriate.
Looks good, except for the typo.

Revised text:
After completing the handshake, endpoints have agreed to enable multipath feature and can start using multiple paths.  This document  <ins> does not specify how an endpoint that is reachable via several addresses announces these addresses to the other endpoint.  In particular, if the server uses the preferred_address transport parameter, clients SHOULD NOT assume that the initial server address and the addresses contained in this parameter can be simultaneously used for multipath.  Furthermore, this document does not discuss when a client decides to initiate a new path.  We delegate such discussion in separate documents. </ins> This proposal adds one multipath control frame for path management:
Original text:
11. <del> TDB </del>  12.

Reviewer comments:
Add some implementation considerations to handle different PMTU sizes following the discussion on . Feel free to add different implementation options here.
Looks ok to me, just a small suggestion to avoid talking about packet retransmission.

Revised text:
11.  <ins> 11.1. An implementation should take care to handle different PMTU sizes across multiple paths.  One simple option if the PMTUs are relatively similar is to apply the minimum PMTU of all paths to each path.  The benefit of such an approach is to simplify retransmission processing as the content of lost packets initially sent on one path can be sent on another path without further frame scheduling adaptations. </ins> 12.
Original text:
"enable_multipath", it MUST treat this as a connection error of type MP_CONNECTION_ERROR and close the connection. <del> Note that the transport parameter "active_connection_id_limit" QUIC- TRANSPORT limits the number of usable Connection IDs, and also limits the number of concurrent paths.  For the QUIC multipath extension this limit even applies when no connection ID is exposed in the QUIC header. </del> This extension does not change the definition of any transport <del> parameter defined in Section 18.2. of QUIC-TRANSPORT.  Inline with the definition in QUIC-TRANSPORT disable_active_migration also disables multipath support, except "after a client has acted on a preferred_address transport parameter" Section 18.2. of QUIC- TRANSPORT.  Further, it is out of scope for this document to specify if the old address can also be used for multipath after a client has migrated to the address provided in the preferred_address transport parameter.  However, it SHOULD NOT be assumed that it is possible to use both addresses simultaneously without further confirmation from the other host. </del>  3.

Reviewer comments:
This text will be moved to the next section in PR . Therefore this PR needs to be merged together with PR .

Revised text:
"enable_multipath", it MUST treat this as a connection error of type MP_CONNECTION_ERROR and close the connection.  This extension does not change the definition of any transport  <ins> parameter defined in Section 18.2. of QUIC-TRANSPORT. Inline with the definition in QUIC-TRANSPORT disable_active_migration also disables multipath support, except "after a client has acted on a preferred_address transport parameter" Section 18.2. of QUIC- TRANSPORT. The transport parameter "active_connection_id_limit" QUIC-TRANSPORT limits the number of usable Connection IDs, and also limits the number of concurrent paths.  For the QUIC multipath extension this limit even applies when no connection ID is exposed in the QUIC header. </ins> 3.
Original text:
9.2. <del> The MP_ACK frame (types TBD-00 and TBD-01; experiments use </del>  0xbaba00..0xbaba01 or 0x42..x43) is an extension of the ACK frame defined by QUIC-TRANSPORT.  It is used to acknowledge packets that <del> were sent on different paths.  If the frame type is TBD-01, MP_ACK </del>  frames also contain the sum of QUIC packets with associated ECN marks received on the connection up to this point. number space, which is the sequence number of Destination Connection ID of the 1-RTT packets which are acknowledged by the ACK_MP frame. If the endpoint receives 1-RTT packets with 0-length Connection ID, <del> it SHOULD use Packet Number Space Identifier 0 in ACK_MP frames. </del>  10.

Reviewer comments:
Should we trigger an connection closure with a MPCONNECTIONERROR in the case an endpoint receives an ACK_MP frame acknowledging packets on a non-existing packet number space ID?
Yes. I just submitted PR for this issue.
PR merged.
LGTM.

Revised text:
9.2.  <ins> The ACK_MP frame (types TBD-00 and TBD-01; experiments use </ins> 0xbaba00..0xbaba01 or 0x42..x43) is an extension of the ACK frame defined by QUIC-TRANSPORT.  It is used to acknowledge packets that  <ins> were sent on different paths.  If the frame type is TBD-01, ACK_MP </ins> frames also contain the sum of QUIC packets with associated ECN marks received on the connection up to this point. number space, which is the sequence number of Destination Connection ID of the 1-RTT packets which are acknowledged by the ACK_MP frame. If the endpoint receives 1-RTT packets with 0-length Connection ID,  <ins> it SHOULD use Packet Number Space Identifier 0 in ACK_MP frames.  If an endpoint receives a ACK_MP frame with a non-existing packet number space ID, it MUST treat this as a connection error of type MP_CONNECTION_ERROR and close the connection. </ins> 10.
Original text:
calculated by combining the packet protection IV with the packet number and with the path identifier. <del> The path ID for 1-RTT packets is the sequence number of of QUIC- </del>  TRANSPORT, or zero if the Connection ID is zero-length.  Section 19 of QUIC-TRANSPORT encodes the Connection ID Sequence Number as a variable-length integer, allowing values up to 2^62-1; in this

Reviewer comments:
It's a grammar error fix in the aead section.
from URL The path ID for 1-RTT packets is the sequence number of of {{QUIC-TRANSPORT}} maybe it should be The path ID for 1-RTT packets is the sequence number of Connection ID of {{QUIC-TRANSPORT}}
Thanks Wu! I fixed this grammar error in PR .

Revised text:
calculated by combining the packet protection IV with the packet number and with the path identifier.  <ins> The path ID for 1-RTT packets is the sequence number of QUIC- </ins> TRANSPORT, or zero if the Connection ID is zero-length.  Section 19 of QUIC-TRANSPORT encodes the Connection ID Sequence Number as a variable-length integer, allowing values up to 2^62-1; in this
Original text:
endpoint abandons a path, the peer will not receive any more non- probing packets on that path. <del> An endpoint that wants to close a path SHOULD NOT rely on implicit signals like idle time or packet losses, but instead SHOULD use explicit request to terminate path by sending the PATH_ABANDON frame (see path-abandon-frame). </del>  4.2.1.

Reviewer comments:
.
Should the spec say something about stateless reset? Suppose a node is sending on two paths with two different DCID and two corresponding stateless reset secrets, and receives a stateless reset packet that matches the reset secret on the first path. Should it: 1) Abandon that path and continue the connection with the other path? 2) Abandon the connection?
That's a good point. RFC9000 states that stateless resets should be used in last resort when the endpoint does not have access to the connection state. If hosts have still access to the connection state and want to abandon a specific path, I would expect them to rely on PATH_ABANDON frame (or on path idle timeout). So when receiving a stateless reset, I would abandon the connection. Depending on the number of impacts on existing RFC9000 mechanisms, it may be useful to write a section (or at least, a paragraph) clarifying these points.
We should review the current text and make sure we cover everything clearly. Maybe add some more text to the intro part of 3.2
Careful with implicit actions!LGTM

Revised text:
endpoint abandons a path, the peer will not receive any more non- probing packets on that path.  <ins> An endpoint that wants to close a path SHOULD use explicit request to terminate the path by sending the PATH_ABANDON frame (see path- abandon-close).  Note that while abandoning a path implies Connection ID retirement, only retiring the associated Connection ID does not necessarily advertise path abandon (see retire-cid-close).  However, implicit signals such as idle time or packet losses might be the only way for an endhost to detect path closure (see idle-time-close). Note that other explicit closing mechanisms of QUIC-TRANSPORT still apply on the whole connection.  In particular, the reception of either a CONNECTION_CLOSE (Section 10.2 of QUIC-TRANSPORT) or a Stateless Reset (Section 10.3 of QUIC-TRANSPORT) closes the connection. </ins> 4.2.1.
Original text:
the connection ID, but MUST use a different connection ID when doing so.  4.2.3. QUIC-TRANSPORT allows for closing of connections if they stay idle

Reviewer comments:
It might be possible to be in a state where a sender retires a DCID that was used by still in-flight packets. Hence, it is possible for the sender to receive a ACKMP frame referencing the retired DCID. Depending on the situation: The sender can keep a way to track the sent packet with the retired DCID sequence number, allowing proper acknowledgement of the packets. The sender drops all the state related to the DCID, hence marking the in-flight packets as being lost and ignoring ACKMP frames having a retired DCID sequence number. While this should not affect interoperability, it might be worthwhile to add a sentence or two to mention the possible performance issue in such situation.
We could add some text to . Can you propose a PR NAME ?

Revised text:
the connection ID, but MUST use a different connection ID when doing so. <ins> Note that if the sender retires a Connection ID that is still used by in-flight packets, it may receive ACK_MP frames referencing the retired Connection ID.  If the sender stops tracking sent packets with retired Connection ID, these would be spuriously marked as lost. To avoid such performance issue without keeping retired Connection ID state, an endpoint should first stop sending packets with the to-be- retired Connection ID, then wait for all in-flight packets to be either acknowledged or marked as lost, and finally retire the Connection ID. </ins> 4.2.3. QUIC-TRANSPORT allows for closing of connections if they stay idle
Original text:
An endpoint that wants to close a path SHOULD use explicit request to terminate the path by sending the PATH_ABANDON frame (see path- <del> abandon-close).  Note that while abandoning a path implies Connection ID retirement, only retiring the associated Connection ID does not necessarily advertise path abandon (see retire-cid-close).  However, implicit signals such as idle time or packet losses might be the only way for an endhost to detect path closure (see idle-time-close). </del>  Note that other explicit closing mechanisms of QUIC-TRANSPORT still apply on the whole connection.  In particular, the reception of

Reviewer comments:
Minor tweak. The text says that a path abandon "implies" retirement of the CID. Readers could be mislead and assume that they don't need to send a retire frame after sending abandon, when in fact they do.
NAME , NAME NAME please review.
This Github setting is pretty annoying. NAME I understand why only the selected authors would be able to merge a pull request, but as it stands I am also blocked from requesting reviews of a PR that I just created.
LGTMThe proposed text is indeed clearer.

Revised text:
An endpoint that wants to close a path SHOULD use explicit request to terminate the path by sending the PATH_ABANDON frame (see path-  <ins> abandon-close).  Note that while abandoning a path will cause Connection ID retirement, only retiring the associated Connection ID does not necessarily advertise path abandon (see retire-cid-close). However, implicit signals such as idle time or packet losses might be the only way for an endhost to detect path closure (see idle-time- close). </ins> Note that other explicit closing mechanisms of QUIC-TRANSPORT still apply on the whole connection.  In particular, the reception of
Original text:
frames to signal acknowledgement of 1-RTT packets on path number 0, and also 0-RTT packets as specified in handling-of-0-rtt-packets. <del> 1-RTT packets sent to different paths SHOULD carry different connection identifiers, if a non-zero connection ID is used. </del>  6.1.

Reviewer comments:
There is a SHOULD here, which I believe should be a MUST as we taking about the receiver behaviour here.
NAME NAME is this ready to merge?
Sorry, I am working on several projects in parallel, missed this. Text is fine.

Revised text:
frames to signal acknowledgement of 1-RTT packets on path number 0, and also 0-RTT packets as specified in handling-of-0-rtt-packets.  <ins> An endpoint sending 1-RTT packets MUST use different Connection IDs on different paths, if non-zero-length Connection IDs are used. Still, the receiver may observe the same Connection ID used on different 4-tuples due to, e.g., NAT rebinding.  In such case, the receiver reacts as specified in Section 9.3 of QUIC-TRANSPORT. </ins> 6.1.