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

Commentary: Section 4.1.2 : Although this is summary of the definition in HPACK , where this issue is clear I think this document should describe things corretly . HPACK defines string literals to begin on a byte boundary . They begin with a single bit flag , denoted as ' H ' in this document ( indicating whether the string is Huffman - coded ) , followed by the  encoded as a 7 - bit prefix integer , and finally  bytes of data . When  encoding is enabled , the  table from Appendix B of [ RFC7541 ] is used without modification . The length field as described here , provides an uncertainty if it is the data pre huffman ( if applied ) encoding or post encoding . HPACK is clear that it is the later . Can you please clarify that the length if the length of the encoded string that is encoded using N - bit prefix integer encoding . " An " N - bit prefix string literal " begins with the same  flag , followed by the length encoded as an ( N-1)-bit prefix integer . " This definition if it is the byte or the prefix field that begins with the huffman flag . I would guess that what is meant is that a 6 - bit prefix string literal would have a start byte of " ? ? Hxxxxx " rather than " H??xxxxx " . 
 This would be an " editorial " change . 
 Yes , the latter is correct . A prefixed string literal does not begin on a byte boundary ; the first bit ( when it begins ) is the Huffman bit , and the remainder is a prefixed integer .
Paragraph (version A):
HPACK defines string literals to begin on a byte boundary.  They
begin with a single bit flag, denoted as 'H' in this document
(indicating whether the string is Huffman-coded), followed by the
Length encoded as a 7-bit prefix integer, and finally Length bytes of
data.  When Huffman encoding is enabled, the Huffman table from
Appendix B of RFC7541 is used without modification.
Paragraph (version A):
This document expands the definition of string literals by permitting
them to begin other than on a byte boundary.  An "N-bit prefix string
literal" begins with the same Huffman flag, followed by the length
encoded as an (N-1)-bit prefix integer.  The prefix size, N, can have
a value between 2 and 8 inclusive.  The remainder of the string
literal is unmodified.
Paragraph (version B):
HPACK defines string literals to begin on a byte boundary.  They
begin with a single bit flag, denoted as 'H' in this document
(indicating whether the string is Huffman-coded), followed by the
Length encoded as a 7-bit prefix integer, and finally Length bytes of
data.  When Huffman encoding is enabled, the Huffman table from
Appendix B of RFC7541 is used without modification and Length
indicates the size of the string after encoding.
Paragraph (version B):
This document expands the definition of string literals by permitting
them to begin other than on a byte boundary.  An "N-bit prefix string
literal" begins mid-byte, with the first (8-N) bits allocated to a
previous field.  The string uses one bit for the Huffman flag,
followed by the Length encoded as an (N-1)-bit prefix integer.  The
prefix size, N, can have a value between 2 and 8 inclusive.  The
remainder of the string literal is unmodified.
Draft: draft-ietf-quic-http

Commentary: Taken from suggestion on the list . 
 On the mailing list raised a question about pseudo - headers . That discussion seemed to identify that HTTP/3 oversteps the mark by saying that psuedo - headers are extensible . We can make an editorial change to bring this back to something equivalent to what RFC 7540 says . See . 
 Conversation evolved , I''ve created a PR that takes  's suggestion .
Paragraph (version A):
Pseudo-header fields are not HTTP fields.  Endpoints MUST NOT
generate pseudo-header fields other than those defined in this
document, except as negotiated via an extension; see extensions.
Paragraph (version B):
Pseudo-header fields are not HTTP fields.  Endpoints MUST NOT
generate pseudo-header fields other than those defined in this
document; however, an extension could negotiate a modification of
this restriction; see extensions.
Draft: draft-ietf-quic-qpack

Commentary: Section 1.1 : HTTP field line : A name - value pair sent as part of an HTTP field section . See Section 5 of [ SEMANTICS ] . I would guess that this can be refined to point to section 5.4 . 
 Proposed change is " editorial " .
Paragraph (version A):
A name-value pair sent as part of an HTTP field section.  See
Section 5 of SEMANTICS.
Paragraph (version B):
A name-value pair sent as part of an HTTP field section.  See
Section 5.4 and Section 5.6 of SEMANTICS.
Draft: draft-ietf-quic-http

Commentary: At suggestion this adds a " change controller " field to registries and splits between a change controller ( IETF ) and contact ( QUIC WG ) . Not really sure if this is worth a design label ... 
 Section 22.1.1 : It is quite common that one may want to separate who has the change control over an registration entry vs who is the contact . Change control can often be assigned to an organization rather than an individual while a contact information may be an individual or a specific contact address for the organization . Contact information has a tendency to get stale , and in many case the contact if a person may no longer represent the organization that made the registration . Thus , my suggestion would be to add a separation between contact and change controller . In fact just for the registration in the Transport doc it makes sense to make the change controller " IETF " and have the contact be " QUIC WG " . 
 This also applies to permanent registrations in Section 22.1.4 
 does the PR address your issue ? 
 Change looks good and implements what I proposed . 
 Labeling as " editorial " based on
Paragraph (version A):
The initial allocations in these registries created in this document
are all assigned permanent status and list as contact both the IETF
and the HTTP working group (ietf-http-wg@w3.org).
Paragraph (version B):
The initial allocations in these registries created in this document
are all assigned permanent status and list a change controller of the
IETF and a contact of the HTTP working group (ietf-http-wg@w3.org).
Paragraph (version B):
The entity that is responsible for the definition of the
registration.
Paragraph (version A):
All registrations in this document are assigned a permanent status
and list as contact the IETF (quic@ietf.org).
Paragraph (version B):
All registrations in this document are assigned a permanent status
and list a change controller of the IETF and a contact of the QUIC
working group (quic@ietf.org).
Draft: draft-ietf-quic-http

Commentary: see . 
 Section 11.2 : " The initial allocations in these registries created in this document are all assigned permanent status and list as contact both the IESG ( ) and the HTTP working group ( ietf - http- ) . " From my perspective it is better to have IETF as change controller . In practice that would mean that any chartered WG to work on this registry would by completing the IETF process be allowed to introduce changes to the registry . Having HTTP Working Group as contact is fine . So I would propose to change this to : " The initial allocations in these registries created in this document are all assigned permanent status and list as change controller the IETF and the HTTP working group ( ietf - http- ) as contact . "
Paragraph (version A):
The initial allocations in these registries created in this document
are all assigned permanent status and list as contact both the IESG
(iesg@ietf.org) and the HTTP working group (ietf-http-wg@w3.org).
Paragraph (version B):
The initial allocations in these registries created in this document
are all assigned permanent status and list as contact both the IETF
and the HTTP working group (ietf-http-wg@w3.org).
Draft: draft-ietf-quic-http

Commentary: In Section 7.2.3 : A server SHOULD send a CANCELPUSH frame even if it has opened the corresponding stream . Is the intention that this sentence should have this meaning ? " A server that has opened a stream for a PUSH and is unable to fulfill this promise SHOULD send a CANCEL_PUSH frame with the corresponding  ID . " I think as currently formulated it is missing the criteria as well when this may occur . Secondly the alternative is also not clear . I assume this is a SHOULD as the stream can be reset with an error code ? Does that need to be and which error will be used ? Especially as the next paragraph only discusses that the client SHOULD abort reading . Ca n't the server terminate the stream from its side ? If only the later is allowed , I think that should be made explicit but appears unnecessary . 
 To the second question , stating clearly that the server can abort the  stream with H3REQUESTCANCELLED seems like a good improvement . 
 Looking at the larger paragraph , the point is that there are two possible states when a server decides not to fulfill a push : a. No stream has been created ; CANCELPUSH is sufficient . b. A stream has been created . The server could simply reset the stream ; this is valid , but risks the client processing the RESET before learning the Push ID , so it wo n't know which  ID is no longer being fulfilled . Better if the server both resets the stream and sends a CANCELPUSH . You 're right that this could be reworded to emphasize that you always send CANCEL_PUSH if you 're not fulfilling a promise , and also close the stream if you 've opened one . 
 This seems like the right framing . But everything seems to correspond .
Paragraph (version A):
When a server sends CANCEL_PUSH, it is indicating that it will not be
fulfilling a promise.  The client cannot expect the corresponding
promise to be fulfilled, unless it has already received and processed
the promised response.  A server SHOULD send a CANCEL_PUSH frame even
if it has opened the corresponding stream.
Paragraph (version B):
A server sends CANCEL_PUSH to indicate that it will not be fulfilling
a promise which was previously sent.  The client cannot expect the
corresponding promise to be fulfilled, unless it has already received
and processed the promised response.  Regardless of whether a push
stream has been opened, a server SHOULD send a CANCEL_PUSH frame when
it determines that promise will not be fulfilled.  If a stream has
already been opened, the server can abort sending on the stream with
an error code of H3_REQUEST_CANCELLED.
Draft: draft-ietf-quic-http

Commentary: Text was already given the thumbs - up on the issue , so merging without waiting for review . 
 Section 3.2.2 states : " Prior to making requests for an origin whose scheme is not "  " , the client MUST ensure the server is willing to serve that scheme . If the client intends to make requests for an origin whose scheme is " http " , this means that it MUST obtain a valid http - opportunistic response for the origin as described in [ RFC8164 ] prior to making any such requests . Other schemes might define other mechanisms . " The first issue is that this text make normative use of RFC8164 to handle " http " scheme .  is an experimental RFC . Thus we have a downref issue . I think it would be inappropriate to elevate RFC8164 status by allowing a downref here . I think one option would be to move the specification of the usage of RFC 8164 for the " http " URI scheme in HTTP/3 into its own experimental RFC . Another potential option is to simply inform about the ongoing experiment without specifying that it can be done with HTTP/3 . Secondly , I am uncertain about the scope of the first sentence in that paragraph . Is there any other URI schemes other than " http " that this is applicable for ? If it is which type of URI schemes is it applicable for ? For clearly it is not applicable to the " rtsp " scheme that is n't using HTTP at all . 
 Second point first : HTTP does n't restrict the scheme of URIs a client can request ; URI schemes define what protocols can be used to access them , which might or might not include HTTP . For example ,  says : " : scheme " is not restricted to " http " and "  " schemed URIs . A proxy or gateway can translate requests for non - HTTP schemes , enabling the use of HTTP to interact with non - HTTP services . To the first point , I feel like not mentioning that RFC8164 can be done with HTTP/3 means it 's irrelevant to include in this document , and the requirement to verify the peer can serve a scheme is necessary . Perhaps something like : 
 The proposed text looks good . I think that resolves it and you can move RFC8164 to be a informational ref . So I think this resolves my issue . 
 Based on this resolution , labeling this as " editorial "
Paragraph (version A):
Prior to making requests for an origin whose scheme is not "https",
the client MUST ensure the server is willing to serve that scheme.
If the client intends to make requests for an origin whose scheme is
"http", this means that it MUST obtain a valid "http-opportunistic"
response for the origin as described in RFC8164 prior to making any
such requests.  Other schemes might define other mechanisms.
Paragraph (version B):
Prior to making requests for an origin whose scheme is not "https",
the client MUST ensure the server is willing to serve that scheme.
For origins whose scheme is "http", an experimental method to
accomplish this is described in RFC8164.  Other mechanisms might be
defined for various schemes in the future.
Draft: draft-ietf-quic-recovery

Commentary: That term does n't appear above , so do n't use it in the PTO section . 
 Thanks I took your suggestions with one tweak . 
 Section 6.2.1 : " The probe timer MUST NOT be set if the time threshold ( Section 6.1.2 ) loss detection timer is set . The time threshold loss detection timer is expected to both expire earlier than the PTO and be less likely to spuriously retransmit data . " What does " MUST NOT be set " means . The time threshold loss detection 6.1.2 only occurs if there is acknowledgement received by the sender sufficient late after the transmission . Thus , PTO timer needs to always be set . because even if Time Threshold timer fires it might not declare a loss . 
 It means if the time threshold timer is armed , you are not supposed to arm the PTO timer . If the Time Threshold timer fires and does n't declare a loss , then I would consider that a bug . 
 So the above text about loss timer is only when one are under the condition created by this Section 6.1.2 sentence ? " If packets sent prior to the largest acknowledged packet can not yet be declared lost , then a timer SHOULD be set for the remaining time . " Does the formulation in 6.1.2 need to be improved , possibly naming the timer ? 
 I can see the confusion . This can either be a single timer or multiple , and sometimes we refer to it one way and sometimes as separately named timers , ie " The time threshold loss detection timer " We can either be more consistent about naming the timers or stop naming the timers entirely . Would you prefer the former ? 
 Frankly I do n't know which direction that is best . Could I ask you to take an editorial stab on your most preferred . I would guess when you sit down to do either you realize if it will work or not when you harmonize it . 
 Does PR resolve this for you ? 
 we 'd need a response , please 
 Yes , that simple tweak do make it clearer . So resolved . 
 The second suggestion is a little risky , but avoids a slightly awkward construction . Editorial suggestion . I 'm fine with merging this , but should probably see if it addresses his issue .
Paragraph (version A):
The probe timer MUST NOT be set if the time threshold (time-
threshold) loss detection timer is set.  The time threshold loss
detection timer is expected to both expire earlier than the PTO and
be less likely to spuriously retransmit data.
Paragraph (version B):
The PTO timer MUST NOT be set if a timer is set for time threshold
loss detection; see time-threshold.  A timer that is set for time
threshold loss detection will expire earlier than the PTO timer in
most cases and is less likely to spuriously retransmit data.
Draft: draft-ietf-quic-recovery

Commentary: If you receive a handshake ACK , then the server has validated the client 's address , so it 's really only Initial ACKs . 
 I think this is good . 
 There is an inconsistency in w.r.t . resetting PTO backoff factor . Section 6.2.1 : This suggests that for a client to be certain that the server has finished validating the client 's address , the handshake should have been confirmed . However , the pseudo code uses PeerCompletedAddressValidation to determine whether to reset pto - count and PeerCompletedAddressValidation also checks for Handshake ACK received . That is not what the text in 6.2.1 says , as , according to , the handshake is confirmed when HANDSHAKEDONE is received or when a 1 - RTT ack is received . That is a subtle difference . As kazu noted in the discussion on Slack , Sec 8.1 of QUIC says : " Once the server has successfully processed a Handshake packet from the client , it can consider the client address to have been validated . " , so , the client can consider that the server validated the client address when either ACK in Handshake or HANDSHAKEDONE in 1 - RTT is received . ( See Figure 5 of TLS . ) Hence , the pseudocode seems to be correct and that means the text in 6.2.1 should be corrected . 
 Thanks for filing this , I think the new text is simpler anyway .
Paragraph (version A):
When a PTO timer expires, the PTO backoff MUST be increased,
resulting in the PTO period being set to twice its current value.
The PTO backoff factor is reset when an acknowledgement is received,
except in the following case.  A server might take longer to respond
to packets during the handshake than otherwise.  To protect such a
server from repeated client probes, the PTO backoff is not reset at a
client that is not yet certain that the server has finished
validating the client's address.  That is, a client does not reset
the PTO backoff factor on receiving acknowledgements until the
handshake is confirmed; see Section 4.1.2 of QUIC-TLS.
Paragraph (version B):
When a PTO timer expires, the PTO backoff MUST be increased,
resulting in the PTO period being set to twice its current value.
The PTO backoff factor is reset when an acknowledgement is received,
except in the following case.  A server might take longer to respond
to packets during the handshake than otherwise.  To protect such a
server from repeated client probes, the PTO backoff is not reset at a
client that is not yet certain that the server has finished
validating the client's address.  That is, a client does not reset
the PTO backoff factor on receiving acknowledgements in Initial
packets.
Draft: draft-ietf-quic-recovery

Commentary: Section 7.6.1 : The RECOMMENDED value for kPersistentCongestionThreshold is 3 , which is approximately equivalent to two TLPs before an RTO in TCP . Any values that needs to be explicitly forbidden ? For example does it need a sentence saying that it MUST be larger than X ? I would think that 1 would be to low and allow slow start after just one RTT+variations ? I understand that likely would give the application bad behavior but likely also have negative impact on other applications if the QUIC stack ends up doing slow start crashing into the wall and then slow starting again ? 
 I lean towards not being overly proscriptive here . We could elaborate on the pros and cons of smaller and larger values if you think that is necessary ? Exponential backoff is clearly critical , but it 's less clear to me that the CWND really needs to be collapsed in these situations . 
 I am really just trying to asses if there are significant risks with any specific ranges of values . For example causing very bursty behavior that could be considered harmful or becoming extremely aggressive after a persistent congestion event , in those cases some text may be necessary . 
 Based on , labeling this as " editorial " 
 Thinks this resolve my issue , but would prefer  's proposal .
Paragraph (version A):
The RECOMMENDED value for kPersistentCongestionThreshold is 3, which
is approximately equivalent to two TLPs before an RTO in TCP.
Paragraph (version B):
Larger values of kPersistentCongestionThreshold cause the sender to
become less responsive to persistent congestion in the network, which
can result in aggressive sending into a congested network.  Too small
a value can result in a sender declaring persistent congestion
unnecessarily, resulting in reduced throughput for the sender.
Paragraph (version B):
The RECOMMENDED value for kPersistentCongestionThreshold is 3, which
results in behavior that is approximately equivalent to a TCP sender
declaring an RTO after two TLPs.
Draft: draft-ietf-quic-tls

Commentary: This could have been more explicit , so now it is . Doubly so . 
 Section 5.4.1 , Figure 6 : mask = headerprotection(hpkey , sample ) I think it is a bit unclear that the headerprotection function is what is producing the stream cipher cipher text that will be masked and xored with the header bits . Especially as the instantiations of these functions for AESGCM ( Section 5.4.3 ) and ChaCha20 ( Section 5.4.4 ) is not defined as instantiation of that function , only as providing the same variable output . I think this could be clarified in both places so that the linkage between the general application and the stream cipher producing function is clear . 
 Looks good and resolve my issue . 
 indubitably
Paragraph (version B):
Specific header protection functions are defined based on the
selected cipher suite; see hp-aes and hp-chacha.