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

Commentary: This is a rephrase of suggestion . 
 The pseudo code says the following : With the change introduced in , the spec says the following for the time from which the timer should be armed if there are no outstanding packets in the Handshake packet number space : 
 This code is called from where Initial keys are discarded , so I believe it still matches the text , which only discusses the " ( has handshake keys ) " case . 
 That being said , it feels odd we mention one case of using now ( ) and not the other , so I updated PR 
 This paragraph does not really provide any context that would allow you to infer what the " current time " is . Based on the pseudocode , this time is when SetLossDetectionTimer ( ) is invoked , but that covers a range of cases : When a packet is received and the endpoint is at its anti - amplification limit When an in - flight packet is sent When an ACK is received When the loss detection timer pops When a packet number space is discarded Of these , the " current time " clause only really applies to the last two , and the last one is the real baseline ( because the other only matters if the first was set ) . I think that this can be more precisely worded to say " In this case , the PTO is set from the time at which the Initial packet number space is discarded . " That 's far more direct , but I would like others to check my work to ensure that it catches all the cases properly . 
 Setting the time from when the Initial PN space is discarded is a good clarification , and conveniently it lines up with the pseudocode . The pseudocode for OnPacketNumberSpaceDiscarded(pn_space ) calls SetLossDetectionTimer ( ) . 
 There are actually two cases now ( ) is used , so we ca n't solely rely on handshake keys being discarded . See for a larger change . 
 This is good , but I would n't talk about " current time " at all .
Paragraph (version A):
A client could have received and acknowledged a Handshake packet,
causing it to discard state for the Initial packet number space, but
not sent any ack-eliciting Handshake packets.  In this case, the PTO
is set from the current time.
Paragraph (version B):
A client could have received and acknowledged a Handshake packet,
causing it to discard state for the Initial packet number space, but
not sent any ack-eliciting Handshake packets.  In this case, the PTO
timer is armed from the time that the Initial packet number space is
discarded.
Draft: draft-ietf-quic-recovery

Commentary: PTO packets always have to be ACK - eliciting , not just during the handshake , per existing text : " When a PTO timer expires , a sender MUST send at least one ack - eliciting packet in the packet number space as a probe , ... " Also removed an " unless " clause , because if there 's nothing to send , you do n't arm the PTO timer .
Paragraph (version A):
Prior to handshake completion, when few to none RTT samples have been
generated, it is possible that the probe timer expiration is due to
an incorrect RTT estimate at the client.  To allow the client to
improve its RTT estimate, the new packet that it sends MUST be ack-
eliciting.
Paragraph (version A):
When a PTO timer expires, a sender MUST send at least one ack-
eliciting packet in the packet number space as a probe, unless there
is no data available to send.  An endpoint MAY send up to two full-
sized datagrams containing ack-eliciting packets, to avoid an
expensive consecutive PTO expiration due to a single lost datagram or
transmit data from multiple packet number spaces.  All probe packets
sent on a PTO MUST be ack-eliciting.
Paragraph (version B):
When a PTO timer expires, a sender MUST send at least one ack-
eliciting packet in the packet number space as a probe.  An endpoint
MAY send up to two full-sized datagrams containing ack-eliciting
packets, to avoid an expensive consecutive PTO expiration due to a
single lost datagram or transmit data from multiple packet number
spaces.  All probe packets sent on a PTO MUST be ack-eliciting.
Draft: draft-ietf-quic-http

Commentary: Replace SETTINGSMAXHEADERLISTSIZE with SETTINGSMAXFIELDSECTIONSIZE in one last place . Add comment to HTTP/2 identifier mapping section about rename .
Paragraph (version A):
An endpoint can use the SETTINGS_MAX_HEADER_LIST_SIZE (settings-
parameters) setting to advise peers of limits that might apply on the
size of field sections.  This setting is only advisory, so endpoints
MAY choose to send field sections that exceed this limit and risk
having the request or response being treated as malformed.  This
setting is specific to a connection, so any request or response could
encounter a hop with a lower, unknown limit.  An intermediary can
attempt to avoid this problem by passing on values presented by
different peers, but they are not obligated to do so.
Paragraph (version B):
An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE (settings-
parameters) setting to advise peers of limits that might apply on the
size of field sections.  This setting is only advisory, so endpoints
MAY choose to send field sections that exceed this limit and risk
having the request or response being treated as malformed.  This
setting is specific to a connection, so any request or response could
encounter a hop with a lower, unknown limit.  An intermediary can
attempt to avoid this problem by passing on values presented by
different peers, but they are not obligated to do so.
Draft: draft-ietf-quic-transport

Commentary: This is a small tweak of  's suggestion . 
 Looks good to me . 
 I promised to raise an issue relating to this text : " It can also improve connection throughput on severely asymmetric links ; see Section 3 of [ RFC3449 ] . " This partly addresss the case , but it does not yet note the implications of the return path traffic on congestion of the return path . I think this is a useful addition , because it helps alert the reader of the tradeoff ... which can be quite important for half - duplex / shared radio , etc where the spectrum consumed sending an ACK can even outweigh the cost of sending a data packet ( because they use different design of PHY ) . I suggest : " It can improve connection throughput using severely asymmetric links and can also reduce the volume of acknowledgment traffic using return path capacity ; see Section 3 of [ RFC3449 ] . "
Paragraph (version A):
On the other hand, reducing the frequency of packets that carry only
acknowledgements reduces packet transmission and processing cost at
both endpoints.  It can also improve connection throughput on
severely asymmetric links; see Section 3 of RFC3449.
Paragraph (version B):
On the other hand, reducing the frequency of packets that carry only
acknowledgements reduces packet transmission and processing cost at
both endpoints.  It can improve connection throughput on severely
asymmetric links and reduce the volume of acknowledgment traffic
using return path capacity; see Section 3 of RFC3449.
Draft: draft-ietf-quic-recovery

Commentary: This should resolve some parts of . 
 If you wish , I will split this PR into small ones . 
 I have dropped the commit of " in flight " . 
 I also changed into . 
 The commit for " towards " has been dropped . 
 Thanks . BTW , that thing is an another odd English quirk . 
 Unfortunately , this PR bundles a bunch of unrelated changes . Some of them I like , some of them I don't . Thanks for the PR , !
Paragraph (version A):
Peers can also use coalesced packets to ensure that each datagram
elicits at least one acknowledgement.  For example, clients can
coalesce an Initial packet containing PING and PADDING frames with a
0-RTT data packet and a server can coalesce an Initial packet
containing a PING frame with one or more packets in its first flight.
Paragraph (version B):
Endpoints can also use coalesced packets to ensure that each datagram
elicits at least one acknowledgement.  For example, a client can
coalesce an Initial packet containing PING and PADDING frames with a
0-RTT data packet and a server can coalesce an Initial packet
containing a PING frame with one or more packets in its first flight.
Draft: draft-ietf-quic-qpack

Commentary: for semantics-09
Paragraph (version A):
A name-value pair sent as part of an HTTP field section.  See
Section 4 of SEMANTICS.
Paragraph (version B):
A name-value pair sent as part of an HTTP field section.  See
Section 5 of SEMANTICS.
Draft: draft-ietf-quic-transport

Commentary: This was going to be a suggestion in a review , but it 's already merged .
Paragraph (version A):
Packets with a supported version, or no version field, are matched to
a connection using the connection ID or - for packets with zero-
length connection IDs - the local address and port.  These packets
are processed using the selected connection, otherwise the server
continues below.
Paragraph (version B):
Packets with a supported version, or no version field, are matched to
a connection using the connection ID or - for packets with zero-
length connection IDs - the local address and port.  These packets
are processed using the selected connection; otherwise, the server
continues below.
Draft: draft-ietf-quic-http

Commentary: client stream should be clearly written as client initiated stream the word which pair of send response is receive request , so its better to be does not abort recieving request here for clearify . 
 First one is good . The second one is intended to align with Section 2.4 of the transport draft , where " abort reading " is a defined operation on a stream ; maybe " does not abort reading the request " ? 
 " does not abort reading the request " SGTM too
Paragraph (version A):
When a stream is closed, this indicates the end of an HTTP message.
Because some messages are large or unbounded, endpoints SHOULD begin
processing partial HTTP messages once enough of the message has been
received to make progress.  If a client stream terminates without
enough of the HTTP message to provide a complete response, the server
SHOULD abort its response with the error code H3_REQUEST_INCOMPLETE.
Paragraph (version B):
When a stream is closed, this indicates the end of an HTTP message.
Because some messages are large or unbounded, endpoints SHOULD begin
processing partial HTTP messages once enough of the message has been
received to make progress.  If a client-initiated stream terminates
without enough of the HTTP message to provide a complete response,
the server SHOULD abort its response with the error code
H3_REQUEST_INCOMPLETE.
Paragraph (version A):
reading, clients SHOULD continue sending the body of the request and
close the stream normally.
Paragraph (version B):
reading the request, clients SHOULD continue sending the body of the
request and close the stream normally.
Draft: draft-ietf-quic-http

Commentary: The introduction is oddly narrow about HTTP/1.1 ( and h2 ) being a TCP mapping , even though HTTP/1.x is commonly used on many different transports and session - layers . In fact , it was specifically designed to not be dependent on TCP so that it could be implemented over every network and every security layer . A simple solution would be to delete that as a description , since it is neither accurate nor useful . It 's fine to say that HTTP/3 is specific to QUIC .
Paragraph (version A):
HTTP semantics SEMANTICS are used for a broad range of services on
the Internet.  These semantics have most commonly been used with two
different TCP mappings, HTTP/1.1 and HTTP/2.  HTTP/3 supports the
same semantics over a new transport protocol, QUIC.
Paragraph (version A):
HTTP/1.1 HTTP11 is a TCP mapping which uses whitespace-delimited text
fields to convey HTTP messages.  While these exchanges are human-
readable, using whitespace for message formatting leads to parsing
complexity and motivates tolerance of variant behavior.  Because
HTTP/1.x does not include a multiplexing layer, multiple TCP
connections are often used to service requests in parallel.  However,
that has a negative impact on congestion control and network
efficiency, since TCP does not share congestion control across
multiple connections.
Paragraph (version B):
HTTP semantics SEMANTICS are used for a broad range of services on
the Internet.  These semantics have most commonly been used with
HTTP/1.1, over a variety of transport and session layers, and with
HTTP/2 over TLS.  HTTP/3 supports the same semantics over a new
transport protocol, QUIC.
Paragraph (version B):
HTTP/1.1 HTTP11 uses whitespace-delimited text fields to convey HTTP
messages.  While these exchanges are human-readable, using whitespace
for message formatting leads to parsing complexity and excessive
tolerance of variant behavior.  Because HTTP/1.x does not include a
multiplexing layer, multiple TCP connections are often used to
service requests in parallel.  However, that has a negative impact on
congestion control and network efficiency, since TCP does not share
congestion control across multiple connections.
Draft: draft-ietf-quic-tls

Commentary: Just in case this was n't blindingly obvious . 
 The TLS spec says : version of TLS . An endpoint MUST terminate the connection if a version of TLS older than 1.3 is negotiated . I would propose that we forbid clients from offering 1.2 or older [ and maybe require servers to enforce this ] .
Paragraph (version A):
A badly configured TLS implementation could negotiate TLS 1.2 or
another older version of TLS.  An endpoint MUST terminate the
connection if a version of TLS older than 1.3 is negotiated.
Paragraph (version B):
Clients MUST NOT offer TLS versions older than 1.3.  A badly
configured TLS implementation could negotiate TLS 1.2 or another
older version of TLS.  An endpoint MUST terminate the connection if a
version of TLS older than 1.3 is negotiated.
Draft: draft-ietf-quic-transport

Commentary: This uses positive framing for the recommendation to use frames rather than packets . And it makes that recommendation directly , rather than implying it . 
 Here are three quasi - nits about S 12.2 . Handshake , 1 - RTT ; see Section 4.1.4 of { { QUIC - TLS } } ) makes it more likely the receiver will be able to process all the packets in a single pass . A packet with a short header does not include a length , so it can only be the last packet included in a UDP datagram . An endpoint SHOULD NOT coalesce multiple packets at the same encryption level . Is the implication here that you should instead pack all the frames into one packet ? UDP datagram . Senders MUST NOT coalesce QUIC packets for different connections into a single UDP datagram . Receivers SHOULD ignore any subsequent packets with a different Destination Connection ID than the first packet in the datagram . Is there a valid reason to have different SCIDs ? ( { { packet - version } } ) , and packets with a short header ( { { short - header } } ) do not contain a Length field and so can not be followed by other packets in the same UDP datagram . Note also that there is no situation where a Retry or Version Negotiation packet is coalesced with another packet . Should this be a MUST NOT ? 
 . . do n't see why . It 's just a fact , not a conformance requirement . 
 For ( 1 ) I think it would be helpful to say that . 
 LGTM , one suggestion .
Paragraph (version A):
Coalescing packets in order of increasing encryption levels (Initial,
0-RTT, Handshake, 1-RTT; see Section 4.1.4 of QUIC-TLS) makes it more
likely the receiver will be able to process all the packets in a
single pass.  A packet with a short header does not include a length,
so it can only be the last packet included in a UDP datagram.  An
endpoint SHOULD NOT coalesce multiple packets at the same encryption
level.
Paragraph (version B):
Coalescing packets in order of increasing encryption levels (Initial,
0-RTT, Handshake, 1-RTT; see Section 4.1.4 of QUIC-TLS) makes it more
likely the receiver will be able to process all the packets in a
single pass.  A packet with a short header does not include a length,
so it can only be the last packet included in a UDP datagram.  An
endpoint SHOULD include multiple frames in a single packet if they
are to be sent at the same encryption level, instead of coalescing
multiple packets at the same encryption level.
Draft: draft-ietf-quic-invariants

Commentary: This clarifies that it is a mechanism in the target QUIC version that authenticates the information . This also lifts the strong requirement on authenticating the contents of Version Negotiation . QUIC version 1 does not do this and so does not comply with this requirement . The intent was always that only information that is used needs to be authenticated in this way . ( This is a tiny bit of evasion as Version Negotiation is used in QUIC version 1 as a signal that a version is not supported , which results in clients abandoning connections . ) 
 This is for -invariants-09 : Section 6 says : Version Negotiation packets do not use integrity or confidentiality protection . A specific QUIC version might authenticate the packet as part of its connection establishment process . Is the second not contradicting what is said in previous paragraph : A Version Negotiation packet contains no other fields . So to my understanding the authentication that the paragraph above talks about needs to be done in another QUIC packet , it ca n't be done in a QUIC packet that is Version Negotiation . Can this be made more explicit or do I misunderstand and can you then clarify why this is not a contradiction ? 
 I do n't see this as contradictory . The sentence here : Implies that the version fields might be authenticated . Indeed , the document says that they MUST be authenticated ( somehow ) . It does n't say how . However , this ... means that it ca n't use any fields that are included in a Version Negotiation packet to do that . If you look at the current proposal for , that uses transport parameters . 
 Ok , then I would request a very minor tweak in this sentence : A specific QUIC version might authenticate the packet as part of its connection establishment process . So that it is explicit that is in another packet(s ) than the Version negotiation packet . For example : A specific QUIC version might authenticate the version negotiation packet as part of its connection establishment process outside of this packet . 
 I have made a slightly larger tweak .
Paragraph (version A):
Version Negotiation packets do not use integrity or confidentiality
protection.  Specific QUIC versions define mechanisms to authenticate
the packet as part of the connection establishment process.
Paragraph (version B):
Version Negotiation packets do not use integrity or confidentiality
protection.  Specific QUIC versions might include protocol elements
that allow endpoints to detect modification or corruption in the set
of supported versions.
Paragraph (version A):
The Version Negotiation packet described in this document is not
integrity-protected; it only has modest protection against insertion
by off-path attackers.  QUIC versions MUST define a mechanism that
authenticates the values it contains.
Paragraph (version B):
The Version Negotiation packet described in this document is not
integrity-protected; it only has modest protection against insertion
by off-path attackers.  An endpoint MUST authenticate the contents of
a Version Negotiation packet if it attempts a different QUIC version
as a result.
Draft: draft-ietf-quic-transport

Commentary: Those packets that are not authenticated can be discarded , but only if processing them has no permanent effect on existing state . This attempts to explain that . 
 S 5.2 . says : Invalid packets without packet protection , such as Initial , Retry , or Version Negotiation , MAY be discarded . An endpoint MUST generate a connection error if it commits changes to state before discovering an error . I 'm having trouble parsing this . 
 LGTM
Paragraph (version A):
Invalid packets without packet protection, such as Initial, Retry, or
Version Negotiation, MAY be discarded.  An endpoint MUST generate a
connection error if it commits changes to state before discovering an
error.
Paragraph (version B):
Invalid packets without packet protection, such as Initial, Retry, or
Version Negotiation, MAY be discarded.  An endpoint MUST generate a
connection error if processing of the contents of these packets prior
to discovering an error resulted in changes to the state of a
connection that cannot be reverted.
Draft: draft-ietf-quic-tls

Commentary: This was never explicit for the client as it is usually not possible . in a way that perhaps was not anticipated . 
 is complete . Consequently , a server might expect 0 - RTT packets to start with a However , this is not necessarily strictly true , because you might have the ACKs in 0.5RTT . Now you might say that the TLS stack reports the handshake as complete as soon as it receives Finished but that 's an implementation detail 
 I think that this is true . The server can send before then , but we require that the client not install 1 - RTT keys until it considers the handshake complete . 
 That 's not entirely true . It 's the server that needs to hold back keys ( namely , the 1 - RTT read key ) until the handshake completes . The client can use keys as soon as they become available . 
 I think is correct in sense that the following three events happen at the same moment on the client side : handshake is declared complete TLS stack provides the 1 - RTT read and write keys TLS stack provides ClientFinished 
 Martin is correct . There are two different forms of handshake completion : complete when 1rtt can be sent and received , confirmed when the peer is known to be complete . The client can not receive  acks before installing 1rtt keys , hence before hanshake is complete . 
 a nit , but LGTM
Paragraph (version A):
Therefore, the server's use of 1-RTT keys MUST be limited to sending
data before the handshake is complete.  A server MUST NOT process
incoming 1-RTT protected packets before the TLS handshake is
complete.  Because sending acknowledgments indicates that all frames
in a packet have been processed, a server cannot send acknowledgments
for 1-RTT packets until the TLS handshake is complete.  Received
packets protected with 1-RTT keys MAY be stored and later decrypted
and used once the handshake is complete.
Paragraph (version B):
Therefore, the server's use of 1-RTT keys before the handshake is
complete is limited to sending data.  A server MUST NOT process
incoming 1-RTT protected packets before the TLS handshake is
complete.  Because sending acknowledgments indicates that all frames
in a packet have been processed, a server cannot send acknowledgments
for 1-RTT packets until the TLS handshake is complete.  Received
packets protected with 1-RTT keys MAY be stored and later decrypted
and used once the handshake is complete.
Paragraph (version B):
A client generally receives 1-RTT keys at the same time as the
handshake completes.  Even if it has 1-RTT secrets, a client MUST NOT
process incoming 1-RTT protected packets before the TLS handshake is
complete.
Draft: draft-ietf-quic-transport

Commentary: Not saying explicitly that was a small oversight . 
 S 5.2.2 says : Packets with a supported version , or no version field , are matched to a connection using the connection ID or - for packets with zero - length connection IDs - the local address and port . If the packet does n't match an existing connection , the server continues below . So , this tells us what to do if we do n't match , but not if we do match . I know this is a nit , but I think there should be some kind of pointer after the first sentence . 
 LGTM
Paragraph (version A):
Packets with a supported version, or no version field, are matched to
a connection using the connection ID or - for packets with zero-
length connection IDs - the local address and port.  If the packet
doesn't match an existing connection, the server continues below.
Paragraph (version B):
Packets with a supported version, or no version field, are matched to
a connection using the connection ID or - for packets with zero-
length connection IDs - the local address and port.  These packets
are processed using the selected connection, otherwise the server
continues below.