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

Commentary: This implies that the version of QUIC being used in a given flow can be determined simply by linking that flows to one with a handshake . That assumes that all the work we did to make flows difficult to link was for naught . Maybe " can " should be a " might " or something along those lines . I do n't really like the implication that the attempt be made to link flows like this either . 
 In addition to this , the following text from Section 3.4 is not precise enough to be correct : The assumption that the same flow persists might be good in some cases , but this does not necessarily hold in the case that the endpoint address is used by an endpoint that requires non - zero - length connection IDs . This needs to be more precise if the claim is to hold . 
 Not sure what you mean by your second comment here . Of course if there is no connection ID you can not associate it to anything ... ? What 's missing ? Can you propose something ? 
 On re - reading , it seems to be a little clearer . It seems to be saying that an observer can match a particular connection ID with a flow and then , if the flow changes address at only one end without changing the connection ID , then it was subject to rebinding and can be assumed to be the same flow . However , it needs to specify that the connection ID association needs to be directional . Maybe that is assumed , but it should be stated . And it needs to say that this is unlikely to apply when the connection ID is empty .
Paragraph (version A):
Negotiated version cannot be identified for flows for which a
handshake is not observed, such as in the case of connection
migration; however, these flows can be associated with flows for
which a version has been identified; see sec-flow-association.
Paragraph (version B):
Negotiated version cannot be identified for flows for which a
handshake is not observed, such as in the case of connection
migration; however, it might be possible to associate a flow with a
flow for which a version has been identified; see sec-flow-
association.
Draft: draft-ietf-quic-manageability

Commentary: This is not a declared invariant , but a property of version 1 . As this pertains to version numbers , it might be assumed to be invariant . Maybe by scoping this to v1 explicitly here is the right answer . 
 lgtm
Paragraph (version A):
An in-network observer assuming that a set of packets belongs to a
QUIC flow can infer the version number in use by observing the
handshake: an Initial packet with a given version from a client to
which a server responds with an Initial packet with the same version
implies acceptance of that version.
Paragraph (version B):
An in-network observer assuming that a set of packets belongs to a
QUIC flow can 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 Initial
packet of the server response, that version has been accepted by both
endpoints to be used for the rest of the connection.
Draft: draft-ietf-quic-manageability

Commentary: This mixes two things : damage to packets that cause integrity protection to fail , and modification of Initial packets . How about :
Paragraph (version A):
As soon as the cryptographic context is established, all information
in the QUIC header, including exposed information, is integrity
protected.  Further, information that was sent and exposed in
handshake packets sent before the cryptographic context was
established are validated later during the cryptographic handshake.
Therefore, devices on path cannot alter any information or bits in
QUIC packet headers, except specific parts of Initial packets, since
alteration of header information will lead to a failed integrity
check at the receiver, and can even lead to connection termination.
Paragraph (version B):
As soon as the cryptographic context is established, all information
in the QUIC header, including exposed information, is integrity
protected.  Further, information that was sent and exposed in
handshake packets sent before the cryptographic context was
established are validated later during the cryptographic handshake.
Therefore, devices on path cannot alter any information or bits in
QUIC packets.  Such alterations would cause the integrity check to
fail, which results in the receiver discarding the packet.  Some
parts of Initial packets could be altered by removing and re-applying
the authenticated encryption without immediate discard at the
receiver.  However, the cryptographic handshake validates most fields
and any modifications in those fields will result in connection
establishment failing later on.
Draft: draft-ietf-quic-manageability

Commentary: However there are cases where the congestion window can increase when 0 - RTT continues to be sent . Some involve packet loss and so probably wo n't result in a net increase in the window , though the total number of packets might still exceed the initial window size . Others , like TLS HelloRetryRequest or large certificates , involve additional round trips in the handshake . The total amount of 0 - RTT is also limited by remembered flow control values , though this is indirect as this counts stream data only and packets might be further padded . 
 The original text sounds correct - cwnd does n't limit the total number of packets sent when some of those packets are declared lost - although we might want to clarify how the sender can still " retransmit " new packets in later RTTs . 
 I read this as saying that if your initial congestion window is 10 packets , then you ca n't send more than 10 packets of 0 - RTT . That is not the case , even if it might commonly be that way . A client can send 0 - RTT over multiple RTTs if you consider HelloRetryRequest and large handshake flights . In the extreme , there is no real limit to the amount of 0 - RTT packets that can be exchanged . 
 qualification worksYou ca n't ACK 0 - RTT packets in 0 - RTT , so realistically it 's probably 10 packets worth of 0 - RTT data at most , but one could construct some edge cases so this is likely better .
Paragraph (version A):
In a 0-RTT QUIC Client Hello datagram, the PADDING frame is only
present if necessary to increase the size of the datagram with 0RTT
data to at least 1200 bytes.  Additional datagrams containing only
0-RTT protected long header packets may be sent from the client to
the server after the Client Hello datagram, containing the rest of
the 0-RTT data.  The amount of 0-RTT protected data is limited by the
initial congestion window, typically around 10 packets (see
Section 7.2 of QUIC-RECOVERY).
Paragraph (version B):
In a 0-RTT QUIC Client Hello datagram, the PADDING frame is only
present if necessary to increase the size of the datagram with 0RTT
data to at least 1200 bytes.  Additional datagrams containing only
0-RTT protected long header packets may be sent from the client to
the server after the Client Hello datagram, containing the rest of
the 0-RTT data.  The amount of 0-RTT protected data that can be sent
in the first round is limited by the initial congestion window,
typically around 10 packets (see Section 7.2 of QUIC-RECOVERY).
Draft: draft-ietf-quic-manageability

Commentary: The first is not true really . There are 16 million versions that start with 0xff and we only published 34 drafts and implemented far fewer than that . The second is no longer true as we removed the reservation from the registry . Maybe just strike these sentences . 
 Time of publication statements are not generally useful in this context .
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 version and Section 17.2.1 of QUIC-TRANSPORT),
the version number field has a special value (0x00000000) that
identifies the packet as a Version Negotiation packet.  Many QUIC
versions that start with 0xff implement IETF drafts.  QUIC
versions that start with 0x0000 are reserved for IETF consensus
documents.  For example, QUIC version 1 uses version 0x00000001.
Operators should expect to observe packets with other version
numbers as a result of various internet experiments and future
standards.
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 version and Section 17.2.1 of QUIC-TRANSPORT),
the version number field has a special value (0x00000000) that
identifies the packet as a Version Negotiation packet.  Upon time
of publishing of this document, QUIC versions that start with 0xff
implement IETF drafts.  QUIC version 1 uses version 0x00000001.
Operators should expect to observe packets with other version
numbers as a result of various Internet experiments and future
standards.
Draft: draft-ietf-quic-applicability

Commentary: It still says ALPN , though . ALPN does n't have anything to do with using different ports ; it has to do with using different protocols on the same port . 
 Yes ,  already pointed this out . Fixed now . Do we need to say still more about ALPN ? 
 I think that this refers to    ( RFC 7838 ) , which is mentioned in . You might also mention the not - yet - done SVCB record , but that might not be a good idea if you like the idea of publishing this . 
 SVCB record would just be an informational reference , no ? So that should n't hold up publication . In this case I 'd be okay to provide a pointer . 
 What do you meant by " ALPN does n't enable use of other ports " ? 
 The text here says " specifies the use of ALPN for service discovery which allows the server to use and announce a different port number " . ALPN is not a service discovery mechanism , it 's a protocol selection mechanism . ALPN is completely orthogonal to choice of ports . The purpose of ALPN is for client and server to agree on the protocol that is used . Your change to references in wo n't fix this issue . It does correctly cite the Alt - Svc sections of HTTP/3 , but the surrounding text still says ALPN .
Paragraph (version A):
Applications could define an alternate endpoint discovery mechanism
to allow the usage of ports other than the default.  For example,
HTTP/3 (QUIC-HTTP Sections 3.2 and 3.3) specifies the use of ALPN
RFC7301 for service discovery which allows the server to use and
announce a different port number.  Note that HTTP/3's ALPN token
("h3") identifies not only the version of the application protocol,
but also the binding to QUIC as well as the version of QUIC itself;
this approach allows unambiguous agreement between the endpoints on
the protocol stack in use.
Paragraph (version B):
Applications could define an alternate endpoint discovery mechanism
to allow the usage of ports other than the default.  For example,
HTTP/3 (QUIC-HTTP Sections 3.1.1 and 3.1.2) specifies the use of HTTP
Alternative Services for an HTTP origin to advertise the availability
of an equivalent HTTP/3 endpoint on a certain UDP port by using the
"h3" ALPN token RFC7301.  Note that HTTP/3's ALPN token ("h3")
identifies not only the version of the application protocol, but also
the binding to QUIC as well as the version of QUIC itself; this
approach allows unambiguous agreement between the endpoints on the
protocol stack in use.
Draft: draft-ietf-quic-manageability

Commentary: addresses 
 Should this ID have some mention of ICMP , because support for ICMP with UDP is a known issue for many stacks , and QUIC seems to have thought this through and we can pass that on . So , I think some mention of the use of ICMP would be helpful - at least to refer to the appropriate sections in the QUIC transport spect 
 I would think this would be handled by the QUIC implementation transparently and therefore it 's not in the applicability statement that is directed at application designers who rather use an existing QUIC library . Or what exactly is the advise you would like to see here ? 
 Actually , I was suggesting somewhere just to say something about  because some endpoints did n't traditionally pass ICMP to UDP - this could be manageability rather than applicability ? : " QUIC stacks can be designed to receive and safely utilise received ICMP messages when these are provided by the endpoint ( e.g to assist PMTUD ) , but do not rely upon them to function . " 
 Okay , let me think we anything like this belongs . I believe , as you say , manageability might make more sense . 
 We merged the PR as it seems uncontroversial but I leave the issue open for now , so we do n't forget to mention this new section in the meeting .
Paragraph (version B):
Datagram Packetization Layer PMTU Discovery (PLPMTUD) can be used by
QUIC to probe for the supported PMTU.  PLPMTUD optionally uses ICMP
messages (e.g., IPv6 Packet Too Big messages).  Given known attacks
with the use of ICMP messages, the use of PLPMTUD in QUIC has been
designed to safely use but not rely on receiving ICMP feedback (see
Section 14.2.1. of QUIC-TRANSPORT).
Paragraph (version B):
Networks are recommended to forward these ICMP messages and retain as
much of the original packet as possible without exceeding the minimum
MTU for the IP version when generating ICMP messages as recommended
in RFC1812 and RFC4443.
Draft: draft-ietf-quic-applicability

Commentary: “ Padding is used by QUIC to ensure ” - please add a sentence that DPLPMTUD is another reason why you might expect QUIC Padding of specific packets after connection establishment , and refer to section in QUIC transport - or people may have a surprise when they suddenly see big probe packets in their logs:- ) 
 I thought that this is what the sentence is about ? The whole sentence says : " Padding is used by QUIC to ensure that the path is capable of transferring datagrams of at least a certain size , ... " We can add a reference to the right section in the transport draft but sure we need another sentence ? However , your point about being surprised to see big packets probably rather belongs into manageability ... ? 
 Ah sorry : I was trying to highlight that there are two places where I think QUIC might be expected to use padding ... in the initial connection ... to verify the path supports the minimum size , and later whenever  is invoked , to probe to check for a larger size . Two section refs would likely be useful . ... Yes , it could be mentioned in manageability - since often QUIC packets might be rather uniform in size with occasional DLPMTUD probes ? 
 I created a PR to add references to the respective sections in the QUIC transport draft . Explaining in detail what padding is used for internally in QUIC was n't really the point here . However , it 's probably correct that the sentence should not just omit one usage ( PLDMTUD ) and reference probably do n't hurt . Do we need still something for manageability ? Or is that , at least partially , already addressed by ? 
 Looks good
Paragraph (version A):
Similarly, an application has usually no control about the length of
a QUIC packet on the wire.  QUIC provides the ability to add a
PADDING frame to arbitrarily increase the size of packets.
Paragraph (version A):
Padding is used by QUIC to ensure that the path is capable of
transferring datagrams of at least a certain size, both during the
handshake and for connection migration.  Padding can also be used by
an application to reduce leakage of information about the data that
is sent.  A QUIC implementation can expose an interface that allows
an application layer to specify how to apply padding.
Paragraph (version B):
Similarly, an application has usually no control about the length of
a QUIC packet on the wire.  QUIC provides the ability to add a
PADDING frame to arbitrarily increase the size of packets.  Padding
is used by QUIC to ensure that the path is capable of transferring
datagrams of at least a certain size, during the handshake (see
Sections 8.1 and 14.1 of QUIC) and for path validation after
connection migration (see Section 8.2 of QUIC) as well as for
Datagram Packetization Layer PMTU Discovery (DPLMTUD) (see
Section 14.3 of QUIC).
Paragraph (version B):
Padding can also be used by an application to reduce leakage of
information about the data that is sent.  A QUIC implementation can
expose an interface that allows an application layer to specify how
to apply padding.
Draft: draft-ietf-quic-manageability

Commentary: The point of is a little odd , because it seems to imply that ALL operations require access to the information that is integrity- or confidentiality - protected . That 's clearly not the case , I think , as it is merely pointing out that if you want to modify data , then you have to be an endpoint . I think that this might be better phrased as : Note : This drops the last sentence of the original paragraph . If proxying is out of scope , then it does n't help to talk about it so much . The point about cooperation should do . 
 Created a PR based on your proposed text but some of the information about proxies to make it more clear what kind of proxies we are talking about .
Paragraph (version A):
Since QUIC's wire image WIRE-IMAGE is integrity protected and not
modifiable on path, in-network operations are not possible without
terminating the QUIC connection, for instance using a back-to-back
proxy.  Proxy operations are not in scope for this document.  A proxy
can either explicit identify itself as providing a proxy service, or
may share the TLS credentials to authenticate as the server and (in
some cases) client acting as a front-facing instance for the endpoint
itself.
Paragraph (version B):
Since QUIC's wire image WIRE-IMAGE is integrity-protected, in-network
operations that depend on modification of data are not possible
without the cooperation of an endpoint.  Network operation practices
that alter data are only possible if performed as a 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.
Draft: draft-ietf-quic-applicability

Commentary: This is text from  . I created a new section in the applicability document but not fully sure yet where this belongs . 
 Okay . I updated the PR . Can people check again ? But I think this is ready to merge ( after the meeting ) . 
 One more question : usually the ack rate is rather controller by the quic stack than the application . Should we add another sentence saying that an interface for indicating the maximum ack rate would be desirable .... ? 
 I think the text we have might be minimal , but is ok . ( A good app needs to be aware of this or choose to use a good stack . Since this is a transport feature that is n't always required by the spec , then the app designer needs either the stack to work appropriately and/or to allow some control . ) 
 This was brought up by in issue : " I ’d also note that the volume of ACK traffic really can be a problem that QUIC needs to address , because QUIC over radio ( of various types ) can be significantly more expensive or lower performant than TCP , precisely because the control / ACK traffic is much more and there is no opportunity for network mitigation - hence it behoves QUIC implementors to use appropriate methods . " I created this new , separate issue for this point and will close the old issue now . Note that there is already proposed text , copied into PR 
 PR was merged
Paragraph (version B):
The cost of sending acknowledgments - in processing cost or link
utilization - could be a significant proportion of available
resources if these resources are constrained.  Reducing the rate at
which acknowledgments are generated can preserve these resources and
improve overall performance, for both network processing as well as
application-relevant metrics.
Draft: draft-ietf-quic-manageability

Commentary: This did n't need to say encrypted twice . And it did n't really require changes to HTTP , just an adaptation . ( I 'm less happy about that part ; it could probably use a tweak or two . )
Paragraph (version A):
QUIC QUIC-TRANSPORT is a new transport protocol encapsulated in UDP
and encrypted by default.  QUIC integrates TLS QUIC-TLS to encrypt
all payload data and most control information.  The design focused on
support of semantics for HTTP, which required changes to HTTP known
as HTTP/3 QUIC-HTTP.
Paragraph (version B):
QUIC QUIC-TRANSPORT is a new transport protocol that is encapsulated
in UDP.  QUIC integrates TLS QUIC-TLS to encrypt all payload data and
most control information.  QUIC version 1 was designed primarily as a
transport for HTTP, with the resulting protocol being known as HTTP/3
QUIC-HTTP.
Draft: draft-ietf-quic-applicability

Commentary: Beware those who want to do something else . 
 Is n't this already covered by the next section on " Flow Control Deadlocks " ? If not , what 's missing ? And can we just add a sentence or two there ? 
 Though the specification does not insist upon it , most implementations will assume that stream data is reliably delivered in order . This means that senders will send until every byte is delivered or they decide to reset the stream ( possibly based on STOP_SENDING ) . And it means that receivers wo n't make data available until a contiguous span of bytes starting at the last unread offset are available . Implementations might act differently , but variations from this behaviour would need to be agreed by both endpoints . 
 can you propose text ?
Paragraph (version B):
QUIC streams enable ordered and reliable delivery.  Though it is
possible for an implementation to provide options that use streams
for partial reliability or out-of-order delivery, most
implementations will assume that data is reliably delivered in order.
Paragraph (version B):
Under this assumption, an endpoint that receives stream data might
not make forward progress until data that is contiguous with the
start of a stream is available.  In particular, a receiver might
withhold flow control credit until contiguous data is delivered to
the application; see Section 2.2 of QUIC.  To support this receive
logic, an endpoint will send stream data until it is acknowledged,
ensuring that data at the start of the stream is sent and
acknowledged first.
Paragraph (version B):
An endpoint that uses a different sending behavior and does not
negotiate that change with its peer might encounter performance
issues or deadlocks.