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

Commentary: I think this helps ? 
 Magnus  : scenario of " mutual distrustful parties " is unclear to me . One stated scenario is where multiple client connections aggregate at an intermediary that then maintains a single connection to an origin server . Another stated scenario is where multiple origin servers connect to an intermediary which then serves a client . In these scenarios , is the concern that the intermediary may control either a client or an origin server and thus would be able to leverage the compression context at , say , a second client and then observe ( as the intermediary ) the result of a guess for a field tuple ? It may be helpful to explain this in a little more detail . as to what strategy ( option ) implementations should choose to protect against this attack . It seems like the Never - Indexed - Literal is a good candidate which should be easy to implement . 
 This text was mostly lifted from RFC 7541 . intermediary may control either a client or an origin server and thus would be able to leverage the compression context at , say , a second client and then observe ( as the intermediary ) the result of a guess for a field tuple ? Yes , this is the concern . It 's interesting that ' intermediary ' here also refers to a browser that coalesces requests from different tabs onto the same connection . I agree . as to what strategy ( option ) implementations should choose to protect against this attack . I think the document recommends the tagging option unambiguously : " An ideal solution segregates access to the dynamic table based on the entity that is constructing the message " While never - index literals is the less complicated fallback option . 
 so are you proposing any changes to the text ?
Paragraph (version A):
Attacks of this nature are possible any time that two mutually
distrustful entities control requests or responses that are placed
onto a single HTTP/3 connection.  If the shared QPACK compressor
permits one entity to add entries to the dynamic table, and the other
to access those entries, then the state of the table can be learned.
Paragraph (version B):
Attacks of this nature are possible any time that two mutually
distrustful entities control requests or responses that are placed
onto a single HTTP/3 connection.  If the shared QPACK compressor
permits one entity to add entries to the dynamic table, and the other
to access those entries to encode chosen field lines, then the
attacker can learn the state of the table by observing the length of
the encoded output.
Draft: draft-ietf-quic-recovery

Commentary: Removes the word ack - eliciting in the descriptive text to persistent congestion . It also contains minor text changes in the following of that section . 
 I 'm taking the suggested changes and this PR . Thanks , ! 
 On the mailing list   asked some questions about persistent congestion and why it was only applicable to in - flight packets . During the explanation , I realized that it should probably be ack - eliciting packets , not in - flight . UPDATE : It already is ack - eliciting in all but one spot . I wrote PR to fix that one spot . 
 To have the context , I quote your explanation . I think ack - eliciting makes more sense here than in - flight . At least , I understand that for the persistent congestion detection the first and the last packet need to be ack - eliciting . But why does this have to be true for packets sent between these two ack - eliciting packets ? Here is an example for the edge case . The loss of three out of 50 packets let the sender consider this a persistent congestion . In general , I do n't see a real issue here . But , I would like to understand why it is helpful to ignore the fact that non - ack - eliciting packets , sent between two lost ack - eliciting packets , have been acknowledged . 
 This absolutely should not be in flight packets . This may not cause a major issue as it stands but it is not technically correct . 
 The text is largely correct(ack - eliciting , not in - flight ) already , based on my reading . Unfortunately , the very first description is incorrect , which is potentially confusing , so see 
 Looking good , one further suggestion .
Paragraph (version A):
When a sender establishes loss of all ack-eliciting packets sent over
a long enough duration, the network is considered to be experiencing
persistent congestion.
Paragraph (version B):
When a sender establishes loss of all packets sent over a long enough
duration, the network is considered to be experiencing persistent
congestion.
Paragraph (version B):
These two packets MUST be ack-eliciting, since a receiver is required
to acknowledge only ack-eliciting packets within its maximum ack
delay; see Section 13.2 of QUIC-TRANSPORT.
Draft: draft-ietf-quic-transport

Commentary: I looked into the commits but I can not identify the commit which removed this line . 
 Gah ! Thanks for catching this ! !
Paragraph (version B):
An opaque blob that the client can use with a future Initial
packet.  The token MUST NOT be empty.  A client MUST treat receipt
of a NEW_TOKEN frame with an empty Token field as a connection
error of type FRAME_ENCODING_ERROR.
Draft: draft-ietf-quic-transport

Commentary: Minor nit while looking at ; the definition of generic " Long - Header Packets " wo n't actually match any real packet types , because it ends after the CIDs . This modifies the definition to add a final " Type - Specific Payload " section to the figure . 
 While the transport draft talks a lot about " 1 - RTT packets " , the term is not defined . We also have a sentence that seem to imply that a long - header variant of 1 - RTT packets might exist ( ) . We refer to the packet less frequently as " short header packets " or " packet with a short header . " As a resolution , I think we might want to change the title of section 17.3 from " Short Header Packets " to " 1 - RTT Packets " . Rest of the text can remain the same , as the first sentence of that section says that it is the only type of short header packet that we define .
Paragraph (version B):
The remainder of the packet, if any, is type-specific.
Draft: draft-ietf-quic-transport

Commentary: Minimum packet size varies between the packet types ( and other things like the length of CID being used ) . Therefore , the sentence is merely providing an example , and should be stated as such . . 
 Currently section 10.3 of the transport doc says : However , Version Negotiation packets are not guaranteed to be larger than 21 bytes . For example , a VN packet with an 0 - byte destination connection ID , 8 byte source connection ID and single version would be 19 bytes . If a client receives such a packet , must it be dropped ? This text suggests it must . But it 's not clear to mean ( or the slack channel ) that this interpretation is expected . Of course , a server could work around this issue by appending a sufficient number of GREASE'd versions to make the packet large enough . But I 'm not sure if that is mandatory ? 
 The second sentence merely points out that QUIC packets that use AEAD can never be smaller than 21 bytes . VN packets do not use AEAD , hence that 21 byte limit does not apply . Of course , endpoints can do their own maths to figure out the minimal size of VN packets that they might receive . Just my two cents . We might want to clarify the italic part ( " that use AEAD " ) in the specification . 
 I agree with that the spec is n't technically wrong , but I find it unclear . It would n't surprise me if someone were to read this and add to their packet ingestion code . I think all we need here is an editorial clarification such as 
 Note : 21 is the correct number , as requires endpoints to expand the payload size to at least 4 + len(AEAD tag ) , so that we can always have full - sized entropy for header protection . 
 Thanks  , this is great . What I like about this is that it also implies the possibility of a higher minimum . For instance , the limit on long headers is higher ( 28 for Initial , 27 for 0 - RTT and handshake if I 'm right , but you can also add the minimum connection ID length for receiving to that ) .
Paragraph (version A):
Endpoints MUST discard packets that are too small to be valid QUIC
packets.  With the set of AEAD functions defined in QUIC-TLS, packets
that are smaller than 21 bytes are never valid.
Paragraph (version B):
Endpoints MUST discard packets that are too small to be valid QUIC
packets.  To give an example, with the set of AEAD functions defined
in QUIC-TLS, short header packets that are smaller than 21 bytes are
never valid.
Draft: draft-ietf-quic-http

Commentary: Please see the for full context . This issue is tracking the following IANA question : 
 Responded to e - mail as well , but for GitHub tracking purposes , I believe HTTP/3 should be its own registry page , separate from QUIC and analogous to HTTP/2 . 
 I think that is a good proposal . 
 Can we put that in the draft then ?
Paragraph (version A):
New registries created in this document operate under the QUIC
registration policy documented in Section 22.1 of QUIC-TRANSPORT.
These registries all include the common set of fields listed in
Section 22.1.1 of QUIC-TRANSPORT.
Paragraph (version B):
New registries created in this document operate under the QUIC
registration policy documented in Section 22.1 of QUIC-TRANSPORT.
These registries all include the common set of fields listed in
Section 22.1.1 of QUIC-TRANSPORT.  These registries [SHALL be/are]
collected under a "Hypertext Transfer Protocol version 3 (HTTP/3)
Parameters" heading.
Draft: draft-ietf-quic-transport

Commentary: Sec 12.4 says : There is no specification of error handling in the case of zero frame . I would like to know what kind of error MUST be sent . Also , the packet formats contains the following field : Should we change this to the following ?
Paragraph (version A):
The payload of a packet that contains frames MUST contain at least
one frame, and MAY contain multiple frames and multiple frame types.
Frames always fit within a single QUIC packet and cannot span
multiple packets.
Paragraph (version B):
The payload of a packet that contains frames MUST contain at least
one frame, and MAY contain multiple frames and multiple frame types.
An endpoint MUST treat receipt of a packet containing no frames as a
connection error of type PROTOCOL_VIOLATION.  Frames always fit
within a single QUIC packet and cannot span multiple packets.
Draft: draft-ietf-quic-transport

Commentary: Because it always is . 
 I 'm checking " MUST treat " in the transport draft . Sec 17.2.4 says : This is only the place where the type of a connection error is NOT specified . This part should be modified as " a connection error of XXX " . 
 This was deliberate , but you can now send CONNECTION_CLOSE in this case , so it makes sense to use a code here .
Paragraph (version A):
The payload of this packet contains CRYPTO frames and could contain
PING, PADDING, or ACK frames.  Handshake packets MAY contain
CONNECTION_CLOSE frames of type 0x1c.  Endpoints MUST treat receipt
of Handshake packets with other frames as a connection error.
Paragraph (version B):
The payload of this packet contains CRYPTO frames and could contain
PING, PADDING, or ACK frames.  Handshake packets MAY contain
CONNECTION_CLOSE frames of type 0x1c.  Endpoints MUST treat receipt
of Handshake packets with other frames as a connection error of type
PROTOCOL_VIOLATION.
Draft: draft-ietf-quic-transport

Commentary: You have a comment here pending . I 'm planning to merge this PR in ~15 hours from now , so please say something now if you still would prefer a change . 
 Section 22.1.4 : " For instance , the registries for 62 - bit codepoints in this document have stricter policies for codepoints in the range from 0 to 63 . " Looking then at 22.2 it states : The " QUIC Transport Parameters " registry governs a 62 - bit space . This registry follows the registration policy from Section 22.1 . Permanent registrations in this registry are assigned using the Specification Required policy ( [ RFC8126 ] ) . No mention of the special registration rule for values in the 0 - 63 range . Section 22.3 and 22.4 do have these special rules . So should 22.1.4 be changed to state " may"/"sometime " have this rule . Or should a special rule be to 22.2 and the version registry ?
Paragraph (version A):
The creation of a registry MAY identify a range of codepoints where
registrations are governed by a different registration policy.  For
instance, the registries for 62-bit codepoints in this document have
stricter policies for codepoints in the range from 0 to 63.
Paragraph (version A):
Any stricter requirements for permanent registrations do not prevent
provisional registrations for affected codepoints.  For instance, a
provisional registration for a frame type (iana-frames) of 61 could
be requested.
Paragraph (version B):
The creation of a registry MAY identify a range of codepoints where
registrations are governed by a different registration policy.  For
instance, the frame type registry in iana-frames has a stricter
policy for codepoints in the range from 0 to 63.
Paragraph (version B):
Any stricter requirements for permanent registrations do not prevent
provisional registrations for affected codepoints.  For instance, a
provisional registration for a frame type of 61 could be requested.
Draft: draft-ietf-quic-transport

Commentary: For . 
 LGTM modulo editorial suggestion , but LGTM
Paragraph (version A):
Additionally, an endpoint MAY consider the peer address validated if
the peer uses a connection ID chosen by the endpoint and the
connection ID contains at least 64 bits of entropy.  For the client,
the value of the Destination Connection ID field in its first Initial
packet also fulfills this requirement, such that successfully
processing any packet validates the server address.
Paragraph (version B):
Additionally, an endpoint MAY consider the peer address validated if
the peer uses a connection ID chosen by the endpoint and the
connection ID contains at least 64 bits of entropy.
Paragraph (version B):
For the client, the value of the Destination Connection ID field in
its first Initial packet allows it to validate the server address as
a part of successfully processing any packet.  Initial packets from
the server are protected with keys that are derived from this value
(see Section 5.2 of QUIC-TLS).  Alternatively, the value is echoed by
the server in Retry and Version Negotiation packets.
Draft: draft-ietf-quic-transport

Commentary: I think you missed the change proposed to the reference . It should point to somewhere that imposes minimum datagram size ( e.g. , { { validate - handshake } } , not { { version - negotiation } } ) . 
  . Thanks for catching that , sent . 
 ( [ IPv4 ] ) , the DF bit MUST be set if possible , to prevent fragmentation on the path . However , the size of the datagram is not authenticated . Therefore , an endpoint MUST NOT close a connection when it receives a datagram that does not meet size constraints , though the endpoint MAY discard such datagrams . I really think this section needs re - writing for clarity . 
 I find this text perfectly clear , so I will need help in identifying in what ways the text lacks clarity . 
 Other than kazuho 's nit which I regard as minor , this is good .
Paragraph (version A):
Datagrams are required to be of a minimum size under some conditions.
However, the size of the datagram is not authenticated.  Therefore,
an endpoint MUST NOT close a connection when it receives a datagram
that does not meet size constraints, though the endpoint MAY discard
such datagrams.
Paragraph (version B):
QUIC sometimes requires datagrams to be no smaller than a certain
size; see version-negotiation as an example.  However, the size of a
datagram is not authenticated.  That is, if an endpoint receives a
datagram of a certain size, it cannot know that the sender sent the
datagram at the same size.  Therefore, an endpoint MUST NOT close a
connection when it receives a datagram that does not meet size
constraints; the endpoint MAY however discard such datagrams.
Draft: draft-ietf-quic-recovery

Commentary: This is n't critical , but it 's clearer and easier to parse . All to the good . 
 Derrell Piper writes : 
 The one nit here regards this sentence : This seems right to me . You might rewrite this as : But I do n't think that is appreciably better . I think we can close this with no action unless we get some enthusiasm for rewording . 
 I think the issue is that " epoch starts is " looks like either an extra word or subject / verb agreement error . It 's not actually ; if you diagram the sentence out , " after the epoch starts " is in a dependent clause and " any packet ... is acknowledged " is correct agreement . That said , the rewording is easier to read because it does n't look wrong and you do n't have to try different possible parsings in your head before you find the one which works . We 've tried to avoid trial decryption ; let 's avoid it in grammar , too . 
 Thanks , this seems like an improvement to me .
Paragraph (version A):
QUIC starts a loss epoch when a packet is lost and ends one when any
packet sent after the epoch starts is acknowledged.  TCP waits for
the gap in the sequence number space to be filled, and so if a
segment is lost multiple times in a row, the loss epoch may not end
for several round trips.  Because both should reduce their congestion
windows only once per epoch, QUIC will do it once for every round
trip that experiences loss, while TCP may only do it once across
multiple round trips.
Paragraph (version B):
QUIC starts a loss epoch when a packet is lost.  The loss epoch ends
when any packet sent after the start of the epoch is acknowledged.
TCP waits for the gap in the sequence number space to be filled, and
so if a segment is lost multiple times in a row, the loss epoch may
not end for several round trips.  Because both should reduce their
congestion windows only once per epoch, QUIC will do it once for
every round trip that experiences loss, while TCP may only do it once
across multiple round trips.
Draft: draft-ietf-quic-transport

Commentary: The description neglected to mention this . Obviously , the confidentiality protection ( specifically , the lack thereof ) is the part that needs to be highlighted , but we should n't neglect the other purpose of using an AEAD here .
Paragraph (version A):
Initial packets use an AEAD, the keys for which are derived using a
value that is visible on the wire.  Initial packets therefore do not
have effective confidentiality protection.  Initial protection exists
to ensure that the sender of the packet is on the network path.  Any
entity that receives an Initial packet from a client can recover the
keys that will allow them to both read the contents of the packet and
generate Initial packets that will be successfully authenticated at
either endpoint.
Paragraph (version B):
Initial packets use an AEAD, the keys for which are derived using a
value that is visible on the wire.  Initial packets therefore do not
have effective confidentiality protection.  Initial protection exists
to ensure that the sender of the packet is on the network path.  Any
entity that receives an Initial packet from a client can recover the
keys that will allow them to both read the contents of the packet and
generate Initial packets that will be successfully authenticated at
either endpoint.  The AEAD also protects Initial packets against
accidental modification.
Draft: draft-ietf-quic-transport

Commentary: For all packets . For all network paths . 
 You are right it 's not really incorrect , I just found it confusing giving potentially the impression that using multiple paths without CID is " easily " possible . How about this phrasing to be even more clear : " A zero - length Destination Connection ID field is used in all packets sent toward such an endpoint and this can not be changed even if the network path changes . " 
 Yes , good to call out this implicit exception .
Paragraph (version B):
An endpoint that selects a zero-length connection ID during the
handshake cannot issue a new connection ID.  A zero-length
Destination Connection ID field is used in all packets sent toward
such an endpoint over any network path.
Draft: draft-ietf-quic-transport

Commentary: There are three places which refer to " Section 9.3 of QUIC - TLS " . I think they should refer to " Section 9.5 of QUIC - TLS " . 
 Thanks !
Paragraph (version A):
A receiver MUST discard a newly unprotected packet unless it is
certain that it has not processed another packet with the same packet
number from the same packet number space.  Duplicate suppression MUST
happen after removing packet protection for the reasons described in
Section 9.3 of QUIC-TLS.
Paragraph (version B):
A receiver MUST discard a newly unprotected packet unless it is
certain that it has not processed another packet with the same packet
number from the same packet number space.  Duplicate suppression MUST
happen after removing packet protection for the reasons described in
Section 9.5 of QUIC-TLS.
Paragraph (version A):
Two bits (those with a mask of 0x0c) of byte 0 are reserved across
multiple packet types.  These bits are protected using header
protection; see Section 5.4 of QUIC-TLS.  The value included prior
to protection MUST be set to 0.  An endpoint MUST treat receipt of
a packet that has a non-zero value for these bits after removing
both packet and header protection as a connection error of type
PROTOCOL_VIOLATION.  Discarding such a packet after only removing
header protection can expose the endpoint to attacks; see
Section 9.3 of QUIC-TLS.
Paragraph (version B):
Two bits (those with a mask of 0x0c) of byte 0 are reserved across
multiple packet types.  These bits are protected using header
protection; see Section 5.4 of QUIC-TLS.  The value included prior
to protection MUST be set to 0.  An endpoint MUST treat receipt of
a packet that has a non-zero value for these bits after removing
both packet and header protection as a connection error of type
PROTOCOL_VIOLATION.  Discarding such a packet after only removing
header protection can expose the endpoint to attacks; see
Section 9.5 of QUIC-TLS.
Paragraph (version A):
The next two bits (those with a mask of 0x18) of byte 0 are
reserved.  These bits are protected using header protection; see
Section 5.4 of QUIC-TLS.  The value included prior to protection
MUST be set to 0.  An endpoint MUST treat receipt of a packet that
has a non-zero value for these bits, after removing both packet
and header protection, as a connection error of type
PROTOCOL_VIOLATION.  Discarding such a packet after only removing
header protection can expose the endpoint to attacks; see
Section 9.3 of QUIC-TLS.
Paragraph (version B):
The next two bits (those with a mask of 0x18) of byte 0 are
reserved.  These bits are protected using header protection; see
Section 5.4 of QUIC-TLS.  The value included prior to protection
MUST be set to 0.  An endpoint MUST treat receipt of a packet that
has a non-zero value for these bits, after removing both packet
and header protection, as a connection error of type
PROTOCOL_VIOLATION.  Discarding such a packet after only removing
header protection can expose the endpoint to attacks; see
Section 9.5 of QUIC-TLS.