jiebi/TextFlow huggingface dataset:
Original text:
13.  This document has no actions for IANA; however, note that ports recommends that application bindings to QUIC for applications using TCP register UDP ports analogous to their existing TCP registrations. <del> 14. </del>  See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for analysis and padding, or migration might be relevant for other applications using QUIC as well. <del> 15. </del>  This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture

Reviewer comments:
I updated the text of the second paragraph. If people could have another look that would be welcome. But I believe we are ready to merge (after the meeting).
So far we don't mention any extension in the ops drafts, however, datagrams actually require a different interface and as such are important for an application to know about, therefore, I think it would be good to add a separate section in the applicability statement and mention it as a separate service over QUIC.
Agreed, mentioning datagram seems very useful.

Revised text:
13. <ins> I-D.draft-ietf-quic-datagram specifies a QUIC extension to enable sending and receiving unreliable datagrams over QUIC.  Unlike operating directly over UDP, applications that use the QUIC datagram service do not need to implement their own congestion control, per RFC8085, as QUIC datagrams are congestion controlled. QUIC datagrams are not flow-controlled, and as such data chunks may be dropped if the receiver is overloaded.  While the reliable transmission service of QUIC provides a stream-based interface to send and receive data in order over multiple QUIC streams, the datagram service has a unordered message-based interface.  If needed, an application layer framing can be used on top to allow separate flows of unreliable datagrams to be multiplexed on one QUIC connection. 14. </ins> This document has no actions for IANA; however, note that ports recommends that application bindings to QUIC for applications using TCP register UDP ports analogous to their existing TCP registrations.  <ins> 15. </ins> See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for analysis and padding, or migration might be relevant for other applications using QUIC as well.  <ins> 16. </ins> This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture
Original text:
If a QUIC receiver has opened the maximum allowed concurrent streams, and the sender indicates that more streams are needed, it does not automatically lead to an increase of the maximum number of streams by <del> the receiver.  Therefore it can be valuable to expose the maximum number of allowed, currently open, and currently used streams to the application to make the mapping of data to streams dependent on this information. </del>  QUIC assigns a numerical identifier to each stream, called the Stream ID.  While the relationship between these identifiers and stream

Reviewer comments:
The proposed wording makes sentence stronger, more list a SHOULD requirement. Therefore we wanted to check with others before we merge.
Seems simpler and clearer. I don't see this as normative.

Revised text:
If a QUIC receiver has opened the maximum allowed concurrent streams, and the sender indicates that more streams are needed, it does not automatically lead to an increase of the maximum number of streams by  <ins> the receiver.  Therefore, an application can use the maximum number of allowed, currently open, and currently used streams when determining how to map data to streams. </ins> QUIC assigns a numerical identifier to each stream, called the Stream ID.  While the relationship between these identifiers and stream
Original text:
identified by five-tuple when the address and port of one of the endpoints changes; e.g. due to NAT rebinding or server IP address migration.  An observer keeping flow state can associate a connection <del> ID with a given flow, and can associate a known flow with a new flow when when observing a packet sharing a connection ID and one endpoint address (IP address and port) with the known flow. </del>  However, since the connection ID may change multiple times during the lifetime of a flow, and the negotiation of connection ID changes is

Reviewer comments:
This is branched of . NAME said: "However, it needs to specify that the connection ID association needs to be directional. Maybe that is assumed, but it should be stated. And it needs to say that this is unlikely to apply when the connection ID is empty."
NAME I created PR . Does that address this point sufficiently?

Revised text:
identified by five-tuple when the address and port of one of the endpoints changes; e.g. due to NAT rebinding or server IP address migration.  An observer keeping flow state can associate a connection  <ins> ID, if present, with a given flow, and can associate a known flow with a new flow when when observing a packet sharing the same connection ID in the same direction between client and server and sharing one endpoint address (IP address and port) with the known flow. </ins> However, since the connection ID may change multiple times during the lifetime of a flow, and the negotiation of connection ID changes is
Original text:
difference is that TCP does not provide stream multiplexing and therefore stream multiplexing would need to be implemented in the application layer if needed.  Further, TCP implementations and <del> network paths often do not support the Fast Open option, which is analogous to 0-RTT session resumption.  Note that there is some evidence of middleboxes blocking SYN data even if TFO was successfully negotiated (see PaaschNanog).  And even if Fast Open successfully operates end-to-end, it is limited to a single packet of payload, unlike QUIC 0-RTT. </del>  Moreover, while encryption (in this case TLS) is inseparably integrated with QUIC, TLS negotiation over TCP can be blocked.  If

Reviewer comments:
I don't think this sentence was accurate. TFO isn't analogous to 0-RTT session resumption, but it's needed to achieve the same application effect.
maybe analogous wasn't the right term but I'm also not sure about the word "true" here...
NAME "true" meaning "actual", i.e. you can resume a session without a round trip. We could specify that further but it probably has to be more wordy.

Revised text:
difference is that TCP does not provide stream multiplexing and therefore stream multiplexing would need to be implemented in the application layer if needed.  Further, TCP implementations and  <ins> network paths often do not support the Fast Open option RFC7413, which enables sending of payload data together with the first control packet of a new connection as also provided by 0-RTT session resumption in QUIC.  Note that there is some evidence of middleboxes blocking SYN data even if TFO was successfully negotiated (see PaaschNanog).  And even if Fast Open successfully operates end-to- end, it is limited to a single packet of TLS handshake and application data, unlike QUIC 0-RTT. </ins> Moreover, while encryption (in this case TLS) is inseparably integrated with QUIC, TLS negotiation over TCP can be blocked.  If
Original text:
stream.  If a stream that is critical for an application is closed, the application can generate error messages on the application layer to inform the other end and/or the higher layer, which can eventually <del> reset the QUIC connection. </del>  Mapping of application data to streams is application-specific and described for HTTP/3 in QUIC-HTTP.  There are a few general

Reviewer comments:
Reset is a directional stream semantic, not a connection one.
Actually the idea here was not necessarily talk about the semantics of how a connection is closed. So maybe using something else like "abort" would avoid any confusion here...?
Oh, I see. Yeah maybe abort is better. For me reading this "reset" made me think of TCP connection and or QUIC stream semantics, which is probably not the intention.

Revised text:
stream.  If a stream that is critical for an application is closed, the application can generate error messages on the application layer to inform the other end and/or the higher layer, which can eventually  <ins> terminate the QUIC connection. </ins> Mapping of application data to streams is application-specific and described for HTTP/3 in QUIC-HTTP.  There are a few general
Original text:
least one RTT and congestion control will also be reset after path migration.  Therefore migration usually has a performance impact. <del> QUIC probing packets, which cannot carry application data, can be sent on multiple paths at once.  Probing packets can be used to perform address validation, measure path characteristics as input for the switching decision, or prime the congestion controller in preparation for switching to the new path. </del>  Only the client can actively migrate in version 1 of QUIC.  However, servers can indicate during the handshake that they prefer to

Reviewer comments:
addresses
The text says: “or prime the congestion controller in preparation for switching to the new path.” what does prime mean? and which section explains this function in the QUIC spec?
The idea here is that you can already e.g. estimate RTT or even open the congestion window before you switch. There was already some discussion previously (seePR ) if we want to have this in the document or say more or less. Maybe a question to the rest of the wg (in the next meeting)...?
Unsure about this in this ID: Isn't that suggesting a transport extension/mechanism update... rather than the applicable use?
I don't think it needs an extension. It can simply be done by the client. It's definitely not appropriate to specify a concrete algorithm in this document but it's just listed as one of the things that padding can be used during mitigation.
I'm really unsure about why text about priming is here and where the advice is located. I don't dispute that it can be done, or even that if done appropriately it can help, however it could also be done in a way that might also hinder. If PR 122 removes this word, then this topic can be discussed elsewhere in RFCs.
NAME PR was already merged a long time ago. I was just point at it to say that there has been previous discussion. As the label indicates, we plan to bring the for discussion to the meeting.
CC priming seems like an issue entirely internal to the QUIC implementation. Why should applications know or care about it? I suggest we simply delete this.
I like NAME suggestion.
is my proposal. It doesn't talk about priming/pre-heating anymore but it says what's possible and why this could be interesting for an application.
PR was merged.
Phrasing suggestion.

Revised text:
least one RTT and congestion control will also be reset after path migration.  Therefore migration usually has a performance impact.  <ins> QUIC probing packets, which can be sent on multiple paths at once, are used to perform address validation as well as measure path characteristics as input for the switching decision.  Probing packets cannot carry application data but may contain padding frames. Endpoints can use information about their receipt as input to congestion control for that path.  Applications could use information learned from probing to inform a decisions to switch paths. </ins> Only the client can actively migrate in version 1 of QUIC.  However, servers can indicate during the handshake that they prefer to
Original text:
streams QUIC.  Applications can implement their own prioritization scheme on top of QUIC: an application protocol that runs on top of QUIC can define explicit messages for signaling priority, such as <del> those defined for HTTP/2; it can define rules that allow an endpoint to determine priority based on context; or it can provide a higher level interface and leave the determination to the application on top. </del>  Priority handling of retransmissions can be implemented by the sender in the transport layer.  QUIC recommends retransmitting lost data

Reviewer comments:
for signaling priority, such as those defined for HTTP/2 First, if we retain this comment, it should probably have a reference to RFC 7540 and the appropriate section. However, as NAME noted in reply to a previous issue, this document is about QUIC, not TCP; the use of HTTP/2 as an exemplar seems out-of-place, particularly since we're actively deprecating that priority scheme. Perhaps a reference to draft-ietf-httpbis-priority would be more appropriate?
I agree that a reference to draft-ietf-httpbis-priority would be more appropriate.
Yes, sounds good. I'll create a PR if no-one else does it before me.

Revised text:
streams QUIC.  Applications can implement their own prioritization scheme on top of QUIC: an application protocol that runs on top of QUIC can define explicit messages for signaling priority, such as  <ins> those defined in I-D.draft-ietf-httpbis-priority for HTTP; it can define rules that allow an endpoint to determine priority based on context; or it can provide a higher level interface and leave the determination to the application on top. </ins> Priority handling of retransmissions can be implemented by the sender in the transport layer.  QUIC recommends retransmitting lost data
Original text:
Use of connection IDs is specifically discouraged for NAT applications.  If a NAT hits an operational limit, it is recommended to rather drop the initial packets of a flow (see also sec- <del> filtering), which potentially triggers a fallback to TCP, than using the connection ID to muliplex mulitple connections on the same IP address port pair which risks connectivity breakage later, in case the connection ID changes. </del>  4.3.

Reviewer comments:
NAME said in PR on section "Passive Network Performance Measurement and Troubleshooting": "I think the caution against using Connection ID needs to be a lot stronger. Things will break, users will notice. I realize that implementations have to use this to enforce that, but I believe some already are. See a comment below as well."
NAME is PR better? Note that you should also review the previous paragraphs as I believe the problems are described there clearly already.

Revised text:
Use of connection IDs is specifically discouraged for NAT applications.  If a NAT hits an operational limit, it is recommended to rather drop the initial packets of a flow (see also sec-  <ins> filtering), which potentially triggers a fallback to TCP.  Use of the connection ID to multiplex multiple connections on the same IP address/port pair is not a viable solution as it risks connectivity breakage, in case the connection ID changes. </ins> 4.3.
Original text:
QUIC-TRANSPORT).  Therefore, observing a new connection ID does not necessary indicate a new connection. <del> Server-generated connection IDs should seek to obscure any encoded routing identities or any other information.  Exposing the server mapping would allow linkage of multiple IP addresses to the same host if the server also supports migration.  Furthermore, this opens an attack vector on specific servers or pools. The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption.  Even when encrypted, a scheme could embed the unencrypted length of the connection ID in the connection ID itself, instead of remembering it. QUIC_LB further specifies possible algorithms to generate connection IDs at load balancers. </del>  2.7.

Reviewer comments:
repeats requirements from the transport spec unnecessarily. It might be easier to just strike this.
This is supposed to give advice to network operators e.g. in a load balancing setup where connection IDs are maybe generated centrally and distributed to the servers.
The surrounding text does. This paragraph does not.
I didn't think network operators who are in control of one of the endpoints would be considered in scope for this I-D. Surely the whole point is to advise network operators about what they should do with traffic they cannot hope to decrypt? If server endpoint operators are in scope, the Introduction should be revised. If they are not in scope, I could propose some words that essentially say "Don't bother trying to infer information from specific parts of the connection ID, for these reasons."
Okay, I think I see the problem now. Is better?
This is fine, but it presumes a lot about the outcome of things that aren't completely resolved in QUIC-LB. I think that I would like to see more of this left to QUIC-LB to deal with, especially if we are planning to publish this before QUIC-LB (which seems likely). That might mean being a lot more aggressive about cutting text here.

Revised text:
QUIC-TRANSPORT).  Therefore, observing a new connection ID does not necessary indicate a new connection.  <ins> QUIC_LB specifies algorithms for encoding the server mapping in a connection ID in order to share this information with selected on- path devices such as load balancers.  Server mappings should only be exposed to selected entities.  Uncontrolled exposure would allow linkage of multiple IP addresses to the same host if the server also supports migration which opens an attack vector on specific servers or pools.  The best way to obscure an encoding is to appear random to any other observers, which is most rigorously achieved with encryption.  As a result any attempt to infer information from specific parts of a connection ID is unlikely to be useful. </ins> 2.7.
Original text:
Moreover, while encryption (in this case TLS) is inseparably integrated with QUIC, TLS negotiation over TCP can be blocked.  If <del> TLS over TCP cannot be supported, the connection should be aborted instead, in order to enable the application to present a suitable prompt to the user that secure communication is unavailable. </del>  In summary, any fallback mechanism is likely to impose a degradation of performance and can degrade security; however, fallback must not

Reviewer comments:
I couldn't immediately parse, and I'm assuming this is a NiT, but I can always be surprised by nuances in security-related text, so I'm writing this as an issue: /If TLS over TCP cannot be supported, the connection should be aborted instead, in order to enable the application to present a suitable prompt to the user that secure communication is unavailable./ If TLS over TCP cannot be supported, the connection should be aborted, and the application should present a suitable prompt to the user that secure communication is unavailable./
I guess we can remove the "instead" but why did you change the "in order to"? The reason to abort instead of just moving on without security is, so that the application recognises and can tell the user.
NAME ?
OK on removing instead Is this better?: /If TLS over TCP cannot be supported, the connection should be aborted, and the application then ought to present a suitable prompt to the user that secure communication is unavailable./

Revised text:
Moreover, while encryption (in this case TLS) is inseparably integrated with QUIC, TLS negotiation over TCP can be blocked.  If  <ins> TLS over TCP cannot be supported, the connection should be aborted, and the application then ought to present a suitable prompt to the user that secure communication is unavailable. </ins> In summary, any fallback mechanism is likely to impose a degradation of performance and can degrade security; however, fallback must not
Original text:
4.5. RFC4787 describes possible packet filtering behaviors that relate to <del> NATs.  Though the guidance there holds, a particularly unwise </del>  behavior is to admit a handful of UDP packets and then make a decision as to whether or not to filter it.  QUIC applications are encouraged to fail over to TCP if early packets do not arrive at

Reviewer comments:
These two sections are slightly redundant, and could easily be merged because the advice they give is more or less identical.
I think better to group these two! The current filtering text describes "possible packet filtering behaviors that relate to NATs". I suggest an initial series of packet ALSO traverse other domain edge devices (such as DDOS detection, NIDS, etc) in the same way, so we should be clear that NAT/NAPT is an example:-)
discussion on 19 April editor's meeting: there's been a lot of minor editorial refactoring that improves the flow of the doc, making this merge less necessary. Still need to make sure we have examples other than NAT, though.
multiple-examples fixed in

Revised text:
4.5. RFC4787 describes possible packet filtering behaviors that relate to  <ins> NATs but is often also used is other scenarios where packet filtering is desired.  Though the guidance there holds, a particularly unwise </ins> behavior is to admit a handful of UDP packets and then make a decision as to whether or not to filter it.  QUIC applications are encouraged to fail over to TCP if early packets do not arrive at
Original text:
QUIC's stream multiplexing feature allows applications to run multiple streams over a single connection, without head-of-line <del> blocking between streams, associated at a point in time with a single five-tuple.  Stream data is carried within frames, where one QUIC packet on the wire can carry one or multiple stream frames. </del>  Streams can be unidirectional or bidirectional, and a stream may be initiated either by client or server.  Only the initiator of a

Reviewer comments:
It is sort of redundant (because it says connection) and maybe sort of misleading (QUIC connections only use a single 5-tuple at a time, so it is maybe correct, but also maybe not).

Revised text:
QUIC's stream multiplexing feature allows applications to run multiple streams over a single connection, without head-of-line  <ins> blocking between streams.  Stream data is carried within frames, where one QUIC packet on the wire can carry one or multiple stream frames. </ins> Streams can be unidirectional or bidirectional, and a stream may be initiated either by client or server.  Only the initiator of a