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

Commentary: … lished Are called Initial packets .
Paragraph (version A):
The packet number field is always present in the QUIC packet header
in version 1; however, it is always encrypted.  The encryption key
for packet number protection on handshake packets sent before
cryptographic context establishment is specific to the QUIC version,
while packet number protection on subsequent packets uses secrets
derived from the end-to-end cryptographic context.  Packet numbers
are therefore not part of the wire image that is visible to on-path
observers.
Paragraph (version B):
The packet number field is always present in the QUIC packet header
in version 1; however, it is always encrypted.  The encryption key
for packet number protection on Initial packets - which are sent
before cryptographic context establishment - is specific to the QUIC
version, while packet number protection on subsequent packets uses
secrets derived from the end-to-end cryptographic context.  Packet
numbers are therefore not part of the wire image that is visible to
on-path observers.
Draft: draft-ietf-quic-manageability

Commentary: Probably , but not certain Especially if you got it wrong regarding the connection ID . 
 If there is no connection is how would an endpoint identify connection on the same 5 - tuple then ( for QUICv1 ) ? 
 It is possible to run multiple connections on the same tuple with trial decryption .
Paragraph (version A):
Further, as QUIC has a connection ID, it is also possible to maintain
multiple QUIC connections over one 5-tuple.  However, if the
connection ID is zero length, all packets of the 5-tuple belong to
the same QUIC connection.
Paragraph (version B):
Further, as QUIC has a connection ID, it is also possible to maintain
multiple QUIC connections over one 5-tuple.  However, if the
connection ID is zero-length, all packets of the 5-tuple likely
belong to the same QUIC connection.
Draft: draft-ietf-quic-applicability

Commentary: No real changes here , just noting that " Server Retry " is n't really a thing . Retry is , and servers use it , that 's all .
Paragraph (version A):
QUIC provides a Server Retry packet that can be sent by a server in
response to the Client Initial packet.  The server may choose a new
connection ID in that packet and the client will retry by sending
another Client Initial packet with the server-selected connection ID.
This mechanism can be used to redirect a connection to a different
server, e.g. due to performance reasons or when servers in a server
pool are upgraded gradually, and therefore may support different
versions of QUIC.  In this case, it is assumed that all servers
belonging to a certain pool are served in cooperation with load
balancers that forward the traffic based on the connection ID.  A
server can choose the connection ID in the Server Retry packet such
that the load balancer will redirect the next Client Initial packet
to a different server in that pool.  Alternatively the load balancer
can directly offer a Retry service as further described in QUIC-LB.
Paragraph (version B):
QUIC provides a Retry packet that can be sent by a server in response
to the client Initial packet.  The server may choose a new connection
ID in that packet and the client will retry by sending another client
Initial packet with the server-selected connection ID.  This
mechanism can be used to redirect a connection to a different server,
e.g., due to performance reasons or when servers in a server pool are
upgraded gradually, and therefore may support different versions of
QUIC.
Paragraph (version B):
In this case, it is assumed that all servers belonging to a certain
pool are served in cooperation with load balancers that forward the
traffic based on the connection ID.  A server can choose the
connection ID in the Retry packet such that the load balancer will
redirect the next Initial packet to a different server in that pool.
Alternatively the load balancer can directly offer a Retry service as
further described in QUIC-LB.
Draft: draft-ietf-quic-applicability

Commentary: The text here mentioned the decision to use a new path twice . Also , probing packets almost always include padding frames now : we require that the datagram is full - sized when probing so that we can probe for MTU , and probing is almost certainly done with short header packets , where padding has to be inside the packet .
Paragraph (version A):
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.
Paragraph (version B):
QUIC probing packets, which can be sent on multiple paths at once,
are used to perform address validation as well as measure path
characteristics.  Probing packets cannot carry application data but
likely 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.
Draft: draft-ietf-quic-applicability

Commentary: The original was factually incorrect as a new path can be used before validating it .
Paragraph (version A):
Currently QUIC only supports failover cases.  Only one "path" can be
used at a time; and only when the new path is validated, all traffic
can be switched over to that new path.  Path validation means that
the remote endpoint is required to validate the new path before use
in order to avoid address spoofing attacks.  Path validation takes at
least one RTT and congestion control will also be reset after path
migration.  Therefore migration usually has a performance impact.
Paragraph (version B):
Currently QUIC only supports the use of a single network path at a
time, which enables failover use cases.  Path validation is required
so that endpoints validate paths before use to avoid address spoofing
attacks.  Path validation takes at least one RTT and congestion
control will also be reset after path migration.  Therefore migration
usually has a performance impact.
Draft: draft-ietf-quic-applicability

Commentary: You can associate packets with connections without a connection ID . So rather than say something that is factually incorrect , let 's just leave the next paragraph to establish the right impression ( that a connection ID is highly recommended ) . This text works without talking about zero - length connection IDs .
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, unless a zero-length value is used.
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 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.
Draft: draft-ietf-quic-applicability

Commentary: 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 ) .
Paragraph (version A):
QUIC's stream multiplexing feature allows applications to run
multiple streams over a single connection, without head-of-line
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.
Paragraph (version B):
QUIC's stream multiplexing feature allows applications to run
multiple streams over a single connection, without head-of-line
blocking between streams.  Stream data is carried within frames,
where one QUIC packet on the wire can carry one or multiple stream
frames.
Draft: draft-ietf-quic-manageability

Commentary: Read this for the first time in a while and the document has drifted slightly .
Paragraph (version A):
This document discusses manageability of the QUIC transport protocol,
focusing on caveats impacting network operations involving QUIC
traffic.  Its intended audience is network operators, as well as
content providers that rely on the use of QUIC-aware middleboxes,
e.g. for load balancing.
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.  Its intended audience is
network operators and equipment vendors who rely on the use of
transport-aware network functions.
Draft: draft-ietf-quic-manageability

Commentary: 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
Paragraph (version A):
RFC4787 describes possible packet filtering behaviors that relate to
NATs.  Though the guidance there holds, a particularly unwise
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
their destination I-D.ietf-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 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
their destination I-D.ietf-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-manageability

Commentary: We recently this sentence but the text two paragraphs up already says this . Here is my proposed change , however , maybe we can shorten this paragraph even further .
Paragraph (version A):
Note that the use of a connection ID to support connection migration
renders 5-tuple based filtering insufficient and requires more state
to be maintained by DDoS defense systems.  For the common case of NAT
rebinding, where the client's address changes without the client's
intent or knowledge, DDoS defense systems can detect a change in the
client's endpoint address by linking flows based on the server's
connection IDs.  However, QUIC's linkability resistance ensures that
a deliberate connection migration is accompanied by a change in the
connection ID.  In this case, the connection ID can not be used to
distinguish valid, active traffic from new attack traffic.
Paragraph (version B):
Note that the use of a connection ID to support connection migration
renders 5-tuple based filtering insufficient to detect active flows
and requires more state to be maintained by DDoS defense systems if
support of migration of QUIC flows is desired.  For the common case
of NAT rebinding, where the client's address changes without the
client's intent or knowledge, DDoS defense systems can detect a
change in the client's endpoint address by linking flows based on the
server's connection IDs.  However, QUIC's linkability resistance
ensures that a deliberate connection migration is accompanied by a
change in the connection ID.  In this case, the connection ID can not
be used to distinguish valid, active traffic from new attack traffic.
Paragraph (version A):
However, it is questionable whether connection migrations must be
supported during a DDoS attack.  However, for unintentional
mitigations, as is usually the case for NAT rebindings, the
connection ID can be used to track connections (see sec-flow-
association).  If the connection migration is not visible to the
network that performs the DDoS detection, an active, migrated QUIC
connection may be blocked by such a system under attack.  As soon as
the connection blocking is detected by the client, the client may
rely on the fast resumption mechanism provided by QUIC.  When clients
migrate to a new path, they should be prepared for the migration to
fail and attempt to reconnect quickly.
Paragraph (version B):
However, it is questionable whether connection migrations must be
supported during a DDoS attack.  While unintended migration without a
connection ID change can be more easily supported, it might be
acceptable to not support migrations of active QUIC connections that
are not visible to the network functions performing the DDoS
detection.  As soon as the connection blocking is detected by the
client, the client may be able to rely on the fast resumption
mechanism provided by QUIC.  When clients migrate to a new path, they
should be prepared for the migration to fail and attempt to reconnect
quickly.
Draft: draft-ietf-quic-manageability

Commentary: this did not flow nicely ... or we just remove that sentence .
Paragraph (version A):
Use of address rewriting to ensure routing stablity as an approach to
simplify operational routing conceals client address changes and will
therefore mask important signals that drive security mechanisms, and
as such opens QUIC up to various attacks.
Paragraph (version B):
Therefore, the use of address rewriting to ensure routing stability
can open QUIC up to various attacks, as it conceals client address
changes, and as such masks important signals that drive security
mechanisms.
Draft: draft-ietf-quic-manageability

Commentary: This paragraph is redundant with the previous paragraph , however , not sure I removed the right one now ...
Paragraph (version A):
QUIC endpoints support address migration and a QUIC connection can
survive a change of the IP address or ports by mapping the connection
ID, if present, to an existing connection.  Ideally a new connection
ID is used at the same time when the address/port changes to avoid
linkability.  As new connection IDs belonging to the same connection
are not known to on-path devices, network devices are not able to map
QUIC connections after a 4-tuple change.  As such, when the 4-tuple
changes, stateful devices lose their state and break connectivity if
state is required for forwarding, while the endpoints would otherwise
survive such a change.
Draft: draft-ietf-quic-applicability

Commentary: Based on the discussion in webtrans at IETF-110 , I guess we could be more explicit that QUIC streams do not guarantee to be received in any particular order .
Paragraph (version A):
A single stream provides ordering.  If the application requires
certain data to be received in order, that data should be sent on
the same stream.
Paragraph (version B):
A single stream provides ordering.  If the application requires
certain data to be received in order, that data should be sent on
the same stream.  There is no guarantee of transmission,
reception, or delivery order across streams.
Draft: draft-ietf-quic-applicability

Commentary: I could n'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 can not 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 can not 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 . 
 ? 
 OK on removing instead Is this better ? : /If TLS over TCP can not 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./
Paragraph (version A):
Moreover, while encryption (in this case TLS) is inseparably
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.
Paragraph (version B):
Moreover, while encryption (in this case TLS) is inseparably
integrated with QUIC, TLS negotiation over TCP can be blocked.  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.
Draft: draft-ietf-quic-manageability

Commentary: 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 did n'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 can not 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 " Do n'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 are n'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 .
Paragraph (version A):
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.
Paragraph (version A):
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.
Paragraph (version A):
QUIC_LB further specifies possible algorithms to generate connection
IDs at load balancers.
Paragraph (version B):
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.
Draft: draft-ietf-quic-manageability

Commentary: 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 . " 
 is PR better ? Note that you should also review the previous paragraphs as I believe the problems are described there clearly already .
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, 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.
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 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.
Draft: draft-ietf-quic-applicability

Commentary: process assumes that the set of versions that a server supports is fixed . This complicates the process for deploying new QUIC versions or disabling old versions when servers operate in clusters . This functionality was removed from -transport , and appears to refer to text in draft - ietf - quic - version - negotiation , but that draft is n't referenced at all . 
 I can add a reference to draft - ietf - quic - version - negotiation and make clear that this is an extension and not part of the base spec .
Paragraph (version A):
QUIC provides integrity protection for its version negotiation
process.  This process assumes that the set of versions that a server
supports is fixed.  This complicates the process for deploying new
QUIC versions or disabling old versions when servers operate in
clusters.
Paragraph (version B):
QUIC version 1 does not specify a version negotation mechanism in the
base spec but I-D.draft-ietf-quic-version-negotiation proposes an
extension.  This process assumes that the set of versions that a
server supports is fixed.  This complicates the process for deploying
new QUIC versions or disabling old versions when servers operate in
clusters.