jiebi/TextFlow huggingface dataset:
Original text:
If the packet is from a new encryption level, it is saved for later processing by TLS.  Once TLS moves to receiving from this <del> encryption level, saved data can be provided to TLS.  When providing data from any new encryption level to TLS, if there is data from a previous encryption level that TLS has not consumed, this MUST be treated as a connection error of type PROTOCOL_VIOLATION. </del>  Each time that TLS is provided with new data, new handshake bytes are requested from TLS.  TLS might not provide any bytes if the handshake

Reviewer comments:
This check really is triggered by TLS providing new keys, not QUIC delivering data on a higher encryption level. Otherwise, in the case where no session ticket is sent, this condition would go undetected for unconsumed data at the Handshake encryption level.

Revised text:
If the packet is from a new encryption level, it is saved for later processing by TLS.  Once TLS moves to receiving from this  <ins> encryption level, saved data can be provided to TLS.  When TLS provides keys for a higher encryption level, if there is data from a previous encryption level that TLS has not consumed, this MUST be treated as a connection error of type PROTOCOL_VIOLATION. </ins> Each time that TLS is provided with new data, new handshake bytes are requested from TLS.  TLS might not provide any bytes if the handshake
Original text:
expiration, as TCP does with Tail Loss Probes (RACK) and a Retransmission Timeout (RFC5681).  The RECOMMENDED value for kPersistentCongestionThreshold is 3, which <del> is approximately equivalent to two TLPs before an RTO in TCP. </del>  This design does not use consecutive PTO events to establish persistent congestion, since application patterns impact PTO

Reviewer comments:
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 Ian's proposal.

Revised text:
expiration, as TCP does with Tail Loss Probes (RACK) and a Retransmission Timeout (RFC5681). <ins> 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. </ins> The RECOMMENDED value for kPersistentCongestionThreshold is 3, which  <ins> results in behavior that is approximately equivalent to a TCP sender declaring an RTO after two TLPs. </ins> This design does not use consecutive PTO events to establish persistent congestion, since application patterns impact PTO
Original text:
The total length of time over which consecutive PTOs expire is limited by the idle timeout. <del> 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. </del>  6.2.2.

Reviewer comments:
That term doesn't appear above, so don't use it in the PTO section.
Thanks NAME 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 doesn'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 cannot 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 don'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.
NAME Does PR resolve this for you?
NAME 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 NAME should probably see if it addresses his issue.

Revised text:
The total length of time over which consecutive PTOs expire is limited by the idle timeout.  <ins> 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. </ins> 6.2.2.
Original text:
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 <del> Section 9.3 of QUIC-TLS. </del>  Endpoints that track all individual packets for the purposes of detecting duplicates are at risk of accumulating excessive state.

Reviewer comments:
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!

Revised text:
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  <ins> Section 9.5 of QUIC-TLS. </ins> Endpoints that track all individual packets for the purposes of detecting duplicates are at risk of accumulating excessive state.
Original text:
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 <del> Section 9.3 of QUIC-TLS. </del>  In packet types that contain a Packet Number field, the least significant two bits (those with a mask of 0x03) of byte 0 contain

Reviewer comments:
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!

Revised text:
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  <ins> Section 9.5 of QUIC-TLS. </ins> In packet types that contain a Packet Number field, the least significant two bits (those with a mask of 0x03) of byte 0 contain
Original text:
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 <del> Section 9.3 of QUIC-TLS. </del>  The next bit (0x04) of byte 0 indicates the key phase, which allows a recipient of a packet to identify the packet protection

Reviewer comments:
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!

Revised text:
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  <ins> Section 9.5 of QUIC-TLS. </ins> The next bit (0x04) of byte 0 indicates the key phase, which allows a recipient of a packet to identify the packet protection
Original text:
has received this parameter SHOULD NOT send an HTTP message header that exceeds the indicated size, as the peer will likely refuse to process it.  However, an HTTP message can traverse one or more <del> intermediaries (see Section 3.7 of SEMANTICS) before reaching the origin server.  Because this limit is applied separately by each </del>  implementation which processes the message, messages below this limit are not guaranteed to be accepted.

Reviewer comments:
Fixes several nits from the gen-art review, which basically all come down to defining terms appropriately and/or referencing their definitions. modifies definition of "stream" and "stream error"; pulls in more terms from SEMANTICS references SEMANTICS for definition of fields rewords to avoid the term "hop" and describes intermediation more explicitly rewords to avoid saying "not possible" and copies language from SEMANTICS advising against retries updates reference to definition of CONNECT in SEMANTICS. NAME your review would be appreciated.
In the HTTP genart review, NAME writes:
Yes, CONNECT only supports TCP, and there's no short-term plan to change that. There is separate relevant work such as but I don't think we need to change anything in the draft here - it pretty clearly mentions TCP so I don't see any ambiguity.
This question should be addressed by the definition of CONNECT the spec is referring to. It's worth double-checking the references in that section, though; it points to HTTP11, when I think there should be a definition in SEMANTICS.
In the HTTP genart review, NAME writes:
Presumably a reference into SEMANTICS; I'll look for the right section to point to.
In the HTTP genart review, NAME writes:
In the HTTP genart review, NAME writes:
In the HTTP genart review, NAME writes: "HTTP/3 stream". Perhaps it's worth defining "HTTP/3 stream" explicitly, in analogy to "HTTP/3 connection". Perhaps it's worth defining "message", too (this is only an HTTP concept, correct?). The document should make sure it clearly distinguishes terms and concept of QUIC vs. of HTTP/3 in all cases. In particular, what is the relationship between HTTP/3 frames and QUIC frames? It's important to make their difference and relationship explicit, as the document uses several other terms interchangeably between HTTP/3 and QUIC, like "connection" and perhaps "stream".
A few minor suggestions, but this is a good change.This looks good to me, thanks!

Revised text:
has received this parameter SHOULD NOT send an HTTP message header that exceeds the indicated size, as the peer will likely refuse to process it.  However, an HTTP message can traverse one or more  <ins> intermediaries before reaching the origin server; see Section 3.7 of SEMANTICS.  Because this limit is applied separately by each </ins> implementation which processes the message, messages below this limit are not guaranteed to be accepted.
Original text:
negotiating-connection-ids describes the use of this field in more detail.  In this version of QUIC, the following packet types with the long header are defined:

Reviewer comments:
Minor nit while looking at ; the definition of generic "Long-Header Packets" won'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 (URL). 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.

Revised text:
negotiating-connection-ids describes the use of this field in more detail. <ins> The remainder of the packet, if any, is type-specific. </ins> In this version of QUIC, the following packet types with the long header are defined:
Original text:
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 <del> to access those entries, then the state of the table can be learned. </del>  Having requests or responses from mutually distrustful entities occurs when an intermediary either:

Reviewer comments:
I think this helps?
Magnus Nystrom : 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.
NAME so are you proposing any changes to the text?

Revised text:
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  <ins> 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. </ins> Having requests or responses from mutually distrustful entities occurs when an intermediary either:
Original text:
1. <del> QUIC is a new multiplexed and secure transport protocol atop UDP, specified in QUIC-TRANSPORT.  This document describes congestion control and loss recovery for QUIC.  Mechanisms described in this document follow the spirit of existing TCP congestion control and loss recovery mechanisms, described in RFCs, various Internet-drafts, or academic papers, and also those prevalent in TCP implementations. </del>  2.

Reviewer comments:
In the Recovery genart review, Vijay Gurbani wrote:
Based on the proposed PR, I'm marking this as editorial.
In the Recovery genart review, Vijay Gurbani wrote:
Based on the proposed PR, I'm marking this as editorial.

Revised text:
1.  <ins> QUIC is a secure general-purpose transport protocol, described in QUIC-TRANSPORT).  This document describes loss detection and congestion control mechanisms for QUIC. </ins> 2.
Original text:
4.2. TCP conflates transmission order at the sender with delivery order at <del> the receiver, which results in retransmissions of the same data carrying the same sequence number, and consequently leads to "retransmission ambiguity".  QUIC separates the two.  QUIC uses a packet number to indicate transmission order.  Application data is sent in one or more streams and delivery order is determined by stream offsets encoded within STREAM frames. </del>  QUIC's packet number is strictly increasing within a packet number space, and directly encodes transmission order.  A higher packet

Reviewer comments:
In the Recovery genart review, Vijay Gurbani wrote:
Based on the proposed PR, I'm marking this as editorial.
In the Recovery genart review, Vijay Gurbani wrote:
Based on the proposed PR, I'm marking this as editorial.

Revised text:
4.2. TCP conflates transmission order at the sender with delivery order at  <ins> the receiver, resulting in the retransmission ambiguity problem (RETRANSMISSION).  QUIC separates transmission order from delivery order: packet numbers indicate transmission order, and delivery order is determined by the stream offsets in STREAM frames. </ins> QUIC's packet number is strictly increasing within a packet number space, and directly encodes transmission order.  A higher packet
Original text:
The initial contents of this registry are shown in iana-tp-table. <del> Additionally, each value of the format "31 * N + 27" for integer values of N (that is, 27, 58, 89, ...) are reserved and MUST NOT be assigned by IANA. </del>  22.3.

Reviewer comments:
IANA's review wanted to know whether the 148 quadrillion GREASE values should be listed on the registry page as Reserved, and what note should be present if not. They should not, lest it be challenging to actually download the registry page within the lifetime of the human race. This rewords the restriction and clarifies that the restriction should be the note.
NAME Can you add the same text to 22.2 (Transport parameter registry) in the transport doc as well?
NAME said
We believe the note, updated based on IANA feedback during Last Call, is sufficient. Reserving 148 quadrillion values in the registry would cause the registry to be impossible to download in the lifetime of humanity; see . The purpose is described in , to exercise the requirement to ignore unknown frame types (a.k.a. GREASE). Proposal is to make no change; this was already covered during IANA review.
If IANA has agreed, then I am fine with it. BTW, I was not asking to make those zillions of reservations but leaving a note in the registry ;-)
It's a fair question but the WG and the responsible AD are satisfied with our IANA considerations at this stage, closing with no action.
Please see the for full context. This issue is tracking the following IANA question:
Copying my e-mail reply here: unknown values; having an explicit list encourages an explicitly defined reaction. This also applies to and , where the latter has better wording.
NAME replied to IANA . Closing this issue.
Actually, NAME said in response to the e-mail that this guidance should be in the document: Let's re-open to track. I don't think all instances of this question need separate issues, though.
So the related questions were: Should the GREASE values be listed in the registry as Reserved? No, because some rough estimation suggests it would take a few millennia to download the registry page if this were the case. Should there be a note indicating which values cannot be assigned? I'm of two minds, because while I really don't want people embedding the formula into their parsers, I do want people embedding the formula into their generators. says no Reserved listing, yes note.
I think this is proposal ready. Forwarding Mike's response to the list, to there is an archive to link to. Lars >


Revised text:
The initial contents of this registry are shown in iana-tp-table.  <ins> Each value of the format "31 * N + 27" for integer values of N (that is, 27, 58, 89, ...) are reserved; these values MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. </ins> 22.3.
Original text:
The entries in iana-frame-table are registered by this document. <del> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, 0x21, 0x40, ..., through 0x3FFFFFFFFFFFFFFE) MUST NOT be assigned by IANA. </del>  11.2.2.

Reviewer comments:
IANA's review wanted to know whether the 148 quadrillion GREASE values should be listed on the registry page as Reserved, and what note should be present if not. They should not, lest it be challenging to actually download the registry page within the lifetime of the human race. This rewords the restriction and clarifies that the restriction should be the note.
NAME Can you add the same text to 22.2 (Transport parameter registry) in the transport doc as well?
NAME said
We believe the note, updated based on IANA feedback during Last Call, is sufficient. Reserving 148 quadrillion values in the registry would cause the registry to be impossible to download in the lifetime of humanity; see . The purpose is described in , to exercise the requirement to ignore unknown frame types (a.k.a. GREASE). Proposal is to make no change; this was already covered during IANA review.
If IANA has agreed, then I am fine with it. BTW, I was not asking to make those zillions of reservations but leaving a note in the registry ;-)
It's a fair question but the WG and the responsible AD are satisfied with our IANA considerations at this stage, closing with no action.
Please see the for full context. This issue is tracking the following IANA question:
Copying my e-mail reply here: unknown values; having an explicit list encourages an explicitly defined reaction. This also applies to and , where the latter has better wording.
NAME replied to IANA . Closing this issue.
Actually, NAME said in response to the e-mail that this guidance should be in the document: Let's re-open to track. I don't think all instances of this question need separate issues, though.
So the related questions were: Should the GREASE values be listed in the registry as Reserved? No, because some rough estimation suggests it would take a few millennia to download the registry page if this were the case. Should there be a note indicating which values cannot be assigned? I'm of two minds, because while I really don't want people embedding the formula into their parsers, I do want people embedding the formula into their generators. says no Reserved listing, yes note.
I think this is proposal ready. Forwarding Mike's response to the list, to there is an archive to link to. Lars >


Revised text:
The entries in iana-frame-table are registered by this document.  <ins> Each code of the format "0x1f * N + 0x21" for non-negative integer values of N (that is, 0x21, 0x40, ..., through 0x3FFFFFFFFFFFFFFE) MUST NOT be assigned by IANA and MUST NOT appear in the listing of assigned values. </ins> 11.2.2.