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

Commentary: Section 4.8 of manageability draft expects that a per - flow basis DSCP and ECMP routing policy is used to ensure same treatment for all the packets belonging to same QUIC connection . I was wondering how does path migration impacts this ? As the new path , potentially via another network , has no idea about QUIC connection insuring all packets belonging to the same QUIC connection get uniform treatment will be difficult . what am I missing here ? 
 During path migration the congestion control is reset and therefore there is no assumption anymore that those packets need to be treated similarly . 
 Ok then packets belonging to same QUIC connection can be treated differently after path migration . I think it would be good to clarify it . 
 This is effectively already what the manageability draft says because it says  handling should be applied on a per flow basis where a flow is the 5 tuple . If there is a path migration event , the 5 - tuple changes . The path does need to be QUIC aware and should not use the CID . 
 can we close this issue ? 
 Potentially yes , but would have been better to put a ref . here to the section where this " If there is a path migration event , the 5 - tuple changes . The path does need to be QUIC aware and should not use the CID . " is discussed . if things are not discussed or referred in one place then one has to infer the same reasoning / conclusion , which I think not always obvious . 
 Okay , I another clarifying sentence and a reference to section 3.5 in PR
Paragraph (version A):
It is expected that any QoS handling in the network, e.g. based on
use of DiffServ Code Points (DSCPs) RFC2475 as well as Equal-Cost
Multi-Path (ECMP) routing, is applied on a per flow-basis (and not
per-packet) and as such that all packets belonging to the same QUIC
connection get uniform treatment.
Paragraph (version B):
It is expected that any QoS handling in the network, e.g. based on
use of DiffServ Code Points (DSCPs) RFC2475 as well as Equal-Cost
Multi-Path (ECMP) routing, is applied on a per flow-basis (and not
per-packet) and as such that all packets belonging to the same active
QUIC connection get uniform treatment.
Paragraph (version B):
Note that the 5-tuple of a QUIC connnection can change due to
migration.  In this case different flows are observed by the path and
maybe be treated differently, as congestion control is usualy reset
on migration (see also sec-flow-association).
Draft: draft-ietf-quic-applicability

Commentary: addresses 
 LGTM 
 should this be pointing to Section 2.2 or section 4.0 , flow control credit is described there ? I also think it will be good if section 4.4 of this document points to Section 4.0 of RFC9000 . specially when it talks about flow control credit updates . 
 I believe this reference was supposed to point to the following normative statement in 2.2 : Section 4 is also relevant but there is also a pointer to section 4 at the end of section 2.2 .... 
 I do n't think it is obvious here , also introducing " flow control credit " here does not help much without referencing to section 4.0 of RFC9000 . 
 PR add a reference to section 4 of RFC9000 in section 4.4 . of the applicability draft . I still think having the link to section 2.2 of RFC900 in section 4.3 is more clear . flow control credit is not a QUIIC specific term .
Paragraph (version A):
QUIC 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
the network.  However, there are several ways in which limits can
produce conditions that can cause a connection to either perform
suboptimally or deadlock.
Paragraph (version B):
QUIC flow control Section 4 of QUIC 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 the network.  However, there are several
ways in which limits can produce conditions that can cause a
connection to either perform suboptimally or deadlock.
Draft: draft-ietf-quic-manageability

Commentary: Looks good to me 
 , where does this data come from ? any reference will be great here . 
 is there something we can cite here ? 
 The best public data I 'm aware of is slide 10 of :
Paragraph (version A):
RFC4787 requires a network state timeout that is not less than 2
minutes for most UDP traffic.  However, in practice, a QUIC endpoint
can experience lower timeouts, in the range of 30 to 60 seconds.
Paragraph (version B):
RFC4787 requires a network state timeout that is not less than 2
minutes for most UDP traffic.  However, in practice, a QUIC endpoint
can experience lower timeouts, in the range of 30 to 60 seconds QUIC-
TIMEOUT.
Draft: draft-ietf-quic-manageability

Commentary: Looks good to me . thanks 
 , this needs examples . what about DNS over QUIC as some defined over QUIC ? but I would love to get educated on the deployment part and refer that from this doc to support this statement .
Paragraph (version A):
The only application binding defined by the IETF QUIC WG is HTTP/3
QUIC-HTTP at the time of this writing; however, many other
applications are currently being defined and deployed over QUIC, so
an assumption that all QUIC traffic is HTTP/3 is not valid.  HTTP/3
uses UDP port 443 by convention but various methods can be used to
specify alternate port numbers.  Simple assumptions about whether a
given flow is using QUIC based upon a UDP port number may therefore
not hold; see also Section 5 of RFC7605.
Paragraph (version B):
At the time of writing, two application bindings for QUIC have been
published or adopted by the IETF: HTTP/3 QUIC-HTTP and DNS I-D.ietf-
dprive-dnsoquic.  These are both known to have active internet
deployments, so an assumption that all QUIC traffic is HTTP/3 is not
valid.  HTTP/3 uses UDP port 443 by convention but various methods
can be used to specify alternate port numbers.  Simple assumptions
about whether a given flow is using QUIC based upon a UDP port number
may therefore not hold; see also Section 5 of RFC7605.
Draft: draft-ietf-quic-manageability

Commentary: Section 4.7 of the manageability draft needs a reference to the fast resumption mechanism . 
 this s 0 - RTT session resumption as explained early in the doc and respectively referred there to the QUIC spec . Would it help to change " fast resumption " to " 0 - RTT session resumption " ? 
 I think so . 
 where was in the document 0 - RTT session resumption explained ? I might have missed it . 
 He have separate figures for that in the handshake section 
 However it seems we use the term " 0 - RTT connection resumption " there so , we should probably do a s / connection / session/ there as well .
Paragraph (version A):
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.
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 0-RTT session
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: , in the section 4.2 , end - of - flow and end - of - connection both are used in a way that they both point to the same observation event . if these are same then lets stick to only one of them otherwise lets describe in a way that they point to different observation points . 
 let 's use end - of - flow consistently .
Paragraph (version A):
While QUIC has no clear network-visible end-of-connection signal and
therefore does require timer-based state removal, the QUIC handshake
indicates confirmation by both ends of a valid bidirectional
transmission.  As soon as the handshake completed, timers should be
set long enough to also allow for short idle time during a valid
transmission.
Paragraph (version B):
While QUIC has no clear network-visible end-of-flow signal and
therefore does require timer-based state removal, the QUIC handshake
indicates confirmation by both ends of a valid bidirectional
transmission.  As soon as the handshake completed, timers should be
set long enough to also allow for short idle time during a valid
transmission.
Draft: draft-ietf-quic-manageability

Commentary: instead of sec 9 ( migration ) 
 , is this referring to the right section ? if yes then can it be made specific to a particular subsection ? I noted that RFC9000 describes the potential amplification attack in section 21.3 
 Yes this should probably be section 8 ; 21.3 is not relevant here .
Paragraph (version A):
Applying address translation at a middlebox to maintain a stable
address-port mapping for flows based on connection ID might seem like
a solution to this problem.  However, hiding information about the
change of the IP address or port conceals important and security-
relevant information from QUIC endpoints and as such would facilitate
amplification attacks (see Section 9 of QUIC-TRANSPORT).  A NAT
function that hides peer address changes prevents the other end from
detecting and mitigating attacks as the endpoint cannot verify
connectivity to the new address using QUIC PATH_CHALLENGE and
PATH_RESPONSE frames.
Paragraph (version B):
Applying address translation at a middlebox to maintain a stable
address-port mapping for flows based on connection ID might seem like
a solution to this problem.  However, hiding information about the
change of the IP address or port conceals important and security-
relevant information from QUIC endpoints and as such would facilitate
amplification attacks (see Section 8 of QUIC-TRANSPORT).  A NAT
function that hides peer address changes prevents the other end from
detecting and mitigating attacks as the endpoint cannot verify
connectivity to the new address using QUIC PATH_CHALLENGE and
PATH_RESPONSE frames.
Draft: draft-ietf-quic-manageability

Commentary: , clarify that the CE marking is observed at IP packet header and also provide a ref to CE marking
Paragraph (version A):
Limited RTT measurement is possible by passive observation of QUIC
traffic; see sec-rtt.  No passive measurement of loss is possible
with the present wire image.  Limited observation of upstream
congestion may be possible via the observation of CE markings on ECN-
enabled QUIC traffic.
Paragraph (version B):
Limited RTT measurement is possible by passive observation of QUIC
traffic; see sec-rtt.  No passive measurement of loss is possible
with the present wire image.  Limited observation of upstream
congestion may be possible via the observation of CE markings in the
IP header RFC3168 on ECN-enabled QUIC traffic.
Draft: draft-ietf-quic-manageability

Commentary: , what is a pure - acknowledgment ( ACK ) packet ?
Paragraph (version A):
Some deployed in-network functions distinguish pure-acknowledgment
(ACK) packets from packets carrying upper-layer data in order to
attempt to enhance performance, for example by queueing ACKs
differently or manipulating ACK signaling RFC3449.  Distinguishing
ACK packets is possible in TCP, but is not supported by QUIC, since
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
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.
Paragraph (version B):
Some deployed in-network functions distinguish packets that carry
only acknowledgment (ACK-only) information from packets carrying
upper-layer data in order to attempt to enhance performance, for
example by queueing ACKs differently or manipulating ACK signaling
RFC3449.  Distinguishing ACK packets is possible in TCP, but is not
supported by QUIC, since 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 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.
Draft: draft-ietf-quic-manageability

Commentary: I am not sure what does the last sentence supposed to add to the context and see it is something more important for the applicability part than manageability part . 
 I already clarified the sentence in PR related to issue . Or is this the wrong reference ? 
 ok , fine with me . 
 , padding and padding frames have been discussed / mentioned several times but I have n't got a clear indication on what does the padding to the manageability . Please point me to the description if I am mistaken .
Paragraph (version A):
QUIC explicitly exposes which side of a connection is a client and
which side is a server during the handshake.  In addition, the
symmetry of a flow (whether primarily client-to-server, primarily
server-to-client, or roughly bidirectional, as input to basic traffic
classification techniques) can be inferred through the measurement of
data rate in each direction.  While QUIC traffic is protected and
ACKs may be padded, padding is not required.
Paragraph (version B):
QUIC explicitly exposes which side of a connection is a client and
which side is a server during the handshake.  In addition, the
symmetry of a flow (whether primarily client-to-server, primarily
server-to-client, or roughly bidirectional, as input to basic traffic
classification techniques) can be inferred through the measurement of
data rate in each direction.  Note that QUIC packets containing only
control frames (such as ACK-only packets) may be padded.  Padding,
though optional, may conceal connection roles or flow symmetry
information.
Draft: draft-ietf-quic-manageability

Commentary: , I am not sure I get what this paragraph is supposed to mean . Number of things - first of all it is not clear that integrity protection actually simply the troubleshooting without defining that kind of troubleshooting we are referring to here and who is doing those , even though it is true that now network nodes can not modify the transport layer information . we are making a statement that in - network operations depends on modification of data , what is the data here ? payload ? header information ? both ? I think here we can reference to the I - D.ietf - tsvwg - transport - encrypt to setup the background information required to parse the statement correctly . I am not sure how a proxy here can support modification of data . Yes , that is my read of this last of the statement . Hence , hence we might want to clarify what is the scope of this collaboration that we are referring to . 
 addressed by
Paragraph (version A):
Integrity protection can also simplify troubleshooting, because none
of the nodes on the network path can modify transport layer
information.  However, it means in-network operations that depend on
modification of data are not possible without the cooperation of an
QUIC endpoint.  This might be possible with the introduction of a
proxy which authenticates as an endpoint.  Proxy operations are not
in scope for this document.
Paragraph (version B):
Integrity protection can also simplify troubleshooting at the end
points as none of the nodes on the network path can modify transport
layer information.  However, it means in-network operations that
depend on modification of data (e.g. see RFC9065 are not possible
without the cooperation of an QUIC endpoint.  Such cooperation might
be possible with the introduction of a proxy which authenticates as
an endpoint.  Proxy operations are not in scope for this document.
Draft: draft-ietf-quic-manageability

Commentary: , can we be more specific here about the control signal we are talking about is QUIC protocol control signal not really other kind of control signal that the network might have ? also here it is compared with TCP , should it also mention TCP with TLS ? 
 I the term " transport - layer " in PR . Does that help . I do n't think TLS needs to be mentioned here .
Paragraph (version A):
QUIC is an end-to-end transport protocol.  No information in the
protocol header, even that which can be inspected, is mutable by the
network.  This is achieved through integrity protection of the wire
image WIRE-IMAGE.  Encryption of most control signaling means that
less information is visible to the network than is the case with TCP.
Paragraph (version B):
QUIC is an end-to-end transport protocol.  No information in the
protocol header, even that which can be inspected, is mutable by the
network.  This is achieved through integrity protection of the wire
image WIRE-IMAGE.  Encryption of most transport-layer control
signaling means that less information is visible to the network than
is the case with TCP.
Draft: draft-ietf-quic-manageability

Commentary: well I do n't think transport protocol will be using any of the tools rather those tools can be used to observer multiple protocols
Paragraph (version A):
On-path devices can also make measurements of RTT, loss and other
performance metrics when information is carried in an additional
network-layer packet header (Section 6 of I-D.ietf-tsvwg-transport-
encrypt describes use of operations, administration and management
(OAM) information).  Using network-layer approaches also has the
advantage that common observation and analysis tools can be
consistently used by multiple transport protocols, however, these
techniques are often limited to measurements within one or multiple
cooperating domains.
Paragraph (version B):
On-path devices can also make measurements of RTT, loss and other
performance metrics when information is carried in an additional
network-layer packet header (Section 6 of I-D.ietf-tsvwg-transport-
encrypt describes use of operations, administration and management
(OAM) information).  Using network-layer approaches also has the
advantage that common observation and analysis tools can be
consistently used for multiple transport protocols, however, these
techniques are often limited to measurements within one or multiple
cooperating domains.
Draft: draft-ietf-quic-manageability

Commentary: Currently the document uses " will " . This might be a very valid assumption , but still it is an assumption hence I think it is better to use " May " instead of " Will " .
Paragraph (version A):
Version Negotiation packets are used by the server to indicate that a
requested version from the client is not supported (see Section 6 of
QUIC-TRANSPORT.  Version Negotiation packets are not intrinsically
protected, but future QUIC versions will use later encrypted messages
to verify that they were authentic.  Therefore, any modification of
this list will be detected and may cause the endpoints to terminate
the connection attempt.
Paragraph (version B):
Version Negotiation packets are used by the server to indicate that a
requested version from the client is not supported (see Section 6 of
QUIC-TRANSPORT.  Version Negotiation packets are not intrinsically
protected, but future QUIC versions could use later encrypted
messages to verify that they were authentic.  Therefore, any
modification of this list will be detected and may cause the
endpoints to terminate the connection attempt.
Draft: draft-ietf-quic-applicability

Commentary: typo fix and one proposal
Paragraph (version A):
Retransmission or (malicious) replay of data contained in 0-RTT
packets could cause the server side to receive two copies of the same
data.
Paragraph (version B):
Retransmission or (malicious) replay of data contained in 0-RTT
packets could cause the server side to receive multiple copies of the
same data.
Paragraph (version A):
Stream errors lead to stream termination.  The are signaled using
STOP_SENDING or RESET_STREAM frames, which contain only an error
code.
Paragraph (version B):
Stream errors lead to stream termination.  These are signaled using
STOP_SENDING or RESET_STREAM frames, which contain only an error
code.
Draft: draft-ietf-quic-applicability

Commentary: Suggesting a rewording to clarify various issues and correct some mistakes . 
 Previously scope of this text was agreed , but what appeared seems to me to have various NiTs : • Saying " every other packet is acknowledged " is a recommendation in RC9000 . I suggest citing also . • The text seems to conflate endpoint processing optimisation , and network path performance optimisation : /constraint/ was n't the correct word , but even /constrained/ was a value judgment on design traedoffs for any mobile / RF link - and many bandwidth - limited cabled link , which could be avoided by simply saying what is intended and saying either /which can impact performance of some types of network/ or /which can impact performance across some types of network/ ... depending on your viewpoint as an operator or application . • I think we can do better than , suggesting removing some and leaving might . This might be resolved in a PR .
Paragraph (version A):
QUIC version 1 without extensions uses an acknowledgment strategy
adopted from TCP.  That is, every other packet is acknowledged.
However, generating and processing QUIC acknowledgments can consume
significant resources, both in terms of processing costs and link
utilization, especially on constraint networks.  Some applications
might be able to improve overall performance by using alternative
strategies that reduce the rate of acknowledgments.
Paragraph (version B):
QUIC version 1 without extensions uses an acknowledgment strategy
adopted from TCP Section 13.2 of RFC9000).  That is, it recommends
every other packet is acknowledged.  However, generating and
processing QUIC acknowledgments consumes resources at a sender and
receiver.  Acknowledgments also incur forwarding costs and contribute
to link utilization, which can impact performance over some types of
network.  Applications might be able to improve overall performance
by using alternative strategies that reduce the rate of
acknowledgments.