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

Commentary: said : 
 I think " can " works equally well , given the precondition . I 'll make that change .
Paragraph (version A):
A token allows a server to correlate activity between the connection
where the token was issued and any connection where it is used.
Clients that want to break continuity of identity with a server MAY
discard tokens provided using the NEW_TOKEN frame.  In comparison, a
token obtained in a Retry packet MUST be used immediately during the
connection attempt and cannot be used in subsequent connection
attempts.
Paragraph (version B):
A token allows a server to correlate activity between the connection
where the token was issued and any connection where it is used.
Clients that want to break continuity of identity with a server can
discard tokens provided using the NEW_TOKEN frame.  In comparison, a
token obtained in a Retry packet MUST be used immediately during the
connection attempt and cannot be used in subsequent connection
attempts.
Draft: draft-ietf-quic-transport

Commentary: said :
Paragraph (version A):
When a sender receives credit after being blocked, it might be able
to send a large amount of data in response, resulting in short-term
congestion; see Section 6.9 in QUIC-RECOVERY for a discussion of how
a sender can avoid this congestion.
Paragraph (version B):
When a sender receives credit after being blocked, it might be able
to send a large amount of data in response, resulting in short-term
congestion; see Section 7.7 in QUIC-RECOVERY for a discussion of how
a sender can avoid this congestion.
Draft: draft-ietf-quic-recovery

Commentary: and the 20 - byte overhead too . ( If this is superseded , that 's cool . Low hanging fruit ... ) 
   said :
Paragraph (version A):
QUIC begins every connection in slow start with the congestion window
set to an initial value.  Endpoints SHOULD use an initial congestion
window of 10 times the maximum datagram size (max_datagram_size),
limited to the larger of 14720 bytes or twice the maximum datagram
size.  This follows the analysis and recommendations in RFC6928,
increasing the byte limit to account for the smaller 8 byte overhead
of UDP compared to the 20 byte overhead for TCP.
Paragraph (version B):
QUIC begins every connection in slow start with the congestion window
set to an initial value.  Endpoints SHOULD use an initial congestion
window of 10 times the maximum datagram size (max_datagram_size),
limited to the larger of 14720 bytes or twice the maximum datagram
size.  This follows the analysis and recommendations in RFC6928,
increasing the byte limit to account for the smaller 8-byte overhead
of UDP compared to the 20-byte overhead for TCP.
Draft: draft-ietf-quic-transport

Commentary: They only need to be good for one RTT . Of course , the server does n't really know what the RTT is , so this is n't something firm , and I do n't want to explain ALL of that , but this should do . 
   said :
Paragraph (version A):
Attackers could replay tokens to use servers as amplifiers in DDoS
attacks.  To protect against such attacks, servers MUST ensure that
replay of tokens is prevented or limited.  Servers SHOULD ensure that
tokens sent in Retry packets are only accepted for a short time.
Tokens that are provided in NEW_TOKEN frames (frame-new-token) need
to be valid for longer, but SHOULD NOT be accepted multiple times in
a short period.  Servers are encouraged to allow tokens to be used
only once, if possible; tokens MAY include additional information
about clients to further narrow applicability or reuse.
Paragraph (version B):
Attackers could replay tokens to use servers as amplifiers in DDoS
attacks.  To protect against such attacks, servers MUST ensure that
replay of tokens is prevented or limited.  Servers SHOULD ensure that
tokens sent in Retry packets are only accepted for a short time, as
they are returned immediately by clients.  Tokens that are provided
in NEW_TOKEN frames (frame-new-token) need to be valid for longer,
but SHOULD NOT be accepted multiple times.  Servers are encouraged to
allow tokens to be used only once, if possible; tokens MAY include
additional information about clients to further narrow applicability
or reuse.
Draft: draft-ietf-quic-transport

Commentary:   said :
Paragraph (version A):
fig-hs shows a simplified handshake and the exchange of packets and
frames that are used to advance the handshake.  Exchange of
application data during the handshake is enabled where possible,
shown with a '*'.  Once completed, endpoints are able to exchange
application data.
Paragraph (version B):
fig-hs shows a simplified handshake and the exchange of packets and
frames that are used to advance the handshake.  Exchange of
application data during the handshake is enabled where possible,
shown with a '*'.  Once the handshake is complete, endpoints are able
to exchange application data freely.
Draft: draft-ietf-quic-transport

Commentary:   said :
Paragraph (version A):
Once a receiver advertises a limit for the connection or a stream, it
MAY advertise a smaller limit, but this has no effect.
Paragraph (version B):
Once a receiver advertises a limit for the connection or a stream, it
is not an error to advertise a smaller limit, but the smaller limit
has no effect.
Draft: draft-ietf-quic-transport

Commentary:   said : 
 The other reference was : — Section 3.5 — An endpoint SHOULD copy the error code from the STOPSENDING frame to the RESETSTREAM frame it sends , but MAY use any application error code . I 'm OK with changing to " can " . 
 I do n't think we need to do this ; I 've suggested changes on the PR . 
 Ok , let 's merge this one , and I 'll make a separate PR for the second comment .
Paragraph (version A):
An endpoint SHOULD copy the error code from the STOP_SENDING frame to
the RESET_STREAM frame it sends, but MAY use any application error
code.  An endpoint that sends a STOP_SENDING frame MAY ignore the
error code in any RESET_STREAM frames subsequently received for that
stream.
Paragraph (version B):
An endpoint SHOULD copy the error code from the STOP_SENDING frame to
the RESET_STREAM frame it sends, but can use any application error
code.  An endpoint that sends a STOP_SENDING frame MAY ignore the
error code in any RESET_STREAM frames subsequently received for that
stream.
Paragraph (version A):
Once the server has completed its path validation and has received a
non-probing packet with a new largest packet number on its preferred
address, the server begins sending non-probing packets to the client
exclusively from its preferred IP address.  It SHOULD drop packets
for this connection received on the old IP address, but MAY continue
to process delayed packets.
Paragraph (version B):
Once the server has completed its path validation and has received a
non-probing packet with a new largest packet number on its preferred
address, the server begins sending non-probing packets to the client
exclusively from its preferred IP address.  It SHOULD drop packets
for this connection received on the old IP address, but can continue
to process delayed packets.
Draft: draft-ietf-quic-invariants

Commentary: This reconciles the abstract with the content 
 Éric Vyncke said : 
 The abstract has n't kept pace with the text . It can be made clearer .
Paragraph (version A):
This document defines the properties of the QUIC transport protocol
that are expected to remain unchanged over time as new versions of
the protocol are developed.
Paragraph (version B):
This document defines the properties of the QUIC transport protocol
that are common to all versions of the protocol.
Draft: draft-ietf-quic-transport

Commentary:   said :
Paragraph (version A):
If a server receives a packet that indicates an unsupported version
but is large enough to initiate a new connection for any supported
version, the server SHOULD send a Version Negotiation packet as
described in send-vn.  A server MAY limit the number of packets to
which it responds with a Version Negotiation packet.  Servers MUST
drop smaller packets that specify unsupported versions.
Paragraph (version B):
If a server receives a packet that indicates an unsupported version
and if the packet is large enough to initiate a new connection for
any supported version, the server SHOULD send a Version Negotiation
packet as described in send-vn.  A server MAY limit the number of
packets to which it responds with a Version Negotiation packet.
Servers MUST drop smaller packets that specify unsupported versions.
Draft: draft-ietf-quic-recovery

Commentary:   said :
Paragraph (version A):
QUIC ACKs contain information that is similar to TCP SACK, but QUIC
does not allow any acknowledged packet to be reneged, greatly
simplifying implementations on both sides and reducing memory
pressure on the sender.
Paragraph (version B):
QUIC ACK frames contain information similar to that in TCP Selective
Acknowledgements (SACKs, RFC2018).  However, QUIC does not allow a
packet acknowledgement to be reneged, greatly simplifying
implementations on both sides and reducing memory pressure on the
sender.
Draft: draft-ietf-quic-transport

Commentary:   said : 
 Yes , that 's correct .
Paragraph (version A):
The server's preferred address is used to effect a change in
server address at the end of the handshake, as described in
preferred-address.  This transport parameter is only sent by a
server.  Servers MAY choose to only send a preferred address of
one address family by sending an all-zero address and port
(0.0.0.0:0 or ::.0) for the other family.  IP addresses are
encoded in network byte order.
Paragraph (version B):
The server's preferred address is used to effect a change in
server address at the end of the handshake, as described in
preferred-address.  This transport parameter is only sent by a
server.  Servers MAY choose to only send a preferred address of
one address family by sending an all-zero address and port
(0.0.0.0:0 or [::]:0) for the other family.  IP addresses are
encoded in network byte order.
Draft: draft-ietf-quic-transport

Commentary: It was pretty obtuse otherwise . 
   said : 
 one nit
Paragraph (version A):
QUIC relies on a combined cryptographic and transport handshake to
minimize connection establishment latency.  QUIC uses the CRYPTO
frame (frame-crypto) to transmit the cryptographic handshake.
Version 0x00000001 of QUIC uses TLS as described in QUIC-TLS; a
different QUIC version number could indicate that a different
cryptographic handshake protocol is in use.
Paragraph (version B):
QUIC relies on a combined cryptographic and transport handshake to
minimize connection establishment latency.  QUIC uses the CRYPTO
frame (frame-crypto) to transmit the cryptographic handshake.  The
version of QUIC defined in this document is identified as 0x00000001
and uses TLS as described in QUIC-TLS; a different QUIC version could
indicate that a different cryptographic handshake protocol is in use.
Draft: draft-ietf-quic-transport

Commentary:   said : 
 We say it , but it comes a lot later . Too late , I think .
Paragraph (version B):
Multiple connection IDs are used so that endpoints can send packets
that cannot be identified by an observer as being for the same
connection without cooperation from an endpoint; see migration-
linkability.
Draft: draft-ietf-quic-transport

Commentary:   said :
Paragraph (version A):
A client only receives acknowledgments for its 0-RTT packets once the
handshake is complete, as defined Section 4.1.1 of QUIC-TLS.
Paragraph (version B):
A client only receives acknowledgments for its 0-RTT packets once the
handshake is complete, as defined in Section 4.1.1 of QUIC-TLS.
Draft: draft-ietf-quic-transport

Commentary:   said :
Paragraph (version A):
A token sent in a NEW_TOKEN frames or a Retry packet MUST be
constructed in a way that allows the server to identify how it was
provided to a client.  These tokens are carried in the same field,
but require different handling from servers.
Paragraph (version B):
A token sent in a NEW_TOKEN frame or a Retry packet MUST be
constructed in a way that allows the server to identify how it was
provided to a client.  These tokens are carried in the same field,
but require different handling from servers.
Draft: draft-ietf-quic-transport

Commentary: This is my best stab at it . 
   said : 
 I thought that section reference was wrong , but Section 7 does indeed mention ECN twice . Once is almost too much for this section . I checked the history and the commits that affected this text likely are the result of a merge , and one that either git resolved incorrectly for us , or one that we messed up . Either way , this is worth fixing . 
 one nit
Paragraph (version A):
Endpoints can use packets sent during the handshake to test for
Explicit Congestion Notification (ECN) support; see ecn.  An endpoint
verifies support for ECN by observing whether the ACK frames
acknowledging the first packets it sends carry ECN counts, as
described in ecn-validation.
Paragraph (version A):
An endpoint validates support for Explicit Congestion Notification
(ECN) by observing whether the ACK frames acknowledging the first
packets it sends carry ECN counts, as described in ecn-validation.
Paragraph (version B):
Endpoints can use packets sent during the handshake to test for
Explicit Congestion Notification (ECN) support; see ecn.  An endpoint
validates support for ECN by observing whether the ACK frames
acknowledging the first packets it sends carry ECN counts, as
described in ecn-validation.
Draft: draft-ietf-quic-transport

Commentary: the path does n't provide extra headroom . Includes some rewording of the text . 
   said : 
 We wanted some space for things like extension headers / options and maybe for tunnels . See which is in response to your peer  . And yeah , 1200 is a nice number . 
 Based on the discussion here and the linked issue , I do n't think we need to do anything here . 
   said : 
 Seems reasonable to mention . Obviously many paths support a larger MTU and so will support more extensions ( or options ) , but it 's worth noting that there is n't a ton of space available .
Paragraph (version B):
This requirement to support a UDP payload of 1200 bytes limits the
space available for IPv6 extension headers to 32 bytes or IPv4
options to 52 bytes if the path only supports the IPv6 minimum MTU
of 1280 bytes.  This affects Initial packets and path validation.
Paragraph (version A):
If a QUIC endpoint determines that the PMTU between any pair of local
and remote IP addresses has fallen below the smallest allowed maximum
datagram size of 1200 bytes, it MUST immediately cease sending QUIC
packets, except for those in PMTU probes or those containing
CONNECTION_CLOSE frames, on the affected path.  An endpoint MAY
terminate the connection if an alternative path cannot be found.
Paragraph (version B):
If a QUIC endpoint determines that the PMTU between any pair of local
and remote IP addresses cannot support the smallest allowed maximum
datagram size of 1200 bytes, it MUST immediately cease sending QUIC
packets, except for those in PMTU probes or those containing
CONNECTION_CLOSE frames, on the affected path.  An endpoint MAY
terminate the connection if an alternative path cannot be found.
Draft: draft-ietf-quic-transport

Commentary: The text was probably backwards , but rather than invert it , remove the indirect reference to the subject of the claim and be explicit . 
   said :
Paragraph (version A):
The IPv6 flow label SHOULD be a pseudo-random function of the source
and destination addresses, source and destination UDP ports, and the
Destination Connection ID field.  The flow label generation MUST be
designed to minimize the chances of linkability with a previously
used flow label, as this would enable correlating activity on
multiple paths; see migration-linkability.
Paragraph (version B):
The IPv6 flow label SHOULD be a pseudo-random function of the source
and destination addresses, source and destination UDP ports, and the
Destination Connection ID field.  The flow label generation MUST be
designed to minimize the chances of linkability with a previously
used flow label, as a stable flow label would enable correlating
activity on multiple paths; see migration-linkability.
Draft: draft-ietf-quic-transport

Commentary: This was definitely odd . Let 's take another tilt at making it comprehensible . 
   said : 
 Yep , when it 's called out , it 's distinctly odd . Hopefully it 's an easy fix , but writing is hardd .
Paragraph (version A):
If the PATH_CHALLENGE frame that resulted in successful path
validation was sent in a datagram that was not expanded to at least
1200 bytes, the endpoint can regard the address as valid.  The
endpoint is then able to send more than three times the amount of
data that has been received.  However, the endpoint MUST initiate
another path validation with an expanded datagram to verify that the
path supports required MTU.
Paragraph (version B):
If an endpoint sends a PATH_CHALLENGE frame in a datagram that is not
expanded to at least 1200 bytes, and if the response to it validates
the peer address, the path is validated but not the path MTU.  As a
result, the endpoint can now send more than three times the amount of
data that has been received.  However, the endpoint MUST initiate
another path validation with an expanded datagram to verify that the
path supports the required MTU.
Draft: draft-ietf-quic-tls

Commentary: We changed the limits listed here to be based on the maximum packet size , so the note a few paragraphs up citing the appendix is all we need here . 
 said : 
 A few things here ... text in DTLS is a copy of this text , so similarities are no accident . However , the text has diverged , so drawing an analogy does n't seem necessary ( and I do n't want a downref , even if it were informational ) . numbers we are using from TLS is the target advantage probability . QUIC has a larger limit on packet size than TLS has on record size . Larger sizes affects the limits , which is what you see there . note you quote is old and it should have been removed when we changed the numbers . noted the analysis for DTLS would be helpful , but not definitive . As you say , the number of blocks in a packet can have an effect ( though not for ChaCha20Poly1305 apparently ) . So l've a PR for the note , but I do n't see any other action here . 
 I have an action item ( to pester the DTLS 1.3 authors to reduce the divergence ) , but I agree there 's no other action for this document .
Paragraph (version A):
These limits were originally calculated using assumptions about
the limits on TLS record size.  The maximum size of a TLS record
is 2^14 bytes.  In comparison, QUIC packets can be up to 2^16
bytes.  However, it is expected that QUIC packets will generally
be smaller than TLS records.  Where packets might be larger than
2^14 bytes in length, smaller limits might be needed.
Draft: draft-ietf-quic-tls

Commentary: said : 
 Reasonable suggestion , as the TLS design is a reference . 
 Thank you !
Paragraph (version B):
Initiating a key update results in both endpoints updating keys.
This differs from TLS where endpoints can update keys independently.
Draft: draft-ietf-quic-tls

Commentary: So it could be unsafe for use in 0 - RTT . 
 said : 
 STOP_SENDING can be sent in 0 - RTT . It should be in the list .
Paragraph (version A):
Of the frames defined in QUIC-TRANSPORT, the STREAM, RESET_STREAM,
and CONNECTION_CLOSE frames are potentially unsafe for use with 0-RTT
as they carry application data.  Application data that is received in
0-RTT could cause an application at the server to process the data
multiple times rather than just once.  Additional actions taken by a
server as a result of processing replayed application data could have
unwanted consequences.  A client therefore MUST NOT use 0-RTT for
application data unless specifically requested by the application
that is in use.
Paragraph (version B):
Of the frames defined in QUIC-TRANSPORT, the STREAM, RESET_STREAM,
STOP_SENDING, and CONNECTION_CLOSE frames are potentially unsafe for
use with 0-RTT as they carry application data.  Application data that
is received in 0-RTT could cause an application at the server to
process the data multiple times rather than just once.  Additional
actions taken by a server as a result of processing replayed
application data could have unwanted consequences.  A client
therefore MUST NOT use 0-RTT for application data unless specifically
requested by the application that is in use.
Draft: draft-ietf-quic-tls

Commentary: This is a little pedantic , but it 's more correct . Also fix reference format . 
 said :
Paragraph (version A):
Once an endpoint successfully receives a packet with a given packet
number, it MUST discard all packets in the same packet number space
with higher packet numbers if they cannot be successfully unprotected
with either the same key, or - if there is a key update - the next
packet protection key (see key-update).  Similarly, a packet that
appears to trigger a key update, but cannot be unprotected
successfully MUST be discarded.
Paragraph (version B):
Once an endpoint successfully receives a packet with a given packet
number, it MUST discard all packets in the same packet number space
with higher packet numbers if they cannot be successfully unprotected
with either the same key, or - if there is a key update - a
subsequent packet protection key; see key-update.  Similarly, a
packet that appears to trigger a key update, but cannot be
unprotected successfully MUST be discarded.
Draft: draft-ietf-quic-tls

Commentary: Though people will undoubtedly rely on pseudocode to understand this , there is no reason why we ca n't also use prose . 
 said : 
 That 's just an oops . There is a paragraph that almost defines this in prose . It just needs a little push and we do n't need to rely exclusively on pseudocode .
Paragraph (version A):
The same number of bytes are always sampled, but an allowance needs
to be made for the endpoint removing protection, which will not know
the length of the Packet Number field.  In sampling the packet
ciphertext, the Packet Number field is assumed to be 4 bytes long
(its maximum possible encoded length).
Paragraph (version B):
The same number of bytes are always sampled, but an allowance needs
to be made for the endpoint removing protection, which will not know
the length of the Packet Number field.  The sample of ciphertext is
taken starting from an offset of 4 bytes after the start of the
Packet Number field.  That is, in sampling packet ciphertext for
header protection, the Packet Number field is assumed to be 4 bytes
long (its maximum possible encoded length).
Draft: draft-ietf-quic-tls

Commentary: This changes the shape of the requirement from one that proscribes the behaviour of a TLS stack to the reaction of QUIC to a warning level alert . This recommends treating them as fatal as QUIC never deliberately closes TLS . This is a normative change that should have no practical effect on implementations . 
 said : 
 I 'm going to request that we flag this one " design " . I think that we want to say : TLS connection is never closed using TLS mechanisms can treat any TLS alert as fatal PR created and email in the pipe . 
 Marking this as design as requested . 
 Returning to an open state as the chairs directed in their plan . 
 Closing this now that the IESG have approved the document(s ) . 
 I agree that this is a good improvement , especially for folks who ca n't modify their TLS stack .
Paragraph (version A):
The alert level of all TLS alerts is "fatal"; a TLS stack MUST NOT
generate alerts at the "warning" level.
Paragraph (version B):
QUIC is only able to convey an alert level of "fatal".  In TLS 1.3,
the only existing uses for the "warning" level are to signal
connection close; see Section 6.1 of TLS13.  As QUIC provides
alternative mechanisms for connection termination and the TLS
connection is only closed if an error is encountered, a QUIC endpoint
MUST treat any alert from TLS as if it were at the "fatal" level.