jiebi/TextFlow huggingface dataset:
Original text:
Required Insert Count to determine when it is safe to process the rest of the block. <del> If no references are made to the dynamic table, a value of 0 is encoded.  Alternatively, where the Required Insert Count is greater than zero, the encoder transforms it as follows before encoding: </del>  Here "MaxEntries" is the maximum number of entries that the dynamic table can have.  The smallest entry has empty name and value strings

Reviewer comments:
This makes the encoding and decoding pseudo-code more symmetric. "Alternatively" might not be the best word here, because it might imply that the implementation has a choice. In a section about encoding Required Insert Count, it is more pure to talk about Required Insert Count being zero than to talk about whether references are made to the dynamic table.
Also, CI failed because the line is too long

Revised text:
Required Insert Count to determine when it is safe to process the rest of the block.  <ins> The encoder transforms the Required Insert Count as follows before encoding: </ins> Here "MaxEntries" is the maximum number of entries that the dynamic table can have.  The smallest entry has empty name and value strings
Original text:
Each header block contains a Required Insert Count, the lowest possible value for the Insert Count with which the header block can <del> be decoded.  For a header block with no references to the dynamic table, the Required Insert Count is zero. </del>  When the Required Insert Count is zero, the frame contains no references to the dynamic table and can always be processed becomes greater than or equal to the Required Insert Count for all header blocks the decoder has started reading from the stream. <del> If the decoder encounters a header block where the largest Absolute Index used is not equal to the largest value permitted by the Required Insert Count, it MAY treat this as a stream error of type HTTP_QPACK_DECOMPRESSION_FAILED. </del> The SETTINGS_QPACK_BLOCKED_STREAMS setting (see configuration) specifies an upper bound on the number of streams which can be blocked.  An encoder MUST limit the number of streams which could

Reviewer comments:
Currently the draft is inconsistent: if the Required Insert Count value in a header block is smaller than dictated by the referenced dynamic table entries, {{overview-hol-avoidance}} says the decoder MAY treat this as a stream error, while {{invalid-references}} says it MUST. This PR seeks to clarify this.

Revised text:
Each header block contains a Required Insert Count, the lowest possible value for the Insert Count with which the header block can  <ins> be decoded.  For a header block with references to the dynamic table, the Required Insert Count is one larger than the largest Absolute Index of all referenced dynamic table entries.  For a header block with no references to the dynamic table, the Required Insert Count is zero. If the decoder encounters a header block with a Required Insert Count value larger than defined above, it MAY treat this as a stream error of type HTTP_QPACK_DECOMPRESSION_FAILED.  If the decoder encounters a header block with a Required Insert Count value smaller than defined above, it MUST treat this as a stream error of type HTTP_QPACK_DECOMPRESSION_FAILED as prescribed in invalid-references. </ins> When the Required Insert Count is zero, the frame contains no references to the dynamic table and can always be processed becomes greater than or equal to the Required Insert Count for all header blocks the decoder has started reading from the stream.  The SETTINGS_QPACK_BLOCKED_STREAMS setting (see configuration) specifies an upper bound on the number of streams which can be blocked.  An encoder MUST limit the number of streams which could
Original text:
perform path validation (migrate-validate) if it detects a change in the IP address of its peer.  This document limits migration of connections to new client addresses, except as described in preferred-address.  Clients are responsible for initiating all migrations.  Servers do not send non- 10. <del> Connections should remain open until they become idle for a pre- negotiated period of time.  A QUIC connection, once established, can be terminated in one of three ways: </del>  idle timeout (idle-timeout) stateless reset (stateless-reset)  10.1. The closing and draining connection states exist to ensure that

Reviewer comments:
NAME this is annoyingly close to done. Would you mind?
NAME : Take a look.
LGTM

Revised text:
perform path validation (migrate-validate) if it detects a change in the IP address of its peer. <ins> When an endpoint has no validated path on which to send packets, it MAY discard connection state.  An endpoint capable of connection migration MAY wait for a new path to become available before discarding connection state. </ins> This document limits migration of connections to new client addresses, except as described in preferred-address.  Clients are responsible for initiating all migrations.  Servers do not send non- 10.  <ins> An established QUIC connection can be terminated in one of three ways: </ins> idle timeout (idle-timeout) stateless reset (stateless-reset) <ins> An endpoint MAY discard connection state if it does not have a validated path on which it can send packets (see migrate-validate). </ins> 10.1. The closing and draining connection states exist to ensure that
Original text:
implementer.  An implementation MUST ensure that the length of a frame exactly matches the length of the fields it contains.  10. 10.1.

Reviewer comments:
Separately from this, I note that Security Considerations is becoming more of a jumbled bag of waving at various concerns. Some organization and expanded text around each topic might be warranted.
Can you add a sub-heading(##) for each of these considerations, like in the transport draft? Originally posted by NAME in URL
Seems mostly right. Though I would prefer something that simply highlighted the fact that a remote address is not expected to be stable over the lifetime of a connection. Therefore, decisions that use an address as input need to either keep up to date, or accept the consequences of not doing so. I would also point out that this is true even if migration is disabled.The text looks great. I really appreciate the fact that we have a recommendation on what IP address we should associate with logging (and address-based authentication).

Revised text:
implementer.  An implementation MUST ensure that the length of a frame exactly matches the length of the fields it contains. <ins> Certain HTTP implementations use the client address for logging or access-control purposes.  Since a QUIC client's address might change during a connection (and future versions might support simultaneous use of multiple addresses), such implementations will need to either actively retrieve the client's current address or addresses when they are relevant or explicitly accept that the original address might change. </ins> 10. 10.1.
Original text:
stateless reset allows a peer to more quickly identify when a connection becomes unusable. <del> Packets that are matched to an existing connection, but for which the endpoint cannot remove packet protection, are discarded. </del>  Invalid packets without packet protection, such as Initial, Retry, or Version Negotiation, MAY be discarded.  An endpoint MUST generate a

Reviewer comments:
by discarding packets which are "inconsistent with the state of the connection." Previously, this was only a failure to remove packet protection; incorrect version is added as another example inconsistency. Note that this phrasing doesn't rule out upward-VN like , since receiving an expected upgrade is not inconsistent with your local state.
I'm wondering if there is a difference between failed decryption and version number. If the versions differ, it doesn't really make sense to try to read a subsequent coalesced packet, unless you want to do trial and error since the concepts of coalescing and length fields are not defined in the general case. Even if you understand the version, two version can not (or should not?) exist in the same datagram. If packet protection fails on the same version, it might just be a timing issue, or the (to me) dreaded path probe with prefixed knowingly invalid handshake.
That's an interesting question. The Length field is version-specific. If you include it, you can have no expectation that a peer which doesn't speak that version will even be able to find anything further in the datagram -- as far as it knows, the remainder of the datagram is that connection. But that actually has a potential use. On receipt, if the logic first attempts to chunk up the datagram and the subsequent packet is the correct version for the connection, then acknowledging that second coalesced packet implies that you support the first packet's version.

Revised text:
stateless reset allows a peer to more quickly identify when a connection becomes unusable.  <ins> Packets that are matched to an existing connection are discarded if the packets are inconsistent with the state of that connection.  For example, packets are discarded if they indicate a different protocol version than that of the connection, or if the removal of packet protection is unsuccessful once the expected keys are available. </ins> Invalid packets without packet protection, such as Initial, Retry, or Version Negotiation, MAY be discarded.  An endpoint MUST generate a
Original text:
fields, each of which has a fixed index over time.  Its entries are defined in static-table.  Note the QPACK static table is indexed from 0, whereas the HPACK static table is indexed from 1. an absolute index greater than or equal to the Base, the representation starts with the '0000' four-bit pattern.  The following bit, 'N', indicates whether an intermediary is permitted to add this header to the dynamic header table on subsequent hops.  When the 'N' bit is set, the encoded header MUST

Reviewer comments:
A couple of clarifications that can be useful to people who are looking at *PACK for the first time like myself. Not sure about the normative language though. I can reword it if necessary.
Let's see how handles it: We could simply add similar verbiage to Sections and 4.5.5. of the QPACK draft instead.
NAME I can add something like that, but TBH I don't think that the HPACK wording would have helped me, so I'd rather keep my clarification (that says "ignore value") as well.
This wording seems fine.

Revised text:
fields, each of which has a fixed index over time.  Its entries are defined in static-table. <ins> All entries in the static table have a name and a value.  However, values can be empty (that is, have a length of 0). </ins> Note the QPACK static table is indexed from 0, whereas the HPACK static table is indexed from 1. an absolute index greater than or equal to the Base, the representation starts with the '0000' four-bit pattern. <ins> Only the header field name stored in the static or dynamic table is used.  Any header field value MUST be ignored. </ins> The following bit, 'N', indicates whether an intermediary is permitted to add this header to the dynamic header table on subsequent hops.  When the 'N' bit is set, the encoded header MUST
Original text:
of the TLS handshake messages being integrated into the calculation of secrets, the inclusion of the QUIC transport parameters extension ensures that handshake and 1-RTT keys are not the same as those that <del> might be produced by a server running TLS over TCP.  However, 0-RTT keys only include the ClientHello message and might therefore use the same secrets.  To avoid the possibility of cross-protocol key synchronization, additional measures are provided to improve key separation. </del>  The QUIC packet protection keys and IVs are derived using a different label than the equivalent keys in TLS. To preserve this separation, a new version of QUIC SHOULD define new labels for key derivation for packet protection key and IV, plus the <del> header protection keys. </del>  <del> The initial secrets also use a key that is specific to the negotiated QUIC version.  New QUIC versions SHOULD define a new salt value used in calculating initial secrets. </del>  10.

Reviewer comments:
This includes the suggestion from NAME to remove the 0-RTT text. Plus some text explaining the choice of label.

Revised text:
of the TLS handshake messages being integrated into the calculation of secrets, the inclusion of the QUIC transport parameters extension ensures that handshake and 1-RTT keys are not the same as those that  <ins> might be produced by a server running TLS over TCP.  To avoid the possibility of cross-protocol key synchronization, additional measures are provided to improve key separation. </ins> The QUIC packet protection keys and IVs are derived using a different label than the equivalent keys in TLS. To preserve this separation, a new version of QUIC SHOULD define new labels for key derivation for packet protection key and IV, plus the  <ins> header protection keys.  This version of QUIC uses the string "quic". Other versions can use a version-specific label in place of that string. </ins>  <ins> The initial secrets use a key that is specific to the negotiated QUIC version.  New QUIC versions SHOULD define a new salt value used in calculating initial secrets. </ins> 10.
Original text:
size for every QUIC version it supports. The client populates the Source Connection ID field with a value of <del> its choosing and sets the SCIL field to match. </del>  The Destination Connection ID field in the server's Initial packet contains a connection ID that is chosen by the recipient of the On first receiving an Initial or Retry packet from the server, the client uses the Source Connection ID supplied by the server as the <del> Destination Connection ID for subsequent packets.  That means that a client might change the Destination Connection ID twice during connection establishment, once in response to a Retry and once in response to the first Initial packet from the server.  Once a client has received an Initial packet from the server, it MUST discard any packet it receives with a different Source Connection ID. </del>  A client MUST only change the value it sends in the Destination Connection ID in response to the first packet of each type it

Reviewer comments:
For and NAME
Thanks
Note that section 17.2.3. 0-RTT does not mention 0-RTT CID but the following section 7.2.4. Handshake Packet does mention Handshake CID's. In existing draft.
LGTM, given the incorporated changes.

Revised text:
size for every QUIC version it supports. The client populates the Source Connection ID field with a value of  <ins> its choosing and sets the SCIL field to indicate the length. The first flight of 0-RTT packets use the same Destination and Source Connection ID values as the client's first Initial. </ins> The Destination Connection ID field in the server's Initial packet contains a connection ID that is chosen by the recipient of the On first receiving an Initial or Retry packet from the server, the client uses the Source Connection ID supplied by the server as the  <ins> Destination Connection ID for subsequent packets, including any subsequent 0-RTT packets.  That means that a client might change the Destination Connection ID twice during connection establishment, once in response to a Retry and once in response to the first Initial packet from the server.  Once a client has received an Initial packet from the server, it MUST discard any packet it receives with a different Source Connection ID. </ins> A client MUST only change the value it sends in the Destination Connection ID in response to the first packet of each type it
Original text:
original_connection_id transport parameter if it sent a Retry packet. <del> The idle timeout is a value in seconds that is encoded as an </del>  integer, see (idle-timeout).  If this parameter is absent or zero then the idle timeout is disabled.

Reviewer comments:
This is fine, but I think that we want chairs to call it.
This falls under the new process, so it's upto the chairs.
Based on the discussion in I think this has rough consensus. Tagging as such and reassigning.
Slow down, we're not in the new process yet. And, in either case, consensus needs to be determined on-list, not in issues.
Currently, the t is in units of seconds. This seems to be too restrictive and not very future proof. Additionally, from an API perspective, most other timers are settable on the millisecond scale, so it creates a kind of ugly discrepancy between all the different timers settable by the app if just one of them has units of seconds. I propose we change the units from seconds to milliseconds. The change both for implementations and spec should be minimal, and it makes things (timers) a little more consistent.
This seems sensible to me both for consistency and I can imagine cases when one would want to specify a fraction(ie: 1/2 of a second).
Agreed. A second is an eternity for a intra-datacenter connection for example. For future proofing all time units should be at least msec IMO.
Don't we want to specify a minimum value now?
No, I don't think so. Even before, if you had a greater than 1 sec RTT (somehow...) if you set an idle timeout of 1 second it would cause you problems. I think bottom line you be smart about your idle timeout values. If you set too small a value you can unnecessarily kill your own connection.
As NAME says, actual idle timeout depends on RTT, and that’s what we have adopted in .
This SGTM.
I support this
I think this has rough consensus. Tagging as such and reassigning.
LG, but I don't know what process this falls under. I'll let NAME and NAME decide.

Revised text:
original_connection_id transport parameter if it sent a Retry packet.  <ins> The idle timeout is a value in milliseconds that is encoded as an </ins> integer, see (idle-timeout).  If this parameter is absent or zero then the idle timeout is disabled.
Original text:
acknowledgement is received, a new RTT is computed and the timer SHOULD be set for twice the newly computed smoothed RTT. <del> When crypto packets are sent, the sender MUST set a timer for the crypto timeout period.  Upon timeout, the sender MUST retransmit all </del>  unacknowledged CRYPTO data if possible. Until the server has validated the client's address on the path, the

Reviewer comments:
From reading the text, it was not clear that the timer is set based on the last (and not the first) crypto packet sent.
LGTM. I've reworded a bit.

Revised text:
acknowledgement is received, a new RTT is computed and the timer SHOULD be set for twice the newly computed smoothed RTT.  <ins> When a crypto packet is sent, the sender MUST set a timer for the crypto timeout period.  This timer MUST be updated when a new crypto packet is sent.  Upon timeout, the sender MUST retransmit all </ins> unacknowledged CRYPTO data if possible. Until the server has validated the client's address on the path, the
Original text:
connection is in the draining state. An endpoint MAY transition from the closing period to the draining <del> period if it can confirm that its peer is also closing or draining. Receiving a CONNECTION_CLOSE frame is sufficient confirmation, as is receiving a stateless reset.  The draining period SHOULD end when the closing period would have ended.  In other words, the endpoint can use the same end time, but cease retransmission of the closing packet. </del>  Disposing of connection state prior to the end of the closing or draining period could cause delayed or reordered packets to be

Reviewer comments:
This doesn't seem implementable without a list of all the things that were sufficient.
That is the list. If you think it should be reworded, I'm happy to take a PR.

Revised text:
connection is in the draining state. An endpoint MAY transition from the closing period to the draining  <ins> period if it receives a CONNECTION_CLOSE frame or stateless reset, both of which indicate that the peer is also closing or draining. The draining period SHOULD end when the closing period would have ended.  In other words, the endpoint can use the same end time, but cease retransmission of the closing packet. </ins> Disposing of connection state prior to the end of the closing or draining period could cause delayed or reordered packets to be
Original text:
4.2.3. <del> The PRIORITY (type=0x02) frame specifies the client-advised priority </del>  of a request, server push or placeholder. A PRIORITY frame identifies an element to prioritize, and an element 4.2.6. <del> The PUSH_PROMISE frame (type=0x05) is used to carry a promised request header set from server to client on a request stream, as in HTTP/2. </del>  The payload consists of:

Reviewer comments:
Simply making this consistent through the document by doing the minimal change and removing leading 0s. Happy to add them if we prefer.
Works for me.

Revised text:
4.2.3.  <ins> The PRIORITY (type=0x2) frame specifies the client-advised priority </ins> of a request, server push or placeholder. A PRIORITY frame identifies an element to prioritize, and an element 4.2.6.  <ins> The PUSH_PROMISE frame (type=0x5) is used to carry a promised request header set from server to client on a request stream, as in HTTP/2. </ins> The payload consists of: