jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-quic-applicability

Commentary: Thanks ! 
 LGTM
Paragraph (version A):
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
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.
Paragraph (version B):
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
the receiver.  Therefore, an application should consider the maximum
number of allowed, currently open, and currently used streams when
determining how to map data to streams.
Paragraph (version A):
QUIC version 1 without extensions uses an acknowledgment strategy
adopted from TCP Section 13.2 of QUIC).  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.
Paragraph (version B):
QUIC version 1 without extensions uses an acknowledgment strategy
adopted from TCP (see Section 13.2 of QUIC).  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.
Paragraph (version A):
QUIC supports connection migration by the client.  If an IP address
changes, a QUIC endpoint can still associate packets with an existing
transport connection using the Destination Connection ID field (see
also connid) in the QUIC header.  This supports cases where address
information changes, such as NAT rebinding, intentional change of the
local interface, or based on an indication in the handshake of the
server for a preferred address to be used.
Paragraph (version B):
QUIC supports connection migration by the client.  If the client's IP
address changes, a QUIC endpoint can still associate packets with an
existing transport connection using the Destination Connection ID
field (see also connid) in the QUIC header.  This supports cases
where address information changes, such as NAT rebinding, intentional
change of the local interface, or based on an indication in the
handshake of the server for a preferred address to be used.
Draft: draft-ietf-quic-applicability

Commentary: Thanks !
Paragraph (version A):
Specifically, fallback to insecure protocols or to weaker versions of
secure protocols needs to be avoided.  In general, an application
that implements fallback needs to consider the security consequences.
A fallback to TCP and TLS exposes control information to modification
and manipulation in the network.  Further, downgrades to older TLS
versions than 1.3, which is used in QUIC version 1, might result in
significantly weaker cryptographic protection.  For example, the
results of protocol negotiation RFC7301 only have confidentiality
protection if TLS 1.3 is used.
Paragraph (version B):
Specifically, fallback to insecure protocols or to weaker versions of
secure protocols needs to be avoided.  In general, an application
that implements fallback needs to consider the security consequences.
A fallback to TCP and TLS exposes control information to modification
and manipulation in the network.  Additionally, downgrades to older
TLS versions than 1.3, which is used in QUIC version 1, might result
in significantly weaker cryptographic protection.  For example, the
results of protocol negotiation RFC7301 only have confidentiality
protection if TLS 1.3 is used.
Paragraph (version A):
In the limit where connection migration in a server pool is rare, it
is trivial for an observer to associate two connection IDs.
Conversely, in the opposite limit where every server handles multiple
simultaneous migrations, even an exposed server mapping may be
insufficient information.
Paragraph (version B):
In the case where connection migration in a server pool is rare, it
is trivial for an observer to associate two connection IDs.
Conversely, in the opposite limit where every server handles multiple
simultaneous migrations, even an exposed server mapping may be
insufficient information.
Draft: draft-ietf-quic-manageability

Commentary: Instead of making an explicit policy recommendation with respect to version recognition , clarify the downsides of doing so . 
 I think this addresses the objection to policy recommendations on version recognition ; PTAL . thanks ! ! 
 I can live with the latest wording here , thanks ! And I did n't imagine that " traditional " was non - inclusive language ; traditions are an inexorable aspect of many cultures ... 
 I can see how some uses of the word tradition or traditional are non - inclusive . The occurences here do not strike me that way and the alternatives presented weaken the point of the text . We can proceed with an open mind to whether the term needs to be changed in response to wider review via subsequent review in the process . 
 My understanding is that " traditional " is also flagged because it 's usually not a clear term in technical documents and I think that 's the case here as well . There is no tradition about deploying certain protocols . We could just say " older " or " other protocols used so far " or something like this . 
 If you editors would like to replace it with a different term that conveys your intent , that 's fine by me . Perhaps switch traditional for " other commonly used " 
 s / traditional / most other / g ? 
 other commonly used is also good , but requires a manual rewrap . :) 
 thanks for addressing the in - solidarity bot
Paragraph (version A):
QUIC is expected to evolve rapidly, so new versions, both
experimental and IETF standard versions, will be deployed on the
Internet more often than with traditional Internet- and transport-
layer protocols.  Using a particular version number to recognize
valid QUIC traffic is likely to persistently miss a fraction of QUIC
flows and completely fail in the near future, and is therefore not
recommended.  In addition, due to the speed of evolution of the
protocol, devices that attempt to distinguish QUIC traffic from non-
QUIC traffic for purposes of network admission control should not
rely on the version number field.  Instead it is recommended to admit
all QUIC traffic regardless of version in order to support continuous
version-based evolution and avoid unnecessary deployment delays.
Paragraph (version B):
QUIC is expected to evolve rapidly, so new versions, both
experimental and IETF standard versions, will be deployed on the
Internet more often than with other commonly deployed Internet- and
transport-layer protocols.  Use of the version number field for
traffic recognition will therefore behave differently than with these
protocols.  Using a particular version number to recognize valid QUIC
traffic is likely to persistently miss a fraction of QUIC flows, and
completely fail in the near future.  Reliance on the version number
field for the purposes of admission control is similarly likely to
rapidly lead to unintended failure modes.  Admission of QUIC traffic
regardless of version avoids these failure modes, avoids unnecessary
deployment delays, and supports continuous version-based evolution.
Draft: draft-ietf-quic-manageability

Commentary: Addresses OPSDIR comment discussion . 
 hi -- does this better clarify language about recommendations in the introduction ? PTAL , thanks ! ! 
 Looks good to me . 
 I 'm not sure if this is actually fully true . We use the terms " recommended " or " recommendation " multiple times in this document and I do n't see a reason to remove it . I think these are the things that the quic group recommends , of course if anybody follows those recommendations is another questions . 
 so I 'm not removing the recommendations elsewhere ( modulo ) , just changing the language here to say " do n't think we think it 's a good idea for you just because we wrote it in general ) , which I think is indeed more true than what was here before ...
Paragraph (version A):
Network management is not a one-size-fits-all endeavour: practices
considered necessary or even mandatory within enterprise networks
with certain compliance requirements, for example, would be
impermissible on other networks without those requirements.  This
document therefore does not make any specific recommendations as to
which practices should or should not be applied; for each practice,
it describes what is and is not possible with the QUIC transport
protocol as defined.
Paragraph (version B):
Network management is not a one-size-fits-all endeavour: practices
considered necessary or even mandatory within enterprise networks
with certain compliance requirements, for example, would be
impermissible on other networks without those requirements.  The
presence of a particular practice in this document should therefore
not be construed as a recommendation to apply it.  For each practice,
this document describes what is and is not possible with the QUIC
transport protocol as defined.
Draft: draft-ietf-quic-manageability

Commentary: hi  , reviewed the thread and I do think an additional 9065 ref here would be helpful .
Paragraph (version B):
This document focuses solely on network management practices that
observe traffic on the wire.  Replacement of troubleshooting based on
observation with active measurement techniques, for example, is
therefore out of scope.  A more generalized treatment of network
management operations on encrypted transports is given in RFC9065.
Draft: draft-ietf-quic-manageability

Commentary: This seems like a fair reflection of the reality upon which we have landed .
Paragraph (version A):
The QUIC wire image is not specifically designed to be
distinguishable from other UDP traffic by a passive observer in the
network.
Paragraph (version B):
The QUIC wire image is not specifically designed to be
distinguishable from other UDP traffic by a passive observer in the
network.  While certain QUIC applications may be heuristically
identifiable on a per-application basis, there is no general method
for distinguishing QUIC traffic from otherwise-unclassifiable UDP
traffic on a given link.  Any unrecognized UDP traffic may therefore
be QUIC traffic.
Draft: draft-ietf-quic-manageability

Commentary: lgtm 
 IMO the PR is clearer ( and better reflects the intent / my understanding of WG consensus ) , so I 'd merge it then continue the discussion after the submission cutoff .
Paragraph (version A):
QUIC is expected to evolve rapidly, so new versions, both
experimental and IETF standard versions, will be deployed on the
Internet more often than with traditional Internet- and transport-
layer protocols.  Using a particular version number to recognize
valid QUIC traffic is likely to persistently miss a fraction of QUIC
flows and completely fail in the near future, and is therefore not
recommended.  In addition, due to the speed of evolution of the
protocol, devices that attempt to distinguish QUIC traffic from non-
QUIC traffic for purposes of network admission control should admit
all QUIC traffic regardless of version.
Paragraph (version B):
QUIC is expected to evolve rapidly, so new versions, both
experimental and IETF standard versions, will be deployed on the
Internet more often than with traditional Internet- and transport-
layer protocols.  Using a particular version number to recognize
valid QUIC traffic is likely to persistently miss a fraction of QUIC
flows and completely fail in the near future, and is therefore not
recommended.  In addition, due to the speed of evolution of the
protocol, devices that attempt to distinguish QUIC traffic from non-
QUIC traffic for purposes of network admission control should not
rely on the version number field.  Instead it is recommended to admit
all QUIC traffic regardless of version in order to support continious
version-based evolution and avoid unnecessary deployment delays.
Draft: draft-ietf-quic-manageability

Commentary: Based Al 's opsdir feedback . Thanks ! 
 With your suggestion , this LGTM
Paragraph (version A):
As shown here, the client can send 0-RTT data as soon as it has sent
its Client Hello, and the server can send 1-RTT data as soon as it
has sent its Server Hello.  The Client Completion flight contains at
least one Handshake packet and could also include an Initial packet.
QUIC packets in separate contexts during the handshake can be
coalesced (see coalesced) in order to reduce the number of UDP
datagrams sent during the handshake.  QUIC packets can be lost and
reordered, so packets within a flight might not be sent close in
time, though the sequence of the flights will not change, because one
flight depends upon the peer's previous flight.
Paragraph (version B):
As shown here, the client can send 0-RTT data as soon as it has sent
its Client Hello, and the server can send 1-RTT data as soon as it
has sent its Server Hello.  The Client Completion flight contains at
least one Handshake packet and could also include an Initial packet.
QUIC packets in separate contexts during the handshake can be
coalesced (see coalesced) in order to reduce the number of UDP
datagrams sent during the handshake.
Paragraph (version B):
Handshake packets can arrive out-of-order without impacting the
handshake as long as the reordering was not accompanied by extensive
delays that trigger a spurious Probe Timeout ({Section 6.2 of
RFC9002}).  If QUIC packets get lost or reordered, packets belonging
to the same flight might not be observed in close time succession,
though the sequence of the flights will not change, because one
flight depends upon the peer's previous flight.
Draft: draft-ietf-quic-manageability

Commentary: Per    opsdir review , review the use of these three terms and correct where appropriate .
Paragraph (version A):
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-
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.
Paragraph (version B):
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-
filtering), which potentially triggers TCP fallback.  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.
Paragraph (version A):
RFC4787 describes possible packet filtering behaviors that relate to
NATs but is often also used is other scenarios where packet filtering
is desired.  Though the guidance there holds, a particularly unwise
behavior admits a handful of UDP packets and then makes a decision to
whether or not filter later packets in the same connection.  QUIC
applications are encouraged to fail over to TCP if early packets do
not arrive at their destination QUIC-APPLICABILITY, as QUIC is based
on UDP and there are known blocks of UDP traffic (see sec-udp-1312).
Admitting a few packets allows the QUIC endpoint to determine that
the path accepts QUIC.  Sudden drops afterwards will result in slow
and costly timeouts before abandoning the connection.
Paragraph (version B):
RFC4787 describes possible packet filtering behaviors that relate to
NATs but is often also used is other scenarios where packet filtering
is desired.  Though the guidance there holds, a particularly unwise
behavior admits a handful of UDP packets and then makes a decision to
whether or not filter later packets in the same connection.  QUIC
applications are encouraged to fall back to TCP if early packets do
not arrive at their destination QUIC-APPLICABILITY, as QUIC is based
on UDP and there are known blocks of UDP traffic (see sec-udp-1312).
Admitting a few packets allows the QUIC endpoint to determine that
the path accepts QUIC.  Sudden drops afterwards will result in slow
and costly timeouts before abandoning the connection.
Draft: draft-ietf-quic-applicability

Commentary: This is a good piece of information . However , I could not put it into the context of this document . Please clarity how this TAPS arch matters here . 
 looks good to me . Now it is more clear that the following paragraph is actually about giving more context to fallback mechanism .
Paragraph (version A):
The IETF TAPS specifications I-D.ietf-taps-arch describe a system
with a common API for multiple protocols and some of the implications
of fallback between these different protocols, specifically
precluding fallback to insecure protocols or to weaker versions of
secure protocols.
Paragraph (version A):
An application that implements fallback needs to consider the
security consequences.  A fallback to TCP and TLS exposes control
information to modification and manipulation in the network.
Further, downgrades to older TLS versions than 1.3, which is used in
QUIC version 1, might result in significantly weaker cryptographic
protection.  For example, the results of protocol negotiation RFC7301
only have confidentiality protection if TLS 1.3 is used.
Paragraph (version B):
The IETF TAPS specifications I-D.ietf-taps-arch describe a system
with a common API for multiple protocols.  This is particularly
relevant for QUIC as it addresses the implications of fallback among
multiple protocols.
Paragraph (version B):
Specifically, fallback to insecure protocols or to weaker versions of
secure protocols needs to be avoided.  In general, a application that
implements fallback needs to consider the security consequences.  A
fallback to TCP and TLS exposes control information to modification
and manipulation in the network.  Further, downgrades to older TLS
versions than 1.3, which is used in QUIC version 1, might result in
significantly weaker cryptographic protection.  For example, the
results of protocol negotiation RFC7301 only have confidentiality
protection if TLS 1.3 is used.
Draft: draft-ietf-quic-manageability

Commentary: , why are we so specific about TLS crypto operations here , it could be anything like later mentioned ( waiting for a response to be send ) or simply work load in the endpoints . Overall the inclusion of the transport- and application - layer delay in RTT measurements has been described in different ways without mentioning why one matters more than the others in certain context while pointing to same thing . This need to be fixed . 
 The section you noted , is about the the handshake . As there is no data during the handshake , the main app - layer delay would be the crypto . Yes , there can always be additional random delays due to processing also on the NIC but these are usually smaller and therefore less relevant . Not sure what kind of change would be needed here . 
 it would be good to refer to same events that may cause application - layer delay , rather giving two different examples for the same application - layer delay . 
 Still not sure what you would like to see here . Can you make a proposal ? 
 Alternate proposal : remove the example ? 
 would actually work , but there are examples of application - layer delay in that later section , may be you want to bring that up here and only use one set of potential reasons for application - layer delay for the whole section .
Paragraph (version A):
Handshake RTT can be measured by adding the client-to-observer and
observer-to-server RTT components together.  This measurement
necessarily includes any transport- and application-layer delay (the
latter mainly caused by the asymmetric crypto operations associated
with the TLS handshake) at both sides.
Paragraph (version B):
Handshake RTT can be measured by adding the client-to-observer and
observer-to-server RTT components together.  This measurement
necessarily includes any transport- and application-layer delay at
both endpoints.
Draft: draft-ietf-quic-manageability

Commentary: As this document does not use normative language and still makes number of recommendations , I think it is best that the abstract and/or introduction of thid document need some text to clarify how the readers should interpret those recommendations 
 What exactly would you propose ? 
 hmm , the reason for not using normative language would be sufficient I think . 
 Not sure what to write . There is no requirement that normative language must be used in RFC and moreover this is not a protocol specification . However , these are not something that we should note in the abstract . 
 Can you make a proposal ? 
 I would simply expect the reason of not using normative language in this document ( I remember there was some discussions on it ) , perhaps best fit in the introduction section . 
 There is nothing really specific here . If you look at the other issue they do n't say much other than that we only provide recommendation and therefore do n't need normative language . I would prefer to not say anything as that could rather give a wrong impression .
Paragraph (version A):
This document discusses manageability of the QUIC transport protocol,
focusing on the implications of QUIC's design and wire image on
network operations involving QUIC traffic.  Its intended audience is
network operators and equipment vendors who rely on the use of
transport-aware network functions.
Paragraph (version B):
This document discusses manageability of the QUIC transport protocol,
focusing on the implications of QUIC's design and wire image on
network operations involving QUIC traffic.  It is intended as a
"user's manual" for the wire image, providing guidance for network
operators and equipment vendors who rely on the use of transport-
aware network functions.