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

Commentary: for signaling priority , such as those defined for HTTP/2 First , if we retain this comment , it should probably have a reference to RFC 7540 and the appropriate section . However , as noted in reply to a previous issue , this document is about QUIC , not TCP ; the use of HTTP/2 as an exemplar seems out - of - place , particularly since we 're actively deprecating that priority scheme . Perhaps a reference to draft - ietf - httpbis - priority would be more appropriate ? 
 I agree that a reference to draft - ietf - httpbis - priority would be more appropriate . 
 Yes , sounds good . I 'll create a PR if no - one else does it before me .
Paragraph (version A):
Stream prioritization is not exposed to either the network or the
receiver.  Prioritization is managed by the sender, and the QUIC
transport should provide an interface for applications to prioritize
streams QUIC.  Applications can implement their own prioritization
scheme on top of QUIC: an application protocol that runs on top of
QUIC can define explicit messages for signaling priority, such as
those defined for HTTP/2; it can define rules that allow an endpoint
to determine priority based on context; or it can provide a higher
level interface and leave the determination to the application on
top.
Paragraph (version B):
Stream prioritization is not exposed to either the network or the
receiver.  Prioritization is managed by the sender, and the QUIC
transport should provide an interface for applications to prioritize
streams QUIC.  Applications can implement their own prioritization
scheme on top of QUIC: an application protocol that runs on top of
QUIC can define explicit messages for signaling priority, such as
those defined in I-D.draft-ietf-httpbis-priority for HTTP; it can
define rules that allow an endpoint to determine priority based on
context; or it can provide a higher level interface and leave the
determination to the application on top.
Draft: draft-ietf-quic-applicability

Commentary: addresses 
 The text says : “ or prime the congestion controller in preparation for switching to the new path . ” what does prime mean ? and which section explains this function in the QUIC spec ? 
 The idea here is that you can already e.g. estimate RTT or even open the congestion window before you switch . There was already some discussion previously ( seePR ) if we want to have this in the document or say more or less . Maybe a question to the rest of the wg ( in the next meeting ) ... ? 
 Unsure about this in this ID : Is n't that suggesting a transport extension / mechanism update ... rather than the applicable use ? 
 I do n't think it needs an extension . It can simply be done by the client . It 's definitely not appropriate to specify a concrete algorithm in this document but it 's just listed as one of the things that padding can be used during mitigation . 
 I 'm really unsure about why text about priming is here and where the advice is located . I do n't dispute that it can be done , or even that if done appropriately it can help , however it could also be done in a way that might also hinder . If PR 122 removes this word , then this topic can be discussed elsewhere in RFCs . 
 PR was already merged a long time ago . I was just point at it to say that there has been previous discussion . As the label indicates , we plan to bring the for discussion to the meeting . 
 CC priming seems like an issue entirely internal to the QUIC implementation . Why should applications know or care about it ? I suggest we simply delete this . 
 I like suggestion . 
 is my proposal . It does n't talk about priming / pre - heating anymore but it says what 's possible and why this could be interesting for an application . 
 PR was merged . 
 Phrasing suggestion .
Paragraph (version A):
QUIC probing packets, which cannot carry application data, can be
sent on multiple paths at once.  Probing packets can be used to
perform address validation, measure path characteristics as input for
the switching decision, or prime the congestion controller in
preparation for switching to the new path.
Paragraph (version B):
QUIC probing packets, which can be sent on multiple paths at once,
are used to perform address validation as well as measure path
characteristics as input for the switching decision.  Probing packets
cannot carry application data but may contain padding frames.
Endpoints can use information about their receipt as input to
congestion control for that path.  Applications could use information
learned from probing to inform a decisions to switch paths.
Draft: draft-ietf-quic-applicability

Commentary: Reset is a directional stream semantic , not a connection one . 
 Actually the idea here was not necessarily talk about the semantics of how a connection is closed . So maybe using something else like " abort " would avoid any confusion here ... ? 
 Oh , I see . Yeah maybe abort is better . For me reading this " reset " made me think of TCP connection and or QUIC stream semantics , which is probably not the intention .
Paragraph (version A):
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.
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
terminate the QUIC connection.
Draft: draft-ietf-quic-applicability

Commentary: I do n't think this sentence was accurate . TFO is n't analogous to 0 - RTT session resumption , but it 's needed to achieve the same application effect . 
 maybe analogous was n't the right term but I 'm also not sure about the word " true " here ... 
 " true " meaning " actual " , i.e. you can resume a session without a round trip . We could specify that further but it probably has to be more wordy .
Paragraph (version A):
These applications must operate, perhaps with impaired functionality,
in the absence of features provided by QUIC not present in the
fallback protocol.  For fallback to TLS over TCP, the most obvious
difference is that TCP does not provide stream multiplexing and
therefore stream multiplexing would need to be implemented in the
application layer if needed.  Further, TCP implementations and
network paths often do not support the Fast Open option, which is
analogous to 0-RTT session resumption.  Note that there is some
evidence of middleboxes blocking SYN data even if TFO was
successfully negotiated (see PaaschNanog).  And even if Fast Open
successfully operates end-to-end, it is limited to a single packet of
payload, unlike QUIC 0-RTT.
Paragraph (version B):
These applications must operate, perhaps with impaired functionality,
in the absence of features provided by QUIC not present in the
fallback protocol.  For fallback to TLS over TCP, the most obvious
difference is that TCP does not provide stream multiplexing and
therefore stream multiplexing would need to be implemented in the
application layer if needed.  Further, TCP implementations and
network paths often do not support the Fast Open option RFC7413,
which enables sending of payload data together with the first control
packet of a new connection as also provided by 0-RTT session
resumption in QUIC.  Note that there is some evidence of middleboxes
blocking SYN data even if TFO was successfully negotiated (see
PaaschNanog).  And even if Fast Open successfully operates end-to-
end, it is limited to a single packet of TLS handshake and
application data, unlike QUIC 0-RTT.
Draft: draft-ietf-quic-manageability

Commentary: This is branched of . said : " 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 . " 
 I created PR . Does that address this point sufficiently ?
Paragraph (version A):
The QUIC connection ID (see rebinding) is designed to allow an on-
path device such as a load-balancer to associate two flows as
identified by five-tuple when the address and port of one of the
endpoints changes; e.g. due to NAT rebinding or server IP address
migration.  An observer keeping flow state can associate a connection
ID with a given flow, and can associate a known flow with a new flow
when when observing a packet sharing a connection ID and one endpoint
address (IP address and port) with the known flow.
Paragraph (version B):
The QUIC connection ID (see rebinding) is designed to allow an on-
path device such as a load-balancer to associate two flows as
identified by five-tuple when the address and port of one of the
endpoints changes; e.g. due to NAT rebinding or server IP address
migration.  An observer keeping flow state can associate a connection
ID, if present, with a given flow, and can associate a known flow
with a new flow when when observing a packet sharing the same
connection ID in the same direction between client and server and
sharing one endpoint address (IP address and port) with the known
flow.
Draft: draft-ietf-quic-manageability

Commentary: proposed by 
 Plan is to update the PR to point to the IANA registry instead . 
 Added a ref to the iana registration sec in the transport draft . Should be ready to go now !
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.  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.
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.  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.  All
deployed versions are maintained in an IANA registry (see
Section 22.2 of QUIC-TRANSPORT).
Draft: draft-ietf-quic-applicability

Commentary: The proposed wording makes sentence stronger , more list a SHOULD requirement . Therefore we wanted to check with others before we merge . 
 Seems simpler and clearer . I do n't see this as normative .
Paragraph (version A):
If a QUIC receiver has opened the maximum allowed concurrent streams,
and the sender indicates that more streams are needed, it does not
automatically lead to an increase of the maximum number of streams by
the receiver.  Therefore it can be valuable to expose the maximum
number of allowed, currently open, and currently used streams to the
application to make the mapping of data to streams dependent on this
information.
Paragraph (version B):
If a QUIC receiver has opened the maximum allowed concurrent streams,
and the sender indicates that more streams are needed, it does not
automatically lead to an increase of the maximum number of streams by
the receiver.  Therefore, an application can use the maximum number
of allowed, currently open, and currently used streams when
determining how to map data to streams.
Draft: draft-ietf-quic-applicability

Commentary: Thanks to  for noticing this . 
 This is true , but there is nothing inherent to the design that prevents RESETSTREAM ( and STOPSENDING ) from using a different code space from CONNECTION_CLOSE . Though we have the policy in HTTP/3 that any stream error can become a connection error , the same is n't necessarily true of other protocols . Maybe we cab just avoid mentioning this possibility .. , 
 I do n't think I have a strong opinion on removing or keeping this sentence . Would it be any better if we say : " Application error codes are recommended to be defined from a single space that applies to all three frame types . " ? Or is there any other guidance we can or want to give to application designer about the use of error codes ?
Paragraph (version A):
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 also include an
error code, but no reason string.  Application error codes are
expected to be defined from a single space that applies to all three
frame types.
Paragraph (version B):
The CONNECTION_CLOSE frame provides an optional reason field, that
can be used to append human-readable information to an error code.
RESET_STREAM and STOP_SENDING frames also include an error code, but
no reason string.
Draft: draft-ietf-quic-applicability

Commentary: I updated the text of the second paragraph . If people could have another look that would be welcome . But I believe we are ready to merge ( after the meeting ) . 
 So far we do n't mention any extension in the ops drafts , however , datagrams actually require a different interface and as such are important for an application to know about , therefore , I think it would be good to add a separate section in the applicability statement and mention it as a separate service over QUIC . 
 Agreed , mentioning datagram seems very useful .
Paragraph (version B):
I-D.draft-ietf-quic-datagram specifies a QUIC extension to enable
sending and receiving unreliable datagrams over QUIC.  Unlike
operating directly over UDP, applications that use the QUIC datagram
service do not need to implement their own congestion control, per
RFC8085, as QUIC datagrams are congestion controlled.
Paragraph (version B):
QUIC datagrams are not flow-controlled, and as such data chunks may
be dropped if the receiver is overloaded.  While the reliable
transmission service of QUIC provides a stream-based interface to
send and receive data in order over multiple QUIC streams, the
datagram service has a unordered message-based interface.  If needed,
an application layer framing can be used on top to allow separate
flows of unreliable datagrams to be multiplexed on one QUIC
connection.
Draft: draft-ietf-quic-manageability

Commentary: where it belongs . This is not a network function but a piece of information that can be identified ( or not )
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 not
recommended to use as a way to construe internals of QUIC's operation
as those mechanisms can change, e.g., due to the use of extensions.
Paragraph (version A):
Some deployed in-network functions distinguish pure-acknowledgment
(ACK) packets from packets carrying upper-layer data in order to
attempt to enhance performance, for example by queueing ACKs
differently or manipulating ACK signaling.  Distinguishing pure ACK
packets is easy 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 very likely to fail, and are not
recommended to use as a way to construe internals of QUIC's operation
as those mechanisms can change, e.g., due to the use of extensions.
Draft: draft-ietf-quic-manageability

Commentary: This seeks to address issue : " MTU or Min QUIC Packet Size ? " 
 Sect 2.4 : says : “ the network path meets minimum Maximum Transmission Unit ( MTU ) requirements . “ There is text in the QUIC transport spec that the WG perfected a little in the final stages , and I think this use of MTU in sect 2.3 is suspect . As I see it , the requirements in QUIC are for a minimum supported QUIC packet size ... not the MTU required to send this on an interface . ... This nuanced might be a really important detail for operations staff - where there is frequently a need to consider encapsulations and tunnels on interfaces of devices . ... A cross reference to the QUIC  may also help here . 
 can you propose text ? 
 Thought to be addressed in PR 
 PR merged 
 I think there are only 3 ways to fill up the space , so maybe enumerate them ? I also wonder if we need to caution against stripping unused UDP payload or splitting up packets within a UDP datagram ?
Paragraph (version A):
Datagrams that contain a QUIC Initial Packet (Client Hello, Server
Hello, and some Initial Completion) must be at least 1200 octets
long.  This protects against amplification attacks and verifies that
the network path meets minimum Maximum Transmission Unit (MTU)
requirements.  This is usually accomplished with either the addition
of PADDING frames to the Initial packet, or coalescing of the Initial
Packet with packets from other encryption contexts.
Paragraph (version B):
Datagrams that contain a QUIC Initial Packet (Client Hello, Server
Hello, and some Initial Completion) contain at least 1200 octets of
UDP payload.  This protects against amplification attacks and
verifies that the network path meets the requirements for the minimum
QUIC IP packet size, see Section 14 of QUIC-TRANSPORT.  This is
accomplished by either adding PADDING frames within the Initial
packet, coalescing other packets with the Initial packet, or leaving
unused payload in the UDP packet after the Initial packet.  A network
path needs to be able to forward at least this size of packet for
QUIC to be used.
Draft: draft-ietf-quic-applicability

Commentary: This cuts a section heading and coalesces a few paragraphs . It adds a point of comparison with TLS 1.3 . 
 Section 3 talks about the challenges of 0 - RTT , but seems to ignore that very similar challenges exist when TLS 1.3 Early Data is used over TCP . I think I 'd reword this to talk about the similarity , and that while QUIC gives Early Data more visibility , the same cautions and mitigations still apply . ( I 'd also probably find a more technical title than " Here There Be Dragons , " but that 's purely stylistic . ) 
 I agree that challenges are similar to TLS1.3 over TCP . However , given this document is scoped to the use of QUIC , I 'm not sure what mentioning TCP in this section gets you . I find the section actually quite clear without mentioning anything about TCP . Or did I miss the point you are making ? 
 Otherwise PRs are always welcome ! :-)
Paragraph (version A):
QUIC provides for 0-RTT connection establishment.  This presents
opportunities and challenges for applications using QUIC.
Paragraph (version B):
QUIC provides for 0-RTT connection establishment.  Though the same
facility exists in TLS 1.3 with TCP, 0-RTT presents opportunities and
challenges for applications using QUIC.
Paragraph (version A):
Applications must be slightly rethought in order to make best use of
0-RTT resumption.  Using 0-RTT requires an understanding of the
implication of sending application data that might be replayed by an
attacker.
Paragraph (version A):
Application protocols that use 0-RTT require a profile that describes
the types of information that can be safely sent.  For HTTP, this
profile is described in HTTP-REPLAY.
Paragraph (version B):
An application needs to deliberately choose to use 0-RTT, as 0-RTT
carries a risk of replay attack.  Application protocols that use
0-RTT require a profile that describes the types of information that
can be safely sent.  For HTTP, this profile is described in HTTP-
REPLAY.
Draft: draft-ietf-quic-manageability

Commentary: addresses 
 I do n’t have comments on the validity of the discussion text in section 12 and the described procedures , but I do wonder why this is information for an application designer , rather than for managing operations . Is this the correct ID for this information ? and if its is , could it be explained a little more to what the app designer needs too know . This section seems rather devoid of useful references . please add some . 
 The split here was see as applicability is addressed at people who want to use QUIC ( application designer but also people deploying QUIC at servers ) and manageability for people who have to handle QUIC traffic ( mainly network operator incl probably data centre operators ) . I know the split between the two last categories ( deploying servers and managing a dc networks ) is not always that clear . It 's probably this section and the one about load balancing in manageability . I 'm open to discuss where which section belongs . Do we need to bring this to the meeting ? what kind of reference are you thinking of ? 
 On what to do in Manageability : I 'd suggest we write some text that says : " QUIC provides a version negotiation process , that allows new versions to be introduced . The deployment of new versions is discussed in section 12 of [ ID . ietf - quic - applicability ] . " Maybe even just as the first para of Manageability : Sect : 2.8 . I meant add reference to section 6 in QUIC Transport - to both these documents 
 There is already section 2.8 on " Version Negotiation and Greasing " and section 3.1.1 . on " Identifying Negotiated Version " in the manageability draft . Ideally the idea is to not have cross reference between manageability and applicability . I a reference to section 6 of the quic - transport draft in manageability ( see PR ) . Not sure we need that reference also in the applicability draft because that section actually does n't require any knowledge of the internals on how version negotiation works ...
Paragraph (version A):
Version Negotiation packets are not intrinsically protected, but QUIC
versions can use later encrypted messages to verify that they were
authentic.  Therefore any modification of this list will be detected
and may cause the endpoints to terminate the connection attempt.
Paragraph (version B):
Version Negotiation packets are used by the server to indicate that a
requested version from the client is not supported (see section 6 of
QUIC-TRANSPORT.  Version Negotiation packets are not intrinsically
protected, but QUIC versions can use later encrypted messages to
verify that they were authentic.  Therefore any modification of this
list will be detected and may cause the endpoints to terminate the
connection attempt.