jiebi/TextFlow huggingface dataset:
Original text:
close either the ingress or egress direction; these actions are fully independent of each other. <del> If a stream that is critical for an application is closed, the application can generate respective error messages on the application layer to inform the other end and/or the higher layer, and eventually indicate QUIC to reset the connection.  QUIC, however, does not need to know which streams are critical, and does not provide an interface for exceptional handling of any stream. </del>  Mapping of application data to streams is application-specific and described for HTTP/3 in QUIC-HTTP.  In general, data that can be

Reviewer comments:
after discussion with NAME we probably do want to keep the information that "all streams are equal" here. Reverse the order of the sentences here to not bury the lede.
I think that the text on can be removed. This was an interesting discussion in HTTP/3, but I'm not sure that the applicability statement needs to concern itself with this detail.
The intention was, given it was an interesting discussion in H3, it might worth mentioning as other application may have the same "problem". I think it doesn't hurt to keep it. Or is there any concern that the term "critical stream" is maybe not well enough defined?
This reads better for sure, aside from an odd bit of phrasing.

Revised text:
close either the ingress or egress direction; these actions are fully independent of each other.  <ins> QUIC does not provide an interface for exceptional handling of any 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 reset the QUIC connection. </ins> Mapping of application data to streams is application-specific and described for HTTP/3 in QUIC-HTTP.  In general, data that can be
Original text:
9.2.  While sufficiently robust connection ID generation schemes will mitigate linkability issues, they do not provide full protection. Analysis of the lifetimes of six-tuples (source and destination

Reviewer comments:
launches right into discussion of how linkability protections might be inadequate without really establishing what the requirements are or why they exist. This needs an introduction paragraph.
Note sure how much more we want to say here or can say at this point in time.... NAME if you have a more concrete idea what we should say here, can you give it a try and propose a PR?
Something like: Then launch into the existing discussion.
Sounds good to me. I can add that after you PR landed or you can add it to your PR.

Revised text:
9.2. <ins> QUIC requires that endpoints generate fresh connection IDs for use on new network paths.  Choosing values that are unlinkable to an outside observer ensures that activity on different paths cannot be trivially correlated using the connection ID. </ins> While sufficiently robust connection ID generation schemes will mitigate linkability issues, they do not provide full protection. Analysis of the lifetimes of six-tuples (source and destination
Original text:
6. <del> Supporting manageability of QUIC traffic inherently involves tradeoffs with the confidentiality of QUIC's control information; this entire document is therefore security-relevant. </del>  7.

Reviewer comments:
This is a proposal to mention some more things specifically in the security considerations section. At minimum we should add a sentence pointing the reader at the security consideration of the transport and tis drafts. I additionally, more or less, copied some notes from the transport draft that I found particular relevant for reader of the manageability draft. Comments welcome!
NAME any further thought here?
After removing normative language, it occurs to us that there might be other security considerations that we want to highlight from Transport and TLS in Manageability or (especially) Applicability.

Revised text:
6.  <ins> QUIC is an encrypted and authenticated transport.  That means, once the cryptographic handshake is complete, QUIC endpoints discard most packets that are not authenticated, greatly limiting the ability of an attacker to interfere with existing connections. However, some information is still observerable, as supporting manageability of QUIC traffic inherently involves tradeoffs with the confidentiality of QUIC's control information; this entire document is therefore security-relevant. More security considerations for QUIC are discussed in QUIC-TRANSPORT and QUIC-TLS, generally considering active or passive attackers in the network as well as attacks on specific QUIC mechanism. Version Negotiation packets do not contain any mechanism to prevent version downgrade attacks.  However, future versions of QUIC that use Version Negotiation packets are require to define a mechanism that is robust against version downgrade attacks.  Therefore a network node should not attempt to impact version selection, as version downgrade may result in connection failure. </ins> 7.
Original text:
See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for <del> applications using QUIC, as well. </del>  Application developers should note that any fallback they use when QUIC cannot be used due to network blocking of UDP should guarantee

Reviewer comments:
After removing normative language, it occurs to us that there might be other security considerations that we want to highlight from Transport and TLS in Manageability or (especially) Applicability.
Minor editorial nit.

Revised text:
See the security considerations in QUIC and QUIC-TLS; the security considerations for the underlying transport protocol are relevant for  <ins> applications using QUIC, as well.  Considerations on linkability, replay attacks, and randomness discussed in QUIC-TLS should be taken into account when deploying and using QUIC. </ins> Application developers should note that any fallback they use when QUIC cannot be used due to network blocking of UDP should guarantee
Original text:
connection should fail to allow the application to explicitly handle fallback to a less-secure alternative.  See fallback.  14. This work is partially supported by the European Commission under

Reviewer comments:
to the security considerations section?
Cross protocol attacks, traffic analysis, and migration are discussed as well in the transport draft, so this pointer might not be absolutely necessary. However, we might still want to have it and then I think these are the relevant sections to refer to.
Applicability to me seems to be mostly targeted to non-H3 users of QUIC, so I'm not sure the H3-specific considerations need to be mentioned here.
My thinking was to add that as reference for other applications that might need to consider similar attacks/security issues. At least half of the points in the hhtp/3 sec considerations are really http specific and probably don't have value for other applications but there are a number of points which are more general. Those points are to some extend probably also covered by the transport draft but may be explained in more detail in the h3 draft.

Revised text:
connection should fail to allow the application to explicitly handle fallback to a less-secure alternative.  See fallback. <ins> Further QUIC-HTTP provides security considerations specific to HTTP. However, discussions such as on cross protocol attacks, traffic analysis and padding, or migration might be relevant for other applications using QUIC as well. </ins> 14. This work is partially supported by the European Commission under
Original text:
endpoints may disable use of the spin bit by default, others only in specific deployment scenarios, e.g. for servers and clients where the RTT would reveal the presence of a VPN or proxy.  To avoid making <del> these connections identifiable based on the usage of the spin bit, it is recommended that all endpoints randomly disable "spinning" for at least one eighth of connections, even if otherwise enabled by default.  An endpoint not participating in spin bit signaling for a given connection can use a fixed spin value for the duration of the connection, or can set the bit randomly on each packet sent. </del>  When in use and a QUIC flow sends data continuously, the latency spin bit in each direction changes value once per round-trip time (RTT).

Reviewer comments:
This sentence is rather supposed to explain what's done in QUIC then giving any recommendation, therefore we can simply remove the "recommended" phrasing.

Revised text:
endpoints may disable use of the spin bit by default, others only in specific deployment scenarios, e.g. for servers and clients where the RTT would reveal the presence of a VPN or proxy.  To avoid making  <ins> these connections identifiable based on the usage of the spin bit, all endpoints randomly disable "spinning" for at least one eighth of connections, even if otherwise enabled by default.  An endpoint not participating in spin bit signaling for a given connection can use a fixed spin value for the duration of the connection, or can set the bit randomly on each packet sent. </ins> When in use and a QUIC flow sends data continuously, the latency spin bit in each direction changes value once per round-trip time (RTT).
Original text:
clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly.  4.5. Today, UDP is the most prevalent DDoS vector, since it is easy for

Reviewer comments:
The text is good however I don't understand its placement in the draft fully. Shouldn't this paragraph go into the previous section or even in an own section? I know the issue, that this PR is addressing, was about DDoS but if we want to have it in the DDoS section we need probably some more words explaining how Retry should be used in this case. Currently it comes a bit out of nothing and interrupts the reading flow of the rest of the text...
I am not really sure at all that the existing DDoS guidance is good advice; we have a somewhat more robust plan in quic-lb, which perhaps we should reference?
for that matter, the Retry packet does not make an appearance in this section at all, which seems like an oversight.
Yes to both. Can you provide an PR?
Yes, please assign this issue to me.

Revised text:
clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly. <ins> TCP syncookies RFC4937 are a well-established method of mitigating some kinds of TCP DDoS attacks.  QUIC Retry packets are the functional analogue to syncookies, forcing clients to prove possession of their IP address before committing server state. However, there are safeguards in QUIC against unsolicited injection of these packets by intermediaries who do not have consent of the end server.  See QUIC_LB for standard ways for intermediaries to send Retry packets on behalf of consenting servers. </ins> 4.5. Today, UDP is the most prevalent DDoS vector, since it is easy for
Original text:
versions of the protocol, or even be negotiated during the handshake via the use of transport parameters.  3.1.1. An in-network observer assuming that a set of packets belongs to a

Reviewer comments:
which is about "Network-visible information about QUIC flows". They are mentioned once, based on a recent edit, but the text before that does not introduce them or explain what they are. Maybe we can add a few more sentences also making sure that even though they could be observed in the client initial, they cannot be changed nor observed form the server (to understand final negotiation/support).

Revised text:
versions of the protocol, or even be negotiated during the handshake via the use of transport parameters. <ins> Even though transport parameters transmitted in the client initial are obserable by the network, they cannot be modified by the network without risking connection failure.  Further, the negotiated reply from the server cannot be observed, so observers on the network cannot know which parameters are actually in use. </ins> 3.1.1. An in-network observer assuming that a set of packets belongs to a
Original text:
acknowledgment signaling is carried inside QUIC's encrypted payload, and ACK manipulation is impossible.  Specifically, heuristics attempting to distinguish ACK-only packets from payload-carrying <del> packets based on packet size are likely to fail, and are emphatically NOT RECOMMENDED. </del>  4.7.

Reviewer comments:
The text says: “and are emphatically NOT RECOMMENDED.” I think I would agree with a strong encouragement to not do this, but I would suggest to not use upper case letters at this point, and I’m not sure “emphatically” is a great word in a RFC :-). I’d also note that the volume of ACK traffic really can be a problem that QUIC needs to address, because QUIC over radio (of various types) can be significantly more expensive or lower performant than TCP, precisely because the control/ACK traffic is much more and there is no opportunity for network mitigation - hence it behoves QUIC implementors to use appropriate methods.
I created an PR to address the first point. Regarding the second point: NAME do you want to propose additional text? However, if I think that would go the into applicability...?
Suggestion for text: On network paths where there is significant asymmetry, the transmission of QUIC ACKs can reduce the efficient use of network capacity or transmission opportunities. This effect occurs when the return capacity is significantly more constrained than the forward capacity, or the cost of transmission per packet is a significant component of the total transmission cost. Reducing the ratio of acknowledgements to data at the QUIC receiver can improve link utilization and reduce link transmission costs.

Revised text:
acknowledgment signaling is carried inside QUIC's encrypted payload, and ACK manipulation is impossible.  Specifically, heuristics attempting to distinguish ACK-only packets from payload-carrying  <ins> packets based on packet size are likely to fail, and are not recommended to use as a way to construe internals of QUIC's operation as those mechanisms can change, e.g., due to the use of extensions. </ins> 4.7.
Original text:
payload data. Moreover, while encryption (in this case TLS) is inseparably <del> integrated with QUIC, TLS negotiation over TCP can be blocked.  In case it is RECOMMENDED to abort the connection, allowing the application to present a suitable prompt to the user that secure communication is unavailable. </del>  3.

Reviewer comments:
I think the following sentence has issues: “In case it is RECOMMENDED to abort the connection, allowing the application to present a suitable prompt to the user that secure communication is unavailable.” I’m not sure I understand “In case” I’m not sure this should be upper case RFC2119, unless we decide to also make normative recommendations in other places. “allowing”..”unavailable” makes this award to read.
2119 issue also noted in .

Revised text:
payload data. Moreover, while encryption (in this case TLS) is inseparably  <ins> integrated with QUIC, TLS negotiation over TCP can be blocked.  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. </ins> 3.
Original text:
Server deployments with load balancers and other routing infrastructure need to ensure that this infrastructure consistently <del> routes packets to the correct server instance.  This might require coordination between servers and infrastructure.  One method of achieving this involves encoding routing information into the connection ID.  This ensures that there is no need to for servers and infrastructure to coordinate routing information for each connection. See QUIC-LB for more information. </del>  10.2.

Reviewer comments:
Does this make it easier to understand?
NAME is this better?
“Server deployments with load balancers and other routing infrastructure need to ensure that this infrastructure consistently routes packets to the correct server instance. “ could this be: “Server deployments with load balancers and other routing infrastructure that depends on observing the payload of IP packets need to ensure that this infrastructure consistently routes all the QUIC packet belonging to a connection to the same server instance.” Seems like that is helpful. Is there a relevant section in the OPS draft where the reader should be directed?
Not sure if you addition of "that depends on observing the payload of IP packets" is that helpful in the sentence. The whole point here that if you use load balancers with QUIC, looking only at the IP might not be enough. NAME can you have a look how to phrase this?
Is this referring to sec 9.1 of the applicability draft? Why refer to the ops draft when the current reference (QUIC-LB) has everything you would want to know about the subject? I don't understand what Gorry's new clause adds. In fact, the IP address is not in the payload so I don't believe it's even accurate. Are you trying to distinguish between L7 and L4 load balancers here?
I couldn't work out what the current sentence means what does "correctly" mean?
OK, I can reword this.
This is left open as there is a pending rewrite of the NAT section.
looks good to me.

Revised text:
Server deployments with load balancers and other routing infrastructure need to ensure that this infrastructure consistently  <ins> routes packets to the server instance that has the connection state, even if addresses, ports, and/or connection IDs change.  This might require coordination between servers and infrastructure.  One method of achieving this involves encoding routing information into the connection ID.  For an example of this technique, see QUIC-LB. </ins> 10.2.
Original text:
2.3. Applications that have a mapping for TCP as well as QUIC are expected <del> to use the same port number for both services.  However, as with TCP- based services, especially when application layer information is encrypted, there is no guarantee that a specific application will use the registered port, or the used port is carrying traffic belonging to the respective registered service.  For example, QUIC-HTTP specifies the use of Alt-Svc for discovery of HTTP/3 services on other ports. </del>  Further, as QUIC has a connection ID, it is also possible to maintain multiple QUIC connections over one 5-tuple.  However, if the

Reviewer comments:
It seems to me that QUIC is no different to other transports in respect of being able to utilise other port numbers, and it would be worth noting that this is normal. The present text might perhaps suggest this is specific to QUIC. Should the text reference RFC 7605 or something else just to explain ports don't imply specific application behaviour, but could infer this?.
The title of the pull request was cause for a momentary flutter - in that I don't see the port as carrying anything other than a reference to a convention - but the text is very good.

Revised text:
2.3. Applications that have a mapping for TCP as well as QUIC are expected  <ins> to use the same port number for both services.  However, as for all other IETF transports RFC7605, there is no guarantee that a specific application will use a given registered port, or that a given port carries traffic belonging to the respective registered service, especially when application layer information is encrypted.  For example, QUIC-HTTP specifies the use of Alt-Svc for discovery of HTTP/3 services on other ports. </ins> Further, as QUIC has a connection ID, it is also possible to maintain multiple QUIC connections over one 5-tuple.  However, if the
Original text:
acknowledgements) and/or application layer delay (e.g., waiting for a response to be generated).  It therefore provides devices on path a good instantaneous estimate of the RTT as experienced by the <del> application.  A simple linear smoothing or moving minimum filter can be applied to the stream of RTT information to get a more stable estimate. </del>  However, application-limited and flow-control-limited senders can have application and transport layer delay, respectively, that are edge observed in the upstream direction and that observed in the downstream direction, and vice versa.  4. In this section, we review specific network management and

Reviewer comments:
URL must be postprocessed to become metrics.
Waiting for more reviews, e.g. from NAME before we can merge.
The text describes an example for measuring the average RTT. I like that, but I think we should call out a little that the mean RTT is only one metric. When looking at management info, I'm often interested in min/max and variance... So: “A simple linear smoothing... to get a more stable estimate”. Quite so for a table average RTT. I’d prefer it if we could say something about RTT variance at this point. To me it is important that RTT measurements are clear, and we should never assume in a Spec that RTT is something specific, but more generally an estimate that needs to consider the variance.

Revised text:
acknowledgements) and/or application layer delay (e.g., waiting for a response to be generated).  It therefore provides devices on path a good instantaneous estimate of the RTT as experienced by the  <ins> application. </ins> However, application-limited and flow-control-limited senders can have application and transport layer delay, respectively, that are edge observed in the upstream direction and that observed in the downstream direction, and vice versa. <ins> Raw RTT samples generated using these techniques can be processed in various ways to generate useful network performance metrics.  A simple linear smoothing or moving minimum filter can be applied to the stream of RTT samples to get a more stable estimate of application-experienced RTT.  RTT samples measured from the spin bit can also be used to generate RTT distribution information, including minimum RTT (which approximates network RTT over longer time windows) and RTT variance (which approximates jitter as seen by the application). </ins> 4. In this section, we review specific network management and
Original text:
4.3.  Flow control provides a means of managing access to the limited buffers endpoints have for incoming data.  This mechanism limits the amount of data that can be in buffers in endpoints or in transit on

Reviewer comments:
Beware those who want to do something else.
Isn't this already covered by the next section on "Flow Control Deadlocks"? If not, what's missing? And can we just add a sentence or two there?
Though the specification does not insist upon it, most implementations will assume that stream data is reliably delivered in order. This means that senders will send until every byte is delivered or they decide to reset the stream (possibly based on STOP_SENDING). And it means that receivers won't make data available until a contiguous span of bytes starting at the last unread offset are available. Implementations might act differently, but variations from this behaviour would need to be agreed by both endpoints.
NAME can you propose text?

Revised text:
4.3. <ins> QUIC streams enable ordered and reliable delivery.  Though it is possible for an implementation to provide options that use streams for partial reliability or out-of-order delivery, most implementations will assume that data is reliably delivered in order. Under this assumption, an endpoint that receives stream data might not make forward progress until data that is contiguous with the start of a stream is available.  In particular, a receiver might withhold flow control credit until contiguous data is delivered to the application; see Section 2.2 of QUIC.  To support this receive logic, an endpoint will send stream data until it is acknowledged, ensuring that data at the start of the stream is sent and acknowledged first. An endpoint that uses a different sending behavior and does not negotiate that change with its peer might encounter performance issues or deadlocks. 4.4. </ins> Flow control provides a means of managing access to the limited buffers endpoints have for incoming data.  This mechanism limits the amount of data that can be in buffers in endpoints or in transit on