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

Commentary: after discussion with we probably do want to keep the information that " all streams are equal " here . Reverse the order of the sentences here to not bury the lede . 
 I think that the text on can be removed . This was an interesting discussion in HTTP/3 , but I 'm not sure that the applicability statement needs to concern itself with this detail . 
 The intention was , given it was an interesting discussion in H3 , it might worth mentioning as other application may have the same " problem " . I think it does n't hurt to keep it . Or is there any concern that the term " critical stream " is maybe not well enough defined ? 
 This reads better for sure , aside from an odd bit of phrasing .
Paragraph (version A):
If a stream that is critical for an application is closed, the
application can generate respective error messages on the application
layer to inform the other end and/or the higher layer, and eventually
indicate QUIC to reset the connection.  QUIC, however, does not need
to know which streams are critical, and does not provide an interface
for exceptional handling of any stream.
Paragraph (version B):
QUIC does not provide an interface for exceptional handling of any
stream.  If a stream that is critical for an application is closed,
the application can generate error messages on the application layer
to inform the other end and/or the higher layer, which can eventually
reset the QUIC connection.
Draft: draft-ietf-quic-manageability

Commentary: addresses 
 In " Connection ID and Rebinding " : " Even when encrypted , a scheme could embed the unencrypted length of the Connection ID in the Connection ID itself , instead of remembering it , e.g. by using the first few bits to indicate a certain size of a well - known set of possible sizes with multiple values that indicate the same size but are selected randomly . " I almost went and filed an issue against quic - lb to do this instead of just encoding a plaintext length like it does currently . But is this a good recommended practice ? ISTM that long headers would provide a bit of    for this mapping , making it not particularly effective for the complexity . 
 The idea was not to conceal the length but to avoid likability by identifying linked connection based on the existence of a certain length field . This might look slightly more random but I guess you also have to change your mapping more time to time . So not sure . I 'm fine to remove that half sentence and maybe add a sentence about likability instead ... ? 
 Yes , I would prefer deleting the quoted text , as I think it 's a solution that adds complexity for little apparent benefit . 
 Okay , will do that change after your PR has landed .
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,
e.g. by using the first few bits to indicate a certain size of a
well-known set of possible sizes with multiple values that indicate
the same size but are selected randomly.
Paragraph (version B):
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.
Draft: draft-ietf-quic-applicability

Commentary: This text in is incorrect . When you have sent that much data , the connection flow control limit can not be increased further . Consequently , though many additional streams can be opened when a stream hits this limit , you can not send any bytes on any of those streams . I recommend striking this sentence or replacing it with a note about this fundamental limit applying to all data conveyed in streams . 
 Happy to take a PR :-) 
 Pretty good . Thanks .
Paragraph (version A):
Streams can be unidirectional or bidirectional, and a stream may be
initiated either by client or server.  Only the initiator of a
unidirectional stream can send data on it.  Due to offset encoding
limitations, a stream can carry a maximum of 2^62-1 bytes in each
direction.  In the presently unlikely event that this limit is
reached by an application, the stream can simply be closed and
replaced with a new one.
Paragraph (version B):
Streams can be unidirectional or bidirectional, and a stream may be
initiated either by client or server.  Only the initiator of a
unidirectional stream can send data on it.
Paragraph (version B):
Due to encoding limitations on stream offsets and connection flow
control limits, both streams and connections can carry a maximum of
2^62-1 bytes in each direction.  In the presently unlikely event that
this limit is reached by an application, a new connection would need
to be established.
Draft: draft-ietf-quic-manageability

Commentary: It might be the case that this is true for the whole draft and we should just state this at the beginning but better to double - check ! 
 we will leave this issue open to double - check at the end
Paragraph (version A):
This document is focused on the protocol as presently defined in
QUIC-TRANSPORT and QUIC-TLS.  Non-invariant parts of the wire image
as described herein and in those documents cannot be used to identify
QUIC as a protocol, and cannot be relied upon to infer behavior of
future versions of QUIC.
Paragraph (version B):
This document describes only version 1 the QUIC protocol, whose wire
image is fully defined in QUIC-TRANSPORT and QUIC-TLS.  Note that
features of the wire image described herein and in those documents
may change in future versions of the protocol, and cannot be used to
identify QUIC as a protocol or to infer the behavior of future
versions of QUIC. sec-google-version provides non-normative guidance
on the identification of QUIC version 1 packets compared to other
deployed versions at the date if publication.
Draft: draft-ietf-quic-applicability

Commentary: note : when merged . 
 We should probably make it clear what the application can do here ( SPA for servers ; maybe intentional migration for clients ? ) I 'm not sure if migration is transparent to client applications or not . 
 The client application might have some knowledge if it 's behind a NAT or not and as such might want to indicate to use Conn ID or not . We can make that more explicit in the text . 
 I did some small edits on the text in the connection migration section but maybe you had something more in mind and want to propose more text ? 
 This whole section should then also be moved to after the Conn ID section . 
 I like the move of text to the manageability draft . If it were me , I 'd move " Server - Generated Connection ID " as well , as I do n't think apps need to worry about it , but it 's not a big deal . I think adding text about server preferred address is probably more important for this draft . 
 Added some more text in 
 we think the current state of the draft addresses this issue ; could you check and close this issue if so ?
Paragraph (version A):
QUIC supports connection migration by the client.  If a lower-layer
address changes, a QUIC endpoint can still associate packets with an
existing connection based on the Connection ID (see also connid) in
the QUIC header, if present.  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 a lower-layer
address changes, a QUIC endpoint can still associate packets with an
existing connection based on the Connection ID (see also connid) in
the QUIC header, if present.  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.  As such if the client is
known or likely to sit behind a NAT, use of a connection ID for the
server is strongly recommended.  A non-empty connection ID for the
server is also strongly recommended when migration is supported.
Paragraph (version B):
Only the client can actively migrate.  However, servers can indicate
during the handshake that they prefer to transfer the connection to a
different address after the handshake, e.g. to move from an address
that is shared by multiple servers to an address that is unique to
the server instance.  The server can provide an IPv4 and an IPv6
address in a transport parameter during the TLS handshake and the
client can select between the two if both are provided.  See also
Section 9.6 of QUIC.
Draft: draft-ietf-quic-manageability

Commentary: However , we also use the terms Server / Client Hello datagram to cover all QUIC Packets of the first two datagrams sent . This term is not used in the transport draft ( anymore ) and I find it confusing given the TLS terminology . Should we maybe use a different term ?
Paragraph (version A):
The Client Hello datagram exposes version number, source and
destination connection IDs, and information in the TLS Client Hello
message, including any TLS Server Name Indication (SNI) present, in
the clear.  The QUIC PADDING frame shown here may be present to
ensure the Client Hello datagram has a minimum size of 1200 octets,
to mitigate the possibility of handshake amplification.  Note that
the location of PADDING is implementation-dependent, and PADDING
frames may not appear in the Initial packet in a coalesced packet.
Paragraph (version A):
The Server Hello datagram exposes version number, source and
destination connection IDs, and information in the TLS Server Hello
message.
Paragraph (version B):
The Client Hello datagram exposes version number, source and
destination connection IDs in the clear.  Information in the TLS
Client Hello frame, including any TLS Server Name Indication (SNI)
present, is obfuscated using the Initial secret.  The QUIC PADDING
frame shown here may be present to ensure the Client Hello datagram
has a minimum size of 1200 octets, to mitigate the possibility of
handshake amplification.  Note that the location of PADDING is
implementation-dependent, and PADDING frames may not appear in the
Initial packet in a coalesced packet.
Paragraph (version B):
The Server Hello datagram also exposes version number, source and
destination connection IDs and information in the TLS Server Hello
message which is obfuscated using the Initial secret.
Draft: draft-ietf-quic-manageability

Commentary: From Spencer on the list : 
 addressed by
Paragraph (version A):
The only application binding currently defined for QUIC is HTTP QUIC-
HTTP.  HTTP over QUIC uses UDP port 443 by default, although URLs
referring to resources available over HTTP over QUIC may 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 RFC7605 section 5.
Paragraph (version A):
While the second most significant bit (0x40) of the first octet is
always set to 1 in QUIC packets of the current version, this is not a
recommended method of recognizing QUIC traffic, as it only provides
one bit of information and is quite prone to collide with UDP-based
protocols other than those that this static bit is meant to allow
multiplexing with.
Paragraph (version B):
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
over QUIC uses UDP port 443 by default, although URLs referring to
resources available over HTTP over QUIC may 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 RFC7605
section 5.
Paragraph (version B):
While the second most significant bit (0x40) of the first octet is
set to 1 in most QUIC packets of the current version (see public-
header), this method of recognizing QUIC traffic is NOT RECOMMENDED.
First, it only provides one bit of information and is quite prone to
collide with UDP-based protocols other than those that this static
bit is meant to allow multiplexing with.  Second, this feature of the
wire image is not invariant QUIC-INVARIANTS and may change in future
versions of the protocol, or even be negotiated after handshake via
future transport parameters.
Paragraph (version A):
In the rest of this section, we discuss only packets belonging to
Version 1 QUIC flows, and assume that these packets have been
identified as such through the observation of a version negotiation.
Paragraph (version B):
This document focuses on QUIC Version 1, and this section applies
only to packets belonging to Version 1 QUIC flows; for purposes of
on-path observation, it assumes that these packets have been
identified as such through the observation of a version negotiation.
Draft: draft-ietf-quic-manageability

Commentary: ( which did n't require any non - editorial changes ; the review is done now ) 
 Also call out invariants ( esp . in header structure and handshake ) explicitly : v2 may / will break functionality outside the invariants . 
 Document is currently in in with final invariants ; do one last pass to make sure everything documented in Section 17 as expose information appears here ( which is basically the same check ) .
Paragraph (version A):
QUIC packets may have either a long header, or a short header.  The
first bit of the QUIC header indicates which type of header is
present.
Paragraph (version B):
QUIC packets may have either a long header, or a short header.  The
first bit of the QUIC header us the Header Form bit, and indicates
which type of header is present.
Paragraph (version A):
demux bit: the second most significant bit of the first octet
every QUIC packet of the current version is set to 1, for
demultiplexing with other UDP-encapsulated protocols.
Paragraph (version B):
"fixed bit": the second most significant bit of the first octet
most QUIC packets of the current version is currently set to 1,
for demultiplexing with other UDP-encapsulated protocols.
Paragraph (version A):
header type: the long header has a 2 bit packet type field
following the Header Form bit.  Header types correspond to stages
of the handshake; see Section 17.2 of QUIC-TRANSPORT.
Paragraph (version B):
header type: the long header has a 2 bit packet type field
following the Header Form and fixed bits.  Header types correspond
to stages of the handshake; see Section 17.2 of QUIC-TRANSPORT for
details.
Paragraph (version A):
packet number: Most packets (with the exception of Version
Negotiation and Retry packets) have an associated packet number;
however, this packet number is encrypted, and therefore not of use
to on-path observers.  The offset of the packet number is encoded
in the header for packets with long headers, while it is implicit
(depending on Destination Connection ID length) in short header
packets.  The length of the packet number is cryptographically
obfuscated.
Paragraph (version B):
packet number: All packets except Version Negotiation and Retry
packets have an associated packet number; however, this packet
number is encrypted, and therefore not of use to on-path
observers.  The offset of the packet number is encoded in the
header for packets with long headers, while it is implicit
(depending on Destination Connection ID length) in short header
packets.  The length of the packet number is cryptographically
obfuscated.
Draft: draft-ietf-quic-applicability

Commentary: … ancers for further algos 
 The intention was not to encrypt the length ( as you say that would not be helpful ) but you should probably " grease " the length such that those bit can not be used to identify a certain system . That was the intention here . However , maybe this is too much detail and we should remove that sentence and only refer to the load - balancer draft instead ... ? 
 Note in section about CID that as the server chooses the CIDs , it could use some own scheme to embed the length of the CID in the CID itself , instead remembering it , e.g. use the first few bits to indicate which of the sizes that are support was chosen . 
 can be done together with , referencing the LB draft 
 PR to address this and reference to load balancer draft 
 Reading this again , I 'm not sure how I would improve the phrasing . Perhaps " embed the length of the connection ID in plaintext ... " .
Paragraph (version A):
The best way to obscure an encoding is to appear random to observers,
which is most rigorously achieved with encryption.
Paragraph (version B):
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,
e.g. by using the first few bits to indicate a certain size of a
well-known set of possible sizes with multiple values that indicate
the same size but are selected randomly.
Paragraph (version B):
QUIC_LB further specified possible algorithms to generate Connection
IDs at load balancers.
Draft: draft-ietf-quic-applicability

Commentary: References to quic - load - balancers and RFC5077 ( due to lack of a better reference ) 
 I thought the plan was to have a dependency on the load balancing draft rather than merging this part into the applicability draft . However , I would also be fine to add more text here and only have an informational reference , if some is willing to provide text ! 
 ... in the applicability statement ? I mean one example mechanism maybe ... 
 Can anybody help with that ? 
 The 5077 construction is pretty outdated ( it 's not even AEAD ) , unfortunately . 
 is there somewhere else we should look for current best practice , or do we need to invent something new here ? 
 I 'll find a stuckee for up - to - date crypto language here at the Zurich interim . 
 closing for now , could n't find any takers . 
 ... actually , it 's in the LB draft . Reference it . 
 PR proposed to address this issue ... 
 Are you prepared to take a dependency on QUIC - LB ?
Paragraph (version A):
to a different server in that pool.
Paragraph (version B):
to a different server in that pool.  Alternatively the load balancer
can directly offer a Retry services as further described in QUIC-LB.
Paragraph (version B):
RFC5077 Section 4 describes an example approach for constructing TLS
resumption tickets that can be also applied for validation tokens,
however, the use of more modern cryptographic algorithms is highly
recommended.
Draft: draft-ietf-quic-manageability

Commentary: But how long ... ? 
 For discussion : should the manageability draft advise that idle timeouts should be longer for flows inferred / detected to be QUIC flows ? I think the answer here is " it depends " : for NATs , yes , state at the edge is not all that scarce anymore . For firewalls ? Maybe not so much . Are there other applications to consider here , and is there any generalized advice this document could give ? If so , is there any generalized advice for how long the timeout should be ? 
 PR is an attempt to address this issue but does n't provide much concrete guidance ...
Paragraph (version A):
QUIC does not expose the end of a connection; the only indication to
on-path devices that a flow has ended is that packets are no longer
observed.  Stateful devices on path such as NATs and firewalls must
therefore use idle timeouts to determine when to drop state for QUIC
flows.
Paragraph (version B):
QUIC does not expose the end of a connection; the only indication to
on-path devices that a flow has ended is that packets are no longer
observed.  Stateful devices on path such as NATs and firewalls must
therefore use idle timeouts to determine when to drop state for QUIC
flows, see further section sec-stateful.
Paragraph (version B):
RFC4787 recommends a 2 minute timeout interval for UDP, however,
often timer are lower in the range of 15 to 30 second.  In constrast
RFC5382 recommends a timeout of more than 2 hours for TCP, given TCP
is a connection-oriented protocol with well defined closure
semantics.  For network devices that are QUIC-aware, it is
recommended to also use longer timeouts for QUIC traffic, as QUIC is
connection-oriented and as such a handshake packet from the server
indicates the willingness of the server to communicate with the
client.
Draft: draft-ietf-quic-manageability

Commentary: As noted in discussion on . 
 Quoting : 
 PR
Paragraph (version A):
the load balancer.
Paragraph (version B):
the load balancer I-D.ietf-quic-load-balancers.
Draft: draft-ietf-quic-manageability

Commentary: addresses 
 From  on the list : 
 addressed by
Paragraph (version A):
This document is focused on the protocol as presently defined in
QUIC-TRANSPORT and QUIC-TLS, and will change to track those
documents.
Paragraph (version B):
This document is focused on the protocol as presently defined in
QUIC-TRANSPORT and QUIC-TLS.  Non-invariant parts of the wire image
as described herein and in those documents cannot be used to identify
QUIC as a protocol, and cannot be relied upon to infer behavior of
future versions of QUIC.
Draft: draft-ietf-quic-manageability

Commentary: when merged . 
 See also issue quicwg / base - drafts 
 Good Strategy probably is to move quickly to new version and/or deploy draft versions in order to keep the version number field as dynamic as possible . However , if there will be ossification there is probably still a possibility to implement some kind of alternate version negotiation in the encrypted part of the packet and pretend on the outside to use the supported version ( similar as TLS1.3 does ) ; of course there is a performance / overhead trade - off . With the uncertainty about what will happen in respect to ossification , it might not be worth is to try and solve the problem now and pay the complexity up front . 
 does not appear as though the discussion on the list has converged yet ; will wait to see at happens in the base drafts before addressing this one in ops . 
 Consensus to handle " weak " version ossification via a mechanism in the transport ; holding this issue open until that converges , but probably not useful to have text in manageability . 
 This converged in Singapore to no - action in v1 . 
 Fixed by 
 My comments left the lines 80 characters , but otherwise LGI'm wondering if we should use even stronger language ; not that anything can really enforce it .
Paragraph (version B):
QUIC is expected to evolve rapidly, so new versions, both
experimental and IETF standard versions, will be deployed in 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 multi-year timeframe so therefore
not recommended.