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

Commentary: Should there be a section about temporary address extension for IPv6 addresses RFC 8981 ( as some OS can be very aggressive in changing to the next IPv6 address ) ? Or is it ' just ' a case of NAT rebinding ? If the latter , then one sentence in the introduction could be useful . What is the recommendation for these addresses , should the application keep always the first address as long as it is valid ? or should it switch to a new one ? [  ] I do n't think this a problem as the address is usually ( at least today ) not changed during an on - going connection , or ? EVthe previously used address may have become invalid ( i.e. , has expired ) but this would only happen on very long - lasting connections . But my question is still the same : should the QUIC application tries to keep the ' original ' address or should it try to use the most recent one ? Giving guidance would be desirable ?
Paragraph (version A):
QUIC supports connection migration by the client.  If the client's IP
address changes, a QUIC endpoint can still associate packets with an
existing transport connection using the Destination Connection ID
field (see also connid) in the QUIC header.  This supports cases
where address information changes, such as NAT rebinding, intentional
change of the local interface, or based on an indication in the
handshake of the server for a preferred address to be used.
Paragraph (version B):
QUIC supports connection migration by the client.  If the client's IP
address changes, a QUIC endpoint can still associate packets with an
existing transport connection using the Destination Connection ID
field (see also connid) in the QUIC header.  This supports cases
where address information changes, such as NAT rebinding, intentional
change of the local interface, the expiration of a temporary IPv6
address RFC8981, or the server indicating a preferred address
Section 9.6 of QUIC.
Draft: draft-ietf-quic-applicability

Commentary: addresses 
 -- Would there be an opportunity to fingerprint a unique application using a specific experimental version number ( in an ecosystem of continuous evolution and experimentation suggested above ) ? [  ] I guess that is the whole point here and I think the answer is no . You might see new experimental version that come and go quickly and are deployed only by one vendor but I do n't think that will give you necessarily much insights about the application within the encrypted payload . Also experimental version are expected to be around for short times only and change quickly , thus you would be very busy to adapt your fingerprinting continuously . That 's why the recommendation is to not do it . [ Christian Huitema ] Application developers will try to evolve the version number . If that cause the packets to be somehow discarded , this will have a very predictable result : all QUIC implementations will set the version number to 1 in the clear text header , while the " real " version number will be negotiated as part of the encrypted payload . If we follow that path , the network managers will not have any usable signal about the QUIC version , and the application developers will have to use more complex software and carry four useless bytes in the initial packets . Truth is , this is most likely what will happen , given natural trends . I do n't know whether the text in the applicability statement will be enough to avoid that fate . 
 I do n't think we can say more about not using the version number to identify QUIC . However do we want to mention the risk of fingerprinting ? However , I guess that would rather something to add to the spec considerations in the applicability statement ?
Paragraph (version B):
The QUIC Versions Registry established in QUIC allows for provisional
registrations for experimentation.  Registration, also of
experimental versions, is important to avoid collision.  Experimental
versions should not be used long-term or registered as permanent to
minimize the risk of fingerprinting based on the version number.
Draft: draft-ietf-quic-manageability

Commentary: Found terminology that should be reviewed for inclusivity ; see for background and more guidance : Term " traditional " ; alternatives might be " classic " , " classical " , " common " , " conventional " , " customary " , " fixed " , " habitual " , " historic " , " long - established " , " popular " , " prescribed " , " regular " , " rooted " , " time - honored " , " universal " , " widely used " , " widespread " Term " invalid " ; alternatives might be " not valid " , " unenforceable " , " not binding " , " inoperative " , " illegitimate " , " incorrect " , " improper " , " unacceptable " , " inapplicable " , " revoked " , " rescinded "
Paragraph (version A):
Using ECMP to distribute packets from a single flow across multiple
network paths or any other non-uniform treatment of packets belong to
the same connection could result in variations in order, delivery
rate, and drop rate.  As feedback about loss or delay of each packet
is used as input to the congestion controller, these variations could
adversely affect performance.  Depending on the loss recovery
mechanism implemented, QUIC may be more tolerant of packet re-
ordering than traditional TCP traffic (see packetnumber).  However,
the recovery mechanism used by a flow cannot be known by the network
and therefore reordering tolerance should be considered as unknown.
Paragraph (version B):
Using ECMP to distribute packets from a single flow across multiple
network paths or any other non-uniform treatment of packets belong to
the same connection could result in variations in order, delivery
rate, and drop rate.  As feedback about loss or delay of each packet
is used as input to the congestion controller, these variations could
adversely affect performance.  Depending on the loss recovery
mechanism implemented, QUIC may be more tolerant of packet re-
ordering than typical TCP traffic (see packetnumber).  However, the
recovery mechanism used by a flow cannot be known by the network and
therefore reordering tolerance should be considered as unknown.
Draft: draft-ietf-quic-applicability

Commentary: The assumption that an application can be identified in the network based on the port number is less true today due to encapsulation , mechanisms for dynamic port assignments , and NATs . NATs do n't hide the destination port which traditionally identifies the application , so it feels wrong to add it to this list . It is true more and more applications use port 443 ( and HTTPS ) but we do n't see traditional applications ( eg IMAP , SMTP ) move to port 443 either . The mechanisms for dynamic port assignments themselves also seem to be on their way out . Is there anything but NFS still using portmap / rpc dynamic ports ( is it still using that even , since people hardcoded it to 2049 years ago anyway ) 
 There 's an example in that makes this true enough for QUIC that I 'd like to say something about it : UDP 443 does n't mean QUIC , and it does n't even mean HTTP/3 over QUIC , and HTTP/3 over QUIC does n't imply UDP 443 because ... well , of HTTP semantics ( but I do think  is right here -- " appearing in a URL " is probably the most widely used form of dynamic port assignment today ) . 
 I 've sent a reply to  by email and waiting for a response now . 
 For the record this is my mail reply : " [  ] There is actually an example : Microsoft 's SMB - over - QUIC uses 443 . I believe for QUIC more and more applications will just use h3 as a transport and simply go with 443 . However , do you think any changes to the text are needed ? If so , can you be more concrete ? " 
 RFC6335 also says this I removed NAT as we only talk about dest port here and another reference to RFC6335 in PR
Paragraph (version A):
In general, port numbers serve two purposes: "first, they provide a
demultiplexing identifier to differentiate transport sessions between
the same pair of endpoints, and second, they may also identify the
application protocol and associated service to which processes
connect" RFC6335.  The assumption that an application can be
identified in the network based on the port number is less true today
due to encapsulation, mechanisms for dynamic port assignments, and
NATs.
Paragraph (version B):
In general, port numbers serve two purposes: "first, they provide a
demultiplexing identifier to differentiate transport sessions between
the same pair of endpoints, and second, they may also identify the
application protocol and associated service to which processes
connect" RFC6335.  The assumption that an application can be
identified in the network based on the port number is less true today
due to encapsulation and mechanisms for dynamic port assignments, as
also noted in RFC6335.
Draft: draft-ietf-quic-applicability

Commentary: Section 7 talks about acknowledgment strategy , but it is not actually giving any examples of what the application can do . Since it is kind of a transport layer property and not an application layer property , it is unclear how an application [ developer ] can replace the " TCP like ack every other packet " functionality . Are there QUIC options to consider that do this ? If so , why not mention those here ? 
 I guess there is draft but not sure we want to add a reference ... ? 
 I guess we should at least add a reference to however that is currently expired :-( 
 I 've sent a reply to  by email and waiting for a response now . 
 Unsure why we would specifically reference this rather than other work : draft - li - quic - optimizing - ack - in - wlan/ , I expect the correct thing is to reference a WG RFC , and section 2.5 of RFC9065 is one way . Citing the WG ack frequency draft might additionally be useful . 
 For the record , this is what I replied by mail : " [ MK ] This is a whole research area of its own ... however , I create an issue to see if people think adding some reference might be useful . There is a wg draft in QUIC for an extension to negotiate the ack frequency and there is another individual draft about strategies for WLANs . Still , this is also not really QUIC specific . Similar proposals also exists for TCP . The difference is that with TCP the network can also do ACK thinning which is not possible with QUIC anymore . " 
 but  section 2.5 does n't talk about acks at all ... I still propose to add a reference to as this is a wg doc at least .
Paragraph (version A):
QUIC version 1 without extensions uses an acknowledgment strategy
adopted from TCP (see Section 13.2 of QUIC).  That is, it recommends
every other packet is acknowledged.  However, generating and
processing QUIC acknowledgments consumes resources at a sender and
receiver.  Acknowledgments also incur forwarding costs and contribute
to link utilization, which can impact performance over some types of
network.  Applications might be able to improve overall performance
by using alternative strategies that reduce the rate of
acknowledgments.
Paragraph (version B):
QUIC version 1 without extensions uses an acknowledgment strategy
adopted from TCP (see Section 13.2 of QUIC).  That is, it recommends
every other packet is acknowledged.  However, generating and
processing QUIC acknowledgments consumes resources at a sender and
receiver.  Acknowledgments also incur forwarding costs and contribute
to link utilization, which can impact performance over some types of
network.  Applications might be able to improve overall performance
by using alternative strategies that reduce the rate of
acknowledgments.  I-D.ietf-quic-ack-frequency describes an extension
to signal the desired delay of acknowledgments and discusses use
cases as well as implications for congestion control and recovery.
Draft: draft-ietf-quic-manageability

Commentary: " Here we assume a bidirectional observer " , let 's also state that there is no section about unidirectional observer ? 
 Not sure if we add something because I think it okay to state assumptions ... 
 " unless noted " states that we 'll note when something is unidirectionally observable , I 'm reviewing the language now to see if we missed any ...
Paragraph (version A):
The client's TLS ClientHello may contain a Server Name Indication
(SNI) RFC6066 extension, by which the client reveals the name of the
server it intends to connect to, in order to allow the server to
present a certificate based on that name.  It may also contain an
Application-Layer Protocol Negotiation (ALPN) RFC7301 extension, by
which the client exposes the names of application-layer protocols it
supports; an observer can deduce that one of those protocols will be
used if the connection continues.
Paragraph (version B):
The client's TLS ClientHello may contain a Server Name Indication
(SNI) RFC6066 extension, by which the client reveals the name of the
server it intends to connect to, in order to allow the server to
present a certificate based on that name.  SNI information is
available to unidirectional observers on the client-to-server path,
if present.
Paragraph (version B):
The TLS ClientHello may also contain an Application-Layer Protocol
Negotiation (ALPN) RFC7301 extension, by which the client exposes the
names of application-layer protocols it supports; an observer can
deduce that one of those protocols will be used if the connection
continues.
Paragraph (version A):
The round-trip time (RTT) of QUIC flows can be inferred by
observation once per flow, during the handshake, as in passive TCP
measurement; this requires parsing of the QUIC packet header and
recognition of the handshake, as illustrated in handshake.  It can
also be inferred during the flow's lifetime, if the endpoints use the
spin bit facility described below and in Section 17.3.1 of QUIC-
TRANSPORT.
Paragraph (version B):
The round-trip time (RTT) of QUIC flows can be inferred by
observation once per flow, during the handshake, as in passive TCP
measurement; this requires parsing of the QUIC packet header and
recognition of the handshake, as illustrated in handshake.  It can
also be inferred during the flow's lifetime, if the endpoints use the
spin bit facility described below and in Section 17.3.1 of QUIC-
TRANSPORT.  RTT measurement is available to unidirectional observers
when the spin bit is enabled.
Draft: draft-ietf-quic-manageability

Commentary: Could the first 1200 - byte QUIC packet be used to suspect a QUIC connection establishment ? [  ] Yes , I think if you look at the first packet as a whole you can be reasonably sure that you look at a quic packet . I guess this is an assumption throughout the whole document , as section 2.4 says : " New QUIC connections are established using a handshake , which is distinguishable on the wire and contains some information that can be passively observed . " [  ] Do we need to say more ? EVhummm I guess not even if the text in 2.4 is rather generic while the point in 3.1 is really specific . Perhaps adding which handshake properties are ' distinguishable ' already in section 2.4 ? 
 proposes to fix this with a forward reference .
Paragraph (version A):
New QUIC connections are established using a handshake, which is
distinguishable on the wire and contains some information that can be
passively observed.
Paragraph (version B):
New QUIC connections are established using a handshake, which is
distinguishable on the wire (see sec-identifying for details), and
contains some information that can be passively observed.
Draft: draft-ietf-quic-manageability

Commentary: Wire image mutability is more subtle than " is completely immutable " , and we get into the details later . New text is sufficient as contrast for TCP . 
 Section 1 states : No information in the protocol header , even that which can be inspected , is mutable by the network . This is enforced through integrity protection of the wire image [ WIRE - IMAGE ] . Section 2.1 states : Retry ( Section 17.2.5 of [ QUIC - TRANSPORT ] ) and Version Negotiation ( Section 17.2.1 of [ QUIC - TRANSPORT ] ) packets are not encrypted or protected in any way . Do these two statements conflict : re protection ? 
 retry packets are actually protected by the Retry Integrity Tag . However not sure about version negotiations ... ? 
 The text in section 2.1 . is already covered by issue and fixed by PR respectively . However , the text in section 1 needs fixing as well as VN packets are not really protected ...
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 enforced 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.
Paragraph (version B):
QUIC is an end-to-end transport protocol; therefore, no information
in the protocol header is intended to be mutable by the network.
This property is enforced 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: Text as proposed by  on list . 
 I do n't think it 's correct to claim that " all deployed versions are maintained in an IANA registry " - many versions are being and have been deployed that are not in that IANA registry at all ( see ) ; there is a huge range for experimental versions . 
 This was discussed on the list and has a proposed resolution ; PR to be submitted . 
 Also this was commented by   as well :
Paragraph (version A):
version number: the version number is present in the long header,
and identifies the version used for that packet.  During Version
Negotiation (see Section 17.2.1 of QUIC-TRANSPORT and version),
the version number field has a special value (0x00000000) that
identifies the packet as a Version Negotiation packet.  QUIC
version 1 uses version 0x00000001.  Operators should expect to
observe packets with other version numbers as a result of various
Internet experiments, future standards, and greasing (RFC7801).
All deployed versions are maintained in an IANA registry (see
Section 22.2 of QUIC-TRANSPORT).
Paragraph (version B):
version number: the version number is present in the long header,
and identifies the version used for that packet.  During Version
Negotiation (see Section 17.2.1 of QUIC-TRANSPORT and version),
the version number field has a special value (0x00000000) that
identifies the packet as a Version Negotiation packet.  QUIC
version 1 uses version 0x00000001.  Operators should expect to
observe packets with other version numbers as a result of various
Internet experiments, future standards, and greasing (RFC7801).
An IANA registry contains the values of all standardized versions
of QUIC, and may contain some proprietary versions (see
Section 22.2 of QUIC-TRANSPORT).  However, other versions of QUIC
can be expected to be seen in the Internet at any given time.
Draft: draft-ietf-quic-manageability

Commentary: Thanks !
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 in the
IP header RFC3168 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 Congestion
Experienced (CE) markings in the IP header RFC3168 on ECN-enabled
QUIC traffic.
Draft: draft-ietf-quic-manageability

Commentary: clarify why CID is present in all headers but is also optional ... see issue 
 The text appears inconsistent to me : " Short headers contain only an optional destination connection ID""source and destination connection ID : short and long headers carry a destination connection ID " , i.e. , is it optional or not ? Also some inconsistency about the spin bit , is it only in v1 or is it an invariant ?
Paragraph (version A):
source and destination connection ID: short and long headers carry
a destination connection ID, a variable-length field that can be
used to identify the connection associated with a QUIC packet, for
load-balancing and NAT rebinding purposes; see sec-loadbalancing
and rebinding.  Long packet headers additionally carry a source
connection ID.  The source connection ID corresponds to the
destination connection ID the source would like to have on packets
sent to it, and is only present on long headers.  On long header
packets, the length of the connection IDs is also present; on
short header packets, the length of the destination connection ID
is implicit and as such need to be known from the long header
packets.
Paragraph (version B):
source and destination connection ID: short and long headers carry
a destination connection ID, a variable-length field which, if not
zero-length, can be used to identify the connection associated
with a QUIC packet, for load-balancing and NAT rebinding purposes;
see sec-loadbalancing and rebinding.  Long packet headers
additionally carry a source connection ID.  The source connection
ID corresponds to the destination connection ID the source would
like to have on packets sent to it, and is only present on long
headers.  On long header packets, the length of the connection IDs
is also present; on short header packets, the length of the
destination connection ID is implicit and as such need to be known
from the long header packets.
Draft: draft-ietf-quic-applicability

Commentary: Section 8.1 talks about " Services might block source ports " and then lists a bunch . But contacting a service should really happen from an ephemeral source port , which would be as per suggestion the range – . None of the examples in this section come from these ports , so it feels like if one picks proper ephemeral ports , there is no relevant blocking issue at all that this section talks about . Perhaps that is the advise this section should give ?
Paragraph (version A):
As a result, client implementations are encouraged to avoid using
source ports associated with protocols known to be vulnerable to
reflection attacks.  Note that the list above is not exhaustive;
other source ports might be considered reflection vectors as well.
Paragraph (version B):
As a result, client implementations are encouraged to avoid using
source ports associated with protocols known to be vulnerable to
reflection attacks.  Note that following the general guidance for
client implementations given in RFC6335, to use ephemeral ports in
the range 49152-65535, has the effect of avoiding these ports.  Note
that other source ports might be reflection vectors as well.
Draft: draft-ietf-quic-manageability

Commentary: From review by 
 it ’s worth noting that compatible version negotiation can cause the version to change mid - handshake . The true signal is a server - chosen version field echoed in a client packet . 
 Should this reference the compatible version negotiation piece of QUIC - VN ?
Paragraph (version A):
An in-network observer assuming that a set of packets belongs to a
QUIC flow might infer the version number in use by observing the
handshake: for QUIC version 1, if the version number in the Initial
packet from a client is the same as the version number in the Initial
packet of the server response, that version has been accepted by both
endpoints to be used for the rest of the connection.
Paragraph (version B):
An in-network observer assuming that a set of packets belongs to a
QUIC flow might infer the version number in use by observing the
handshake.  If the version number in an Initial packet of the server
response is subsequently seen in a packet from the client, that
version has been accepted by both endpoints to be used for the rest
of the connection (see Section 2 of I-D.ietf-quic-version-
negotiation).