jiebi/TextFlow huggingface dataset:
Original text:
use of DiffServ Code Points (DSCPs) RFC2475 as well as Equal-Cost Multi-Path (ECMP) routing, is applied on a per flow-basis (and not per-packet) and as such that all packets belonging to the same QUIC <del> connection get uniform treatment.  Using ECMP to distribute packets from a single flow across multiple network paths or any other non- uniform treatment of packets belong to the same connection could result in variations in order, delivery rate, and drop rate.  As feedback about loss or delay of each packet is used as input to the congestion controller, these variations could adversely affect performance. Depending on the loss recovery mechanism implemented, QUIC may be more tolerant of packet re-ordering than traditional TCP traffic (see packetnumber).  However, it cannot be known by the network which exact recovery mechanism is used and therefore reordering tolerance should be considered as unknown. </del>  4.9.

Reviewer comments:
It could be worth noting two general further things about DSCPs : (a) "When multiplexing multiple flows over a QUIC connection, the DSCP value selected should be the one associated with the highest priority requested for all multiplexed flows." (b) "If a packet enters a network segment that does not support the DSCP value, this could result in the connection not receiving the network treatment it expects. The DSCP value in this packet could also be remarked as the packet travels along the network path."
A sample PR: "More aspects of setting DSCPs"

Revised text:
use of DiffServ Code Points (DSCPs) RFC2475 as well as Equal-Cost Multi-Path (ECMP) routing, is applied on a per flow-basis (and not per-packet) and as such that all packets belonging to the same QUIC  <ins> connection get uniform treatment. Using ECMP to distribute packets from a single flow across multiple network paths or any other non-uniform treatment of packets belong to the same connection could result in variations in order, delivery rate, and drop rate.  As feedback about loss or delay of each packet is used as input to the congestion controller, these variations could adversely affect performance.  Depending on the loss recovery mechanism implemented, QUIC may be more tolerant of packet re- ordering than traditional TCP traffic (see packetnumber).  However, the recovery mechanism used by a flow cannot be known by the network and therefore reordering tolerance should be considered as unknown. </ins> 4.9.
Original text:
12. <del> QUIC assumes that all packets of a QUIC connection, or at least with the same 5-tuple {dest addr, source addr, protocol, dest port, source port}, will receive similar network treatment since feedback about loss or delay of each packet is used as input to the congestion controller.  Therefore, it is not recommended to use different DiffServ Code Points (DSCPs) RFC2475 for packets belonging to the same connection.  If differential network treatment, e.g. by the use of different DSCPs, is desired, multiple QUIC connections to the same server may be used.  However, in general it is recommended to minimize the number of QUIC connections to the same server, to avoid increased overheads and, more importantly, competing congestion control. </del>  13.

Reviewer comments:
Separates for manageability and this PR for applicability
I actually find this sentence weak: "Therefore it is not recommended to use different DiffServ Code Points (DSCPs) {{?RFC2475}} for ... Considering that QUIC v1 as defined has a single congestion controller and recovery handler and don't treat different DSCP values as separate transport flows I would think that this should be stronger formulated. However, I could see that one could provide a bit more context to this DSCP and single QUIC connections vs multiple QUIC streams discussion by referencing Section 5.1 of URL and be explicit about the point that QUIC v1 is similar to SCTP in regards to the issues raised.
I think the new text do work.

Revised text:
12.  <ins> QUIC, as defined in RFC9000, has a single congestion controller and recovery handler.  This design assumes that all packets of a QUIC connection, or at least with the same 5-tuple {dest addr, source addr, protocol, dest port, source port} that same the same DiffServ Code Point (DSCP) RFC2475, will receive similar network treatment since feedback about loss or delay of each packet is used as input to the congestion controller.  Therefore, packets belonging to the same connection should use a single DSCP.  Section 5.1 of RFC7657 provides a discussion of DiffServ interactions with datagram transport protocols RFC7657 (in this respect the interactions with QUIC resemble those of SCTP). When multiplexing multiple flows over a single QUIC connection, the selected DSCP value should be the one associated with the highest priority requested for all multiplexed flows. If differential network treatment is desired, e.g., by the use of different DSCPs, multiple QUIC connections to the same server may be used.  However, in general it is recommended to minimize the number of QUIC connections to the same server, to avoid increased overhead and, more importantly, competing congestion control. As in other uses of DiffServ, when a packet enters a network segment that does not support the DSCP value, this could result in the connection not receiving the network treatment it expects.  The DSCP value in this packet could also be remarked as the packet travels along the network path, changing the requested treatment. </ins> 13.
Original text:
7. QUIC version 1 without extensions uses an acknowledgment strategy <del> adopted from TCP.  That is, every other packet is acknowledged. However, generating and processing QUIC acknowledgments can consume significant resources, both in terms of processing costs and link utilization, especially on constraint networks.  Some applications might be able to improve overall performance by using alternative strategies that reduce the rate of acknowledgments. </del>  8.

Reviewer comments:
Suggesting a rewording to clarify various issues and correct some mistakes.
Previously scope of this text was agreed, but what appeared seems to me to have various NiTs: • Saying "every other packet is acknowledged" is a recommendation in RC9000. I suggest citing also. • The text seems to conflate endpoint processing optimisation, and network path performance optimisation: /constraint/ wasn't the correct word, but even /constrained/ was a value judgment on design traedoffs for any mobile/RF link - and many bandwidth-limited cabled link, which could be avoided by simply saying what is intended and saying either /which can impact performance of some types of network/ or /which can impact performance across some types of network/ ... depending on your viewpoint as an operator or application. • I think we can do better than URL, suggesting removing some and leaving might. This might be resolved in a PR .

Revised text:
7. QUIC version 1 without extensions uses an acknowledgment strategy  <ins> adopted from TCP Section 13.2 of RFC9000).  That is, it recommends every other packet is acknowledged.  However, generating and processing QUIC acknowledgments consumes resources at a sender and receiver.  Acknowledgments also incur forwarding costs and contribute to link utilization, which can impact performance over some types of network.  Applications might be able to improve overall performance by using alternative strategies that reduce the rate of acknowledgments. </ins> 8.
Original text:
sequences of one-to-one exchanges with servers in the group, by sending requests over unicast. <del> 2.3.3. </del>  If the pairwise mode is supported, the Security Context additionally includes Secret Derivation Algorithm, Secret Derivation Parameters

Reviewer comments:
NAME Good point about being more explicit. I actually think is valuable to reference an existing encoding of public keys providing also key type and curve, like CREDX in URL Also, there is a discussion about format for public keys in COSE, which if it is specified probably will be referenced by EDHOC instead of CREDX. I would be good if there is a common format used in all these instances. For the time being I propose that we reference CRED_X with empty text string subject name, and keep track of the COSE activity.
We should consider replace the NIST reference with SECG [1] to harmonize with EDHOC [2]. [1] URL [2] URL (edit) ... but the commits in [3] mainly refers to the NIST spec. so I propose we keep it as is for the time being. [2] URL
It looks good to me; we can give more details on one point. For the two HKDF invocations in Section 2.3.1, we can define more explicitly how the public keys are expressed when concatenated to form IKM-Sender and IKM-Recipient. Given a public key, that can simply be: For OKP signature keys, the compressed 'x' coordinate, i.e. what would be expressed in the key parameter -2 of a corresponding COSE Key. For EC2 signature keys, the 'x' coordinate followed by the 'y' coordinate in this order, i.e. what would be expressed in the key parameters -2 and -3 of a corresponding COSE Key. This should be sufficient, i.e. it shouldn't be needed to have a more structured encoding of public keys providing also key type and curve, e.g. like done for CRED_X in URL

Revised text:
sequences of one-to-one exchanges with servers in the group, by sending requests over unicast.  <ins> 2.3.4. </ins> If the pairwise mode is supported, the Security Context additionally includes Secret Derivation Algorithm, Secret Derivation Parameters
Original text:
hold for Group OSCORE, about building the AEAD nonce and the secrecy of the Security Context parameters. <del> The EdDSA signature algorithm and the elliptic curve Ed25519 RFC8032 are mandatory to implement.  For endpoints that support the pairwise mode, the ECDH-SS + HKDF-256 algorithm specified in Section 6.3.1 of I-D.ietf-cose-rfc8152bis-algs and the X25519 curve RFC7748 are also mandatory to implement. </del>  Constrained IoT devices may alternatively represent Montgomery curves and (twisted) Edwards curves RFC7748 in the short-Weierstrass form

Reviewer comments:
NAME Good point about being more explicit. I actually think is valuable to reference an existing encoding of public keys providing also key type and curve, like CREDX in URL Also, there is a discussion about format for public keys in COSE, which if it is specified probably will be referenced by EDHOC instead of CREDX. I would be good if there is a common format used in all these instances. For the time being I propose that we reference CRED_X with empty text string subject name, and keep track of the COSE activity.
We should consider replace the NIST reference with SECG [1] to harmonize with EDHOC [2]. [1] URL [2] URL (edit) ... but the commits in [3] mainly refers to the NIST spec. so I propose we keep it as is for the time being. [2] URL
It looks good to me; we can give more details on one point. For the two HKDF invocations in Section 2.3.1, we can define more explicitly how the public keys are expressed when concatenated to form IKM-Sender and IKM-Recipient. Given a public key, that can simply be: For OKP signature keys, the compressed 'x' coordinate, i.e. what would be expressed in the key parameter -2 of a corresponding COSE Key. For EC2 signature keys, the 'x' coordinate followed by the 'y' coordinate in this order, i.e. what would be expressed in the key parameters -2 and -3 of a corresponding COSE Key. This should be sufficient, i.e. it shouldn't be needed to have a more structured encoding of public keys providing also key type and curve, e.g. like done for CRED_X in URL

Revised text:
hold for Group OSCORE, about building the AEAD nonce and the secrecy of the Security Context parameters.  <ins> The EdDSA signature algorithm Ed25519 RFC8032 is mandatory to implement.  For endpoints that support the pairwise mode, the ECDH-SS + HKDF-256 algorithm specified in Section 6.3.1 of I-D.ietf-cose- rfc8152bis-algs and the X25519 algorithm RFC7748 are also mandatory to implement. </ins> Constrained IoT devices may alternatively represent Montgomery curves and (twisted) Edwards curves RFC7748 in the short-Weierstrass form
Original text:
the order of notifications, the client SHALL maintain a Notification Number for each Observation it registers.  The Notification Number is a non-negative integer containing the largest Partial IV of the <del> received notifications for the associated Observe registration (see replay-protection).  The Notification Number is initialized to the Partial IV of the first successfully received notification response to the registration request.  In contrast to RFC7641, the received Partial IV MUST always be compared with the Notification Number, which thus MUST NOT be forgotten after 128 seconds.  Further details of replay protection of notifications are specified in replay- protection. Clients can re-register observations to ensure that the observation is still active and establish freshness again (RFC7641 Section 3.3.1).  When an OSCORE protected observation is refreshed, not only the ETags, but also the partial IV (and thus the payload and OSCORE option) change.  The server uses the new request's Partial IV as the 'request_piv' of new responses. </del>  4.1.3.5.

Reviewer comments:
Back to one processing description Observe is now primarily inner Simplified processing Explicit cancellation by intermediary not supported

Revised text:
the order of notifications, the client SHALL maintain a Notification Number for each Observation it registers.  The Notification Number is a non-negative integer containing the largest Partial IV of the  <ins> received notifications for the associated Observe registration. Further details of replay protection of notifications are specified in replay-notifications. The Inner Observe in a response MUST either have the value of Observe in the original CoAP message or be empty.  The former is used to allow the server to set the Observe values to be received by the client.  In the latter case the overhead of the Observe value is saved and instead the least significant bytes of the Partial IV is used as Observe value, see replay-notifications.  The Outer Observe in the response may be needed for intermediary nodes to support multiple responses to one request.  The client MAY ignore the Outer Observe value. If the client receives a response to an Observe request without an Observe value, then it verifies the response as a non-Observe response, as specified in ver-res.  If the client receives a response to a non-Observe request with an Observe value, then it stops processing the message but keeps the observation alive, as specified in ver-res. </ins> 4.1.3.5.
Original text:
The sending endpoint SHALL write the Code of the original CoAP message into the plaintext of the COSE object (see plaintext).  After that, the sending endpoint writes an Outer Code to the OSCORE <del> message.  With one exeception (see observe-option-processing) the Outer Code SHALL by default be set to 0.02 (POST) for requests and to 2.04 (Changed) for responses.  The receiving endpoint SHALL discard the Outer Code in the OSCORE message and write the Code of the COSE object plaintext (plaintext) into the decrypted CoAP message. </del>  The other currently defined CoAP Header fields are Unprotected (Class U).  The sending endpoint SHALL write all other header fields of the

Reviewer comments:
Back to one processing description Observe is now primarily inner Simplified processing Explicit cancellation by intermediary not supported

Revised text:
The sending endpoint SHALL write the Code of the original CoAP message into the plaintext of the COSE object (see plaintext).  After that, the sending endpoint writes an Outer Code to the OSCORE  <ins> message.  With one exeception (see observe) the Outer Code SHALL by default be set to 0.02 (POST) for requests and to 2.04 (Changed) for responses.  The receiving endpoint SHALL discard the Outer Code in the OSCORE message and write the Code of the COSE object plaintext (plaintext) into the decrypted CoAP message. </ins> The other currently defined CoAP Header fields are Unprotected (Class U).  The sending endpoint SHALL write all other header fields of the
Original text:
7.4.1. <del> Additionally to the previous section, the following applies when Observe is supported. 7.4.1.1. A client receiving a notification SHALL compare the Partial IV of a received notification with the Notification Number associated to that Observe registration.  The ordering of notifications after OSCORE processing MUST be aligned with the Partial IV.  The client MAY do so by copying the least significant bytes of the Partial IV into the Observe option, before passing it to CoAP processing.  The client MAY ignore an Outer Observe option value.  If the verification of the response succeeds, and the received Partial IV was greater than the Notification Number, then the client SHALL update the corresponding Notification Number with the received Partial IV.  The client MUST stop processing notifications with a Partial IV which has been previously received.  An application MAY require the client to discard notifications which have Partial IV less than the Notification Number. If messages are processed concurrently, the Partial IV needs to be validated a second time after decryption and before updating the replay protection data.  The operation of validating the Partial IV and updating the replay protection data MUST be atomic. 7.4.1.2. In order to allow intermediaries to re-register their interest in a resource (see 3.3.1 of RFC7641), a server receiving an Observe registration with Token, kid and Partial IV identical to a previously received registration, and which decrypts without error SHALL not treat it as a replay and SHALL respond with a notification.  The notification may be a cached copy of the latest sent notification (with the same Token, kid and Partial IV) or it may be a newly generated notification with a fresh Partial IV. </del>  7.5.

Reviewer comments:
Back to one processing description Observe is now primarily inner Simplified processing Explicit cancellation by intermediary not supported

Revised text:
7.4.1.  <ins> The following applies additionally when Observe is supported. The Notification Number is initialized to the Partial IV of the first successfully received notification response to the registration request.  A client receiving a notification SHALL compare the Partial IV of a verified notification with the Notification Number associated to that Observe registration.  In contrast to RFC7641, the received Partial IV MUST always be compared with the Notification Number, which thus MUST NOT be forgotten after 128 seconds. If the verification of the response succeeds, and the received Partial IV was greater than the Notification Number, then the client SHALL update the corresponding Notification Number with the received Partial IV.  The operation of validating the Partial IV and updating the replay protection data MUST be atomic.  If the Inner Observe option is empty, then the client SHALL copy the least significant bytes of the Partial IV into the Observe option, before passing it to CoAP processing. If the Partial IV is less than or equal to the Notification Number, then the client SHALL stop processing the response but not cancel the observation. </ins> 7.5.
Original text:
7.5.3. <del> To prevent accepting replay of previously received notification responses, the client may perform the following procedure after boot: </del>  <del> The client rejects notifications bound to the earlier registration, removes all Notification Numbers and re-registers using Observe. </del>  8.

Reviewer comments:
Back to one processing description Observe is now primarily inner Simplified processing Explicit cancellation by intermediary not supported

Revised text:
7.5.3.  <ins> To prevent accepting replay of previously received notifications, the client may perform the following procedure after boot: </ins>  <ins> The client forgets about earlier registrations, removes all Notification Numbers and re-registers using Observe. </ins> 8.
Original text:
If Observe is implemented: <del> Replace step 1 in ver-req with: A.  Discard Code and all options marked in fig-option-protection with 'x' in column E, except for Observe, present in the received message. For example, an If-Match Outer option is discarded, Uri-Host Outer option is not discarded, Observe is not discarded. </del>  <del> Replace step 3 in ver-req with: </del>  <del> B.  If Observe is present in the received message, and has value 0, check if the Token, kid and Partial IV are identical to a previously received Observe registration.  In this case, replay verification is postponed until step C.  Otherwise verify the 'Partial IV' parameter using the Replay Window, as described in replay-protection. </del>  <del> Insert the following steps between step 6 and 7 of ver-req: C.  If Observe was present in the received message (in step 1): If the value of Observe in the Outer message is 0: If Observe is present and has value 0 in the decrypted options, discard the Outer Observe.  If the Token, kid and Partial IV are identical to a previously received Observe registration, respond with a notification as described in observe-replay- processing; Otherwise, discard both the Outer and Inner (if present) Observe options and verify the 'Partial IV' parameter using the Replay Window, as described in replay-protection. If the value of Observe in the Outer message is not 0, discard the decrypted Observe option if present. </del>  8.3.

Reviewer comments:
Back to one processing description Observe is now primarily inner Simplified processing Explicit cancellation by intermediary not supported

Revised text:
If Observe is implemented:  <ins> Insert the following step before step 1 in ver-req: </ins>  <ins> A.  Check if the Outer Observe option is present and has value zero. </ins>  <ins> Insert the following step between step 6 and 7 of ver-req: </ins>  <ins> B.  If Inner Observe is present and has value zero, and Outer option is either not present or has not value 0, then remove the Observe option. </ins> 8.3.