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

Commentary: At  's suggestion I put the NAT guidance into a different draft : Sorry , I thought the notification went out automatically . Regardless , this change is fine . 
 The manageability draft should talk a little bit about NATS for QUIC . The laziest thing to do is just continue to have NAT mapping be by 4 - tuple , as it is today . This is actually fine . However , someone might attempt to be clever and use the CID as well . For example , client A and client B could share the same serverside address and port and the NAT can initially distinguish between the two because they have different CIDs . This appears to save address space , but does n't actually work because the server could switch to a new client connection ID . In this case , the NAT wo n't be able to determine which client to route to . 
 I think it 's also worth mentioning that using just the CID only is similarly broken , the fundamental underlying concept here is that subsequent CIDs are exchanged in a manner that the NAT can not see -- the only time it 's okay to use CIDs is if you 're colluding with one of the endpoints , as in QUIC LB . 
 At least recommend to use longer binding lifetimes for identified QUIC connections ? 
 See PR 
 Fixed in this doc by 
 Looks good to me . It might be worth adding a bit more ( see my detailed comment ) .
Paragraph (version A):
The QUIC header optionally contains a Connection ID which can be used
as additional entropy beyond the 5-tuple, if needed.  The QUIC
handshake needs to be observed in order to understand whether the
Connection ID is present and what length it has.
Paragraph (version B):
The QUIC header optionally contains a Connection ID which can be used
as additional entropy beyond the 5-tuple, if needed.  The QUIC
handshake needs to be observed in order to understand whether the
Connection ID is present and what length it has.  However, Connection
IDs may be renegotiated during a connection, and this renegotiation
is not visible to the path.  Keying state off the Connection ID may
therefore cause undetectable and unrecoverable loss of state in the
middle of a connection.  Use of Connection ID specifically
discouraged for NAT applications.
Draft: draft-ietf-quic-manageability

Commentary: addresses issue 
 See . 
 ISTM that this might also be an applicability thing as the " easy " solution involves the firewall to share state with the LB / frontend ( with all the scalability impact that entails ) . 
 PR add a little more text here . Please provide another PR if you think more text is needed ! 
 PR merged
Paragraph (version B):
The QUIC header optionally contains a Connection ID which can be used
as additional entropy beyond the 5-tuple, if needed.  The QUIC
handshake needs to be observed in order to understand whether the
Connection ID is present and what length it has.
Draft: draft-ietf-quic-applicability

Commentary: addresses issue 
 I think the applicability draft may benefit from exploring connection migration strategies as described in : 
 Do we also need to say anything about use of 0 - byte CID ? See quicwg / base - drafts 
 The transport draft already says : 
 addressed by PR and one more sentence 
 I do n’t see any text related to connection migration on that PR . 
 sorry wrong PR ; should be and is already merged 
 good modulo typos
Paragraph (version B):
QUIC supports connection migration.  Even if lower-layer addresses
(usually the 4-tuple of IP addresses and ports) changes, QUIC packets
can still be associated with an existing connection based on the
Connection ID (see also section connid) in the QUIC header, if
present.  This supports cases where address information changes due
to e.g.  NAT rebinding or change of the local interface.  Currently
QUIC only supports failover cases.  Only one "path" can be used at a
time, and as soon as the new path is validated all traffic will be
switched over to the next path.
Draft: draft-ietf-quic-applicability

Commentary: This PR also moves the whole section on Packetization as it should n't be under " Use of Streams " and adds an additional paragraph on packet sizes and padding . 
 I think the applicability draft may benefit from exploring connection migration strategies as described in : 
 Do we also need to say anything about use of 0 - byte CID ? See quicwg / base - drafts 
 The transport draft already says : 
 addressed by PR and one more sentence 
 I do n’t see any text related to connection migration on that PR . 
 sorry wrong PR ; should be and is already merged 
 quic could offer an appliaction interface to specify the use of fixed length packets as input for an algorithm that handles padding to enable concealment of application characteristics based on packet length 
 see PR 
 merged 
 also good modulo typos .
Paragraph (version B):
Similarly, an appliaction has usually no control about the length of
a QUIC packet on the wire.  However, QUIC provides the ability to add
a padding frame to impact the packet size.  This is mainly used by
QUIC itself in the first packet in order to ensure that the path is
capable of transferring packets of at least a certain size.
Additionally, a QUIC implementation can expose an application layer
interface to specify a certain packet size.  This can either be used
by the application to force certian packet sizes in specific use
cases/networks, or ensure that all packets are equally sized to
conceal potential leakage of application layer information when the
data sent by the application are not greedy.  Note the initial packet
must have a minimum size of 1200 bytes according to the QUIC
specification.  A receiver of a smaller initial packet may reject
this packet in order to avoid amplification attacks.
Draft: draft-ietf-quic-applicability

Commentary: This section was still empty so far . This PR also address issue . 
 This is related to quicwg / base - drafts and depends on the outcome there . 
 PR now indicated that the idle timeout could be exposed to the application . However , we should probably say a bit more what to do with it . I guess the minimum would be to say that the keep - alive frequency needs to be clearly smaller than the idle timeout , e.g. half the timeout . Is there anything more we could say ? any thoughts ? Or text you can provide ? 
 PR provides some more guidance now but it still does n't discuss suitable value or ranges . What values are used in current implementations ? Should we say more ? 
 See also PR 
 merged 
 This is good , modulo typos ( all edits as suggestions )
Paragraph (version B):
QUIC connections are closed either by expiration of an idle timeout
or by an explicit indication of the application that a connection
should be closed (immediate close).  While data could still be
received after the immediate close has been initiated by one endpoint
(for a limited time period), the expectation is that an immediate
close was negotiated at the application layer and therefore no
additional data is expected from both sides.
Paragraph (version B):
An immidate close will emit an CONNECTION_CLOSE frame.  This frames
has two sets of types: one for QUIC internal problems that might lead
to connection closure, and one for closures initiated by the
application.  An application using QUIC can define application-
specific error codes, e.g. see QUIC-HTTP section 8.1.  In the case of
a grateful shut-down initiated by the application after application
layer negotiation, a NO_ERROR code is expected.  Further, the
CONNECTION_CLOSE frame provides an optional reason field, that can be
used to append human-readable information to an error code.  Note
that QUIC RESET_STREAM and STOP_SENDING frames provide similar
capablities.  Usually application error codes are defined to be
applicabile to all three frames.
Paragraph (version B):
Alternatively, a QUIC connection will be silently closed by each
endpoint separately after an idle timeout.  The idle timeout is
announce for each endpoint during connection established and should
be accessible by the application.  If an application desires to keep
the connection open for longer than the announced timeout, it can
send keep-alives messages.  See {#resumption-v-keepalive} for further
guidance.
Draft: draft-ietf-quic-manageability

Commentary: Review and update text in -manageability to reflect BKK spin bit consensus : single spin bit is in the protocol spec now endpoints may opt out ( discuss why ; this is for any reason , not just proxies as suggested in ) , endpoints should probabilistically out out to provide cover for endpoints opting out 
 I am working on this . 
 what about having a privacy consideration section ? 
 I 'm not sure this fits in the scope of the document : can you say more about what you propose to be in this section ? The -manageability document is meant to be an independent user 's guide to the wire image , so information on the spin bit here will be more about how to measure it , not additional guidelines on how to generate it and when not to ( though such text might belong in -applicability ) Please coordinate with who will also be proposing text on spin measurement to bring over from draft - ietf - quic - spin - exp . 
 see PR 
 closed by merge of and
Paragraph (version A):
latency spin bit: the third most significant bit of first octet.
However, the is only used in short packet headers.  There it will
be set alternatingly to 0 or 1 by the endpoints such that tracking
edge transistions can be used to passively monitor the connection
RTT, see spin-usage for further details.
Paragraph (version B):
latency spin bit: the third most significant bit of first octet in
the short packet header.  The spin bit is set by endpoints such
that tracking edge transitions can be used to passively observe
end-to-end RTT.  See spin-usage for further details.
Draft: draft-ietf-quic-manageability

Commentary: ... addressing 
 Middlebox vendors ( and others as well ) used to TCP want to assume that the smallest packet might be ack packets . This is not true in QUIC , and manageabiity draft may want to say something about it . 
 Thanks for writing this up !
Paragraph (version A):
The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this
document.  It's not shouting; when these words are capitalized, they
have a special meaning as defined in RFC2119.
Paragraph (version B):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
Paragraph (version B):
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.  Distinguishing ACK
packets is trivial in TCP, but 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 emphatically
NOT RECOMMENDED.
Draft: draft-ietf-quic-manageability

Commentary: Address . 
 The section on " Passive network performance measurement and troubleshooting " is probably a bit too pessimistic . It 's probably worth pointing out that one part of network troubleshooting -- " find out which box to blame " -- is substantially easier . Thanks to integrity protection , most middleboxes , can drop , delay / rate limit , and corrupt , and that 's about it . These are fairly easy behaviors to diagnose . I 've had some conversations with customers afraid of not having their TCP headers anymore , and I believe this fear is largely misguided . If people agree this belongs in the draft , I can file a PR . 
 I agree the wording is very pessimistic . However , I do n't think your observation belongs in this section because it 's about measurement of performance metrics . There is a sentence in the introduction : " Given QUIC is an end - to - end transport protocol , all information in the protocol header , even that which can be inspected , is is not meant to be mutable by the network , and is therefore integrity - protected to the extent possible . " Maybe it makes sense to add another sentence right there to also emphasis the positive effect of that , like : " While more limited information compared to TCP is visible to the network , integrity protection can also make troubleshooting easier as none of the nodes on the network path can modify the transport layer information . " 
 LGTM , will fix  's suggestion manually . One nit , but LGTM . The nit is to avoid ambiguity that might arise from " transport " -- one might read that QUIC integrity - protects UDP headers as well , since those are technically transport .
Paragraph (version A):
QUIC QUIC-TRANSPORT is a new transport protocol currently under
development in the IETF quic working group, focusing on support of
semantics as needed for HTTP/2 QUIC-HTTP.  Based on current
deployment practices, QUIC is encapsulated in UDP and encrypted by
default.  The current version of QUIC integrates TLS QUIC-TLS to
encrypt all payload data and most control information.  Given QUIC is
an end-to-end transport protocol, all information in the protocol
header, even that which can be inspected, is is not meant to be
mutable by the network, and is therefore integrity-protected to the
extent possible.
Paragraph (version B):
QUIC QUIC-TRANSPORT is a new transport protocol currently under
development in the IETF quic working group, focusing on support of
semantics as needed for HTTP/2 QUIC-HTTP.  Based on current
deployment practices, QUIC is encapsulated in UDP and encrypted by
default.  The current version of QUIC integrates TLS QUIC-TLS to
encrypt all payload data and most control information.
Paragraph (version B):
Given that QUIC is an end-to-end transport protocol, all information
in the protocol header, even that which can be inspected, is not
meant to be mutable by the network, and is therefore integrity-
protected.  While less information is visible to the network than for
TCP, integrity protection can also simplify troubleshooting because
none of the nodes on the network path can modify the transport layer
information.
Draft: draft-ietf-quic-applicability

Commentary: This provides some advice about flow control and how it might produce deadlocks . This was originally quicwg / base - drafts . 
 lgtm modulo nitsnits .
Paragraph (version B):
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):
Deadlocks in flow control are possible for any protocol that uses
QUIC, though whether they become a problem depends on how
implementations consume data and provide flow control credit.
Understanding what causes deadlocking might help implementations
avoid deadlocks.
Paragraph (version B):
Large messages can produce deadlocking if the recipient does not
process the message incrementally.  If the message is larger than
flow control credit available and the recipient does not release
additional flow control credit until the entire message is received
and delivered, a deadlock can occur.  This is possible even where
stream flow control limits are not reached because connection flow
control limits can be consumed by other streams.
Paragraph (version B):
A common flow control implementation technique is for a receiver to
extend credit to the sender as a the data consumer reads data.  In
this setting, a length-prefixed message format makes it easier for
the data consumer to leave data unread in the receiver's buffers and
thereby withhold flow control credit.  If flow control limits prevent
the remainder of a message from being sent, a deadlock will result.
A length prefix might also enable the detection of this sort of
deadlock.  Where protocols have messages that might be processed as a
single unit, reserving flow control credit for the entire message
atomically ensures that this style of deadlock is less likely.
Paragraph (version B):
A data consumer can read all data as it becomes available to cause
the receiver to extend flow control credit to the sender and reduce
the chances of a deadlock.  However, releasing flow control credit
might mean that the data consumer might need other means for holding
a peer accountable for the state it keeps for partially processed
messages.
Paragraph (version B):
Deadlocking can also occur if data on different streams is
interdependent.  Suppose that data on one stream arrives before the
data on a second stream on which it depends.  A deadlock can occur if
the first stream is left unread, preventing the receiver from
extending flow control credit for the second stream.  To reduce the
likelihood of deadlock for interdependent data, the sender should
ensure that dependent data is not sent until the data it depends on
has been accounted for in both stream- and connection- level flow
control credit.
Paragraph (version B):
Some deadlocking scenarios might be resolved by cancelling affected
streams with STOP_SENDING or RST_STREAM.  Cancelling some streams
results in the connection being terminated in some protocols.
Draft: draft-ietf-quic-applicability

Commentary: should probably double - check my work here . This assumes that we take the compatible version upgrade stuff , but if we do n't , there 's only one sentence to remove . I 've tried to keep it abstract enough that the details wo n't matter . 
 LGTM . Thank you for writing it down ! 
 Moving this from quicwg / base - drafts to here . 
 can one of you maybe provide some text ? 
 is probably exactly what needs to be said for this issue . 
 lgtm
Paragraph (version B):
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):
A server that rolls out a new version of QUIC can do so in three
stages.  Each stage is completed across all server instances before
moving to the next stage.
Paragraph (version B):
In the first stage of deployment, all server instances start
accepting new connections with the new version.  The new version can
be enabled progressively across a deployment, which allows for
selective testing.  This is especially useful when the new version is
compatible with an old version, because the new version is more
likely to be used.
Paragraph (version B):
While enabling the new version, servers do not advertise the new
version in any Version Negotiation packets they send.  This prevents
clients that receive a Version Negotiation packet from attempting to
connect to server instances that might not have the new version
enabled.
Paragraph (version B):
During the initial deployment, some clients will have received
Version Negotiation packets that indicate that the server does not
support the new version.  Other clients might have successfully
connected with the new version and so will believe that the server
supports the new version.  Therefore, servers need to allow for this
ambiguity when validating the negotiated version.
Paragraph (version B):
The second stage of deployment commences once all server instances
are able accept new connections with the new version.  At this point,
all servers can start sending the new version in Version Negotiation
packets.
Paragraph (version B):
During the second stage, the server still allows for the possibility
that some clients believe the new version to be available and some do
not.  This state will persist only for as long as any Version
Negotiation packets take to be transmitted and responded to.  So the
third stage can follow after a relatively short delay.
Paragraph (version B):
The third stage completes the process by enabling validation of the
negotiation version as though the new version were disabled.
Paragraph (version B):
The process for disabling an old version or rolling back the
introduction of a new version uses the same process in reverse.
Servers disable validation of the old version, stop sending the old
version in Version Negotiation packets, then the old version is no
longer accepted.
Draft: draft-ietf-quic-manageability

Commentary: The last two paragraphs of the security considerations section were for a ( much earlier , probably pre - WG ) version of the document . Now that -manageability is basically a wire image users ' guide , they do n't belong . So let 's cut them .
Paragraph (version A):
Some of the properties of the QUIC header used in network management
are irrelevant to application-layer protocol operation and/or user
privacy.  For example, packet number exposure (and echo, as proposed
in this document), as well as connection establishment exposure for
1-RTT establishment, make no additional information about user
traffic available to devices on path.
Paragraph (version A):
At the other extreme, supporting current traffic classification
methods that operate through the deep packet inspection (DPI) of
application-layer headers are directly antithetical to QUIC's goal to
provide confidentiality to its application-layer protocol(s); in
these cases, alternatives must be found.
Draft: draft-ietf-quic-manageability

Commentary: -manageablility has guidelines on how to select ConnIDs at a server , which is really more an -applicability thing . This fixes that .
Paragraph (version A):
In the case of content distribution networking architectures
including load balancers, the connection ID provides a way for the
server to signal information about the desired treatment of a flow to
the load balancers.
Paragraph (version A):
Server-generated Connection IDs must not encode any information other
that that needed to route packets to the appropriate backend
server(s): typically the identity of the backend server or pool of
servers, if the data-center's load balancing system keeps "local"
state of all flows itself.  Care must be exercised to ensure that the
information encoded in the Connection ID is not sufficient to
identify unique end users.  Note that by encoding routing information
in the Connection ID, load balancers open up a new attack vector that
allows bad actors to direct traffic at a specific backend server or
pool.  It is therefore recommended that Server-Generated Connection
ID includes a cryptographic MAC that the load balancer pool server
are able to identify and discard packets featuring an invalid MAC.
Paragraph (version B):
In the case of content distribution networking architectures
including load balancers, the connection ID provides a way for the
server to signal information about the desired treatment of a flow to
the load balancers.  Guidance on assigning connection IDs is given in
QUIC-APPLICABILITY.