jiebi/TextFlow huggingface dataset:
Original text:
enc-request. request describes the process for constructing and processing an Encapsulated Request.  Responses are bound to responses and so consist only of AEAD- protected content.  response describes the process for constructing and processing an Encapsulated Response.

Reviewer comments:
and . Given (either assuming a fixed key ID, or looking up the KEM based on key ID), I think this is a nice simplification. It also authenticates more, even if redundant. (The kemID is already part of the HPKE key schedule.) I implemented this change and it's straightforward.
Currently, an encapsulated request carries a key ID which maps to a KEM key that determines the size of the encapsulated public key in a request. This means that code parsing a request needs to know the ID -> KEM mapping in order to parse things correctly, which is somewhat annoying. I propose we add KEMID to the request so that this mapping isn't needed to just parse the message. As a bonus, that would also fold in the KEMID explicitly into the AAD alongside the KDFID and AEADID.
We currently length-prefix it, but we don't have to. Think about this a little.
Both the public key and encapsulated secret are fixed length. I think making these fixed length on the wire is good. However, it does require the parsing code to know the corresponding size, which depends on the KEM. This requires there to be a function to map the kem_id to the corresponding size(s). NAME do you have such an API in your implementation? I have one in mine, which would make this pretty straightforward to implement.

Revised text:
enc-request. request describes the process for constructing and processing an Encapsulated Request. <ins> The Nenc parameter corresponding to the HpkeKdfId can be found in HPKE. </ins> Responses are bound to responses and so consist only of AEAD- protected content.  response describes the process for constructing and processing an Encapsulated Response.
Original text:
Clients encapsulate a request "request" using values from a key configuration: <del> the key identifier from the configuration, "keyID", </del>  the public key from the configuration, "pkR", and

Reviewer comments:
and . Given (either assuming a fixed key ID, or looking up the KEM based on key ID), I think this is a nice simplification. It also authenticates more, even if redundant. (The kemID is already part of the HPKE key schedule.) I implemented this change and it's straightforward.
Currently, an encapsulated request carries a key ID which maps to a KEM key that determines the size of the encapsulated public key in a request. This means that code parsing a request needs to know the ID -> KEM mapping in order to parse things correctly, which is somewhat annoying. I propose we add KEMID to the request so that this mapping isn't needed to just parse the message. As a bonus, that would also fold in the KEMID explicitly into the AAD alongside the KDFID and AEADID.
We currently length-prefix it, but we don't have to. Think about this a little.
Both the public key and encapsulated secret are fixed length. I think making these fixed length on the wire is good. However, it does require the parsing code to know the corresponding size, which depends on the KEM. This requires there to be a function to map the kem_id to the corresponding size(s). NAME do you have such an API in your implementation? I have one in mine, which would make this pretty straightforward to implement.

Revised text:
Clients encapsulate a request "request" using values from a key configuration:  <ins> the key identifier from the configuration, "keyID", with the corresponding KEM identified by "kemID", </ins> the public key from the configuration, "pkR", and
Original text:
encapsulation key "enc". Construct associated data, "aad", by concatenating the values of <del> "keyID", "kdfID", and "aeadID", as 8-, 16- and 16-bit integers respectively, each in network byte order. </del>  Encrypt (seal) "request" with "aad" as associated data using "context", yielding ciphertext "ct".

Reviewer comments:
and . Given (either assuming a fixed key ID, or looking up the KEM based on key ID), I think this is a nice simplification. It also authenticates more, even if redundant. (The kemID is already part of the HPKE key schedule.) I implemented this change and it's straightforward.
Currently, an encapsulated request carries a key ID which maps to a KEM key that determines the size of the encapsulated public key in a request. This means that code parsing a request needs to know the ID -> KEM mapping in order to parse things correctly, which is somewhat annoying. I propose we add KEMID to the request so that this mapping isn't needed to just parse the message. As a bonus, that would also fold in the KEMID explicitly into the AAD alongside the KDFID and AEADID.
We currently length-prefix it, but we don't have to. Think about this a little.
Both the public key and encapsulated secret are fixed length. I think making these fixed length on the wire is good. However, it does require the parsing code to know the corresponding size, which depends on the KEM. This requires there to be a function to map the kem_id to the corresponding size(s). NAME do you have such an API in your implementation? I have one in mine, which would make this pretty straightforward to implement.

Revised text:
encapsulation key "enc". Construct associated data, "aad", by concatenating the values of  <ins> "keyID", "kemID", "kdfID", and "aeadID", as one 8-bit integer and three 16-bit integers, respectively, each in network byte order. </ins> Encrypt (seal) "request" with "aad" as associated data using "context", yielding ciphertext "ct".
Original text:
Servers decrypt an Encapsulated Request by reversing this process. Given an Encapsulated Request "enc_request", a server: <del> Parses "enc_request" into "keyID", "kdfID", "aeadID", "enc", and "ct" (indicated using the function "parse()" in pseudocode).  The server is then able to find the HPKE private key, "skR", corresponding to "keyID". </del>  <del> a.  If "keyID" does not identify a key, the server returns an error. </del>  b.  If "kdfID" and "aeadID" identify a combination of KDF and AEAD that the server is unwilling to use with "skR", the server returns

Reviewer comments:
and . Given (either assuming a fixed key ID, or looking up the KEM based on key ID), I think this is a nice simplification. It also authenticates more, even if redundant. (The kemID is already part of the HPKE key schedule.) I implemented this change and it's straightforward.
Currently, an encapsulated request carries a key ID which maps to a KEM key that determines the size of the encapsulated public key in a request. This means that code parsing a request needs to know the ID -> KEM mapping in order to parse things correctly, which is somewhat annoying. I propose we add KEMID to the request so that this mapping isn't needed to just parse the message. As a bonus, that would also fold in the KEMID explicitly into the AAD alongside the KDFID and AEADID.
We currently length-prefix it, but we don't have to. Think about this a little.
Both the public key and encapsulated secret are fixed length. I think making these fixed length on the wire is good. However, it does require the parsing code to know the corresponding size, which depends on the KEM. This requires there to be a function to map the kem_id to the corresponding size(s). NAME do you have such an API in your implementation? I have one in mine, which would make this pretty straightforward to implement.

Revised text:
Servers decrypt an Encapsulated Request by reversing this process. Given an Encapsulated Request "enc_request", a server:  <ins> Parses "enc_request" into "keyID", "kemID", "kdfID", "aeadID", "enc", and "ct" (indicated using the function "parse()" in pseudocode).  The server is then able to find the HPKE private key, "skR", corresponding to "keyID". </ins>  <ins> a.  If "keyID" does not identify a key matching the type of "kemID", the server returns an error. </ins> b.  If "kdfID" and "aeadID" identify a combination of KDF and AEAD that the server is unwilling to use with "skR", the server returns
Original text:
the QUIC header, if present.  This supports cases where address information changes, such as NAT rebinding, intentional change of the local interface, or based on an indication in the handshake of the <del> server for a preferred address to be used. </del>  Currently QUIC only supports failover cases.  Only one "path" can be used at a time, and only when the new path is validated all traffic

Reviewer comments:
note: when merged.
We should probably make it clear what the application can do here (SPA for servers; maybe intentional migration for clients?) I'm not sure if migration is transparent to client applications or not.
The client application might have some knowledge if it's behind a NAT or not and as such might want to indicate to use Conn ID or not. We can make that more explicit in the text.
I did some small edits on the text in the connection migration section but NAME maybe you had something more in mind and want to propose more text?
This whole section should then also be moved to after the Conn ID section.
I like the move of text to the manageability draft. If it were me, I'd move "Server-Generated Connection ID" as well, as I don't think apps need to worry about it, but it's not a big deal. I think adding text about server preferred address is probably more important for this draft.
Added some more text in
NAME we think the current state of the draft addresses this issue; could you check and close this issue if so?

Revised text:
the QUIC header, if present.  This supports cases where address information changes, such as NAT rebinding, intentional change of the local interface, or based on an indication in the handshake of the  <ins> server for a preferred address to be used.  As such if the client is known or likely to sit behind a NAT, use of a connection ID for the server is strongly recommended.  A non-empty connection ID for the server is also strongly recommended when migration is supported. </ins> Currently QUIC only supports failover cases.  Only one "path" can be used at a time, and only when the new path is validated all traffic
Original text:
characteristics as input for the switching decision or the congestion controller on the new path.  8. QUIC connections are closed either by expiration of an idle timeout,

Reviewer comments:
note: when merged.
We should probably make it clear what the application can do here (SPA for servers; maybe intentional migration for clients?) I'm not sure if migration is transparent to client applications or not.
The client application might have some knowledge if it's behind a NAT or not and as such might want to indicate to use Conn ID or not. We can make that more explicit in the text.
I did some small edits on the text in the connection migration section but NAME maybe you had something more in mind and want to propose more text?
This whole section should then also be moved to after the Conn ID section.
I like the move of text to the manageability draft. If it were me, I'd move "Server-Generated Connection ID" as well, as I don't think apps need to worry about it, but it's not a big deal. I think adding text about server preferred address is probably more important for this draft.
Added some more text in
NAME we think the current state of the draft addresses this issue; could you check and close this issue if so?

Revised text:
characteristics as input for the switching decision or the congestion controller on the new path. <ins> Only the client can actively migrate.  However, servers can indicate during the handshake that they prefer to transfer the connection to a different address after the handshake, e.g. to move from an address that is shared by multiple servers to an address that is unique to the server instance.  The server can provide an IPv4 and an IPv6 address in a transport parameter during the TLS handshake and the client can select between the two if both are provided.  See also Section 9.6 of QUIC. </ins> 8. QUIC connections are closed either by expiration of an idle timeout,
Original text:
changes under discussion, via issues and pull requests in GitHub current as of the time of writing. <del> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> 2. In this section, we discusses those aspects of the QUIC transport

Reviewer comments:
note: don't merge yet, still need to make the pass on applicability but working on the CI issue at the moment
done. mergeable if ok.
There are a few instances that might be read as normative statements. Is that really wise? Examples: cannot? Maybe this isn't something that this document needs to say. It could just say that fallback to unencrypted TCP might not be a desirable outcome. There is also a bunch of "MUST"-level statements in the 0-RTT section, but I've proposed a rewrite that (I hope) eliminates them.
Fixed in : removed all 2119 language.
Not clear if these documents should use normative language at all. The applicability statement also sometimes uses normative language to recommend the implementation of certain interfaces; I don't think this is the right document for that but as we also don't have another document, we should decide if we want to do that or not!
Manageability is a user's guide to the wire image, as such there's no sense to normative language (though I suppose some might like to add MUST NOT observe packets). Since applicability is in part a set of recommendations to application designers, normative language might make sense there... but the document is informational, so normative language here has to reference or be trivially derived from normative language in one of the base drafts. To simplify things, I'd just scrub all the SHOULDs, MAYs, and MUSTs.

Revised text:
changes under discussion, via issues and pull requests in GitHub current as of the time of writing.  2. In this section, we discusses those aspects of the QUIC transport
Original text:
header, is integrity protected.  Further, information that was sent and exposed in handshake packets sent before the cryptographic context was established are validated later during the cryptographic <del> handshake.  Therefore, devices on path MUST NOT change any information or bits in QUIC packet headers, since alteration of header information will lead to a failed integrity check at the receiver, and can even lead to connection termination. </del>  2.6.

Reviewer comments:
note: don't merge yet, still need to make the pass on applicability but working on the CI issue at the moment
done. mergeable if ok.
There are a few instances that might be read as normative statements. Is that really wise? Examples: cannot? Maybe this isn't something that this document needs to say. It could just say that fallback to unencrypted TCP might not be a desirable outcome. There is also a bunch of "MUST"-level statements in the 0-RTT section, but I've proposed a rewrite that (I hope) eliminates them.
Fixed in : removed all 2119 language.
Not clear if these documents should use normative language at all. The applicability statement also sometimes uses normative language to recommend the implementation of certain interfaces; I don't think this is the right document for that but as we also don't have another document, we should decide if we want to do that or not!
Manageability is a user's guide to the wire image, as such there's no sense to normative language (though I suppose some might like to add MUST NOT observe packets). Since applicability is in part a set of recommendations to application designers, normative language might make sense there... but the document is informational, so normative language here has to reference or be trivially derived from normative language in one of the base drafts. To simplify things, I'd just scrub all the SHOULDs, MAYs, and MUSTs.

Revised text:
header, is integrity protected.  Further, information that was sent and exposed in handshake packets sent before the cryptographic context was established are validated later during the cryptographic  <ins> handshake.  Therefore, devices on path cannot alter any information or bits in QUIC packet headers, since alteration of header information will lead to a failed integrity check at the receiver, and can even lead to connection termination. </ins> 2.6.
Original text:
given that establishing a new connection using 0-RTT support is cheap and fast. <del> QoS mechanisms in the network MAY also use the connection ID for </del>  service differentiation, as a change of connection ID is bound to a change of address which anyway is likely to lead to a re-route on a different path with different network characteristics.

Reviewer comments:
note: don't merge yet, still need to make the pass on applicability but working on the CI issue at the moment
done. mergeable if ok.
There are a few instances that might be read as normative statements. Is that really wise? Examples: cannot? Maybe this isn't something that this document needs to say. It could just say that fallback to unencrypted TCP might not be a desirable outcome. There is also a bunch of "MUST"-level statements in the 0-RTT section, but I've proposed a rewrite that (I hope) eliminates them.
Fixed in : removed all 2119 language.
Not clear if these documents should use normative language at all. The applicability statement also sometimes uses normative language to recommend the implementation of certain interfaces; I don't think this is the right document for that but as we also don't have another document, we should decide if we want to do that or not!
Manageability is a user's guide to the wire image, as such there's no sense to normative language (though I suppose some might like to add MUST NOT observe packets). Since applicability is in part a set of recommendations to application designers, normative language might make sense there... but the document is informational, so normative language here has to reference or be trivially derived from normative language in one of the base drafts. To simplify things, I'd just scrub all the SHOULDs, MAYs, and MUSTs.

Revised text:
given that establishing a new connection using 0-RTT support is cheap and fast.  <ins> QoS mechanisms in the network could also use the connection ID for </ins> service differentiation, as a change of connection ID is bound to a change of address which anyway is likely to lead to a re-route on a different path with different network characteristics.
Original text:
applicability, and issues that application developers must consider when using QUIC as a transport for their application. <del> 1.1. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> 2. QUIC uses UDP as a substrate.  This enables both userspace

Reviewer comments:
note: don't merge yet, still need to make the pass on applicability but working on the CI issue at the moment
done. mergeable if ok.
There are a few instances that might be read as normative statements. Is that really wise? Examples: cannot? Maybe this isn't something that this document needs to say. It could just say that fallback to unencrypted TCP might not be a desirable outcome. There is also a bunch of "MUST"-level statements in the 0-RTT section, but I've proposed a rewrite that (I hope) eliminates them.
Fixed in : removed all 2119 language.
Not clear if these documents should use normative language at all. The applicability statement also sometimes uses normative language to recommend the implementation of certain interfaces; I don't think this is the right document for that but as we also don't have another document, we should decide if we want to do that or not!
Manageability is a user's guide to the wire image, as such there's no sense to normative language (though I suppose some might like to add MUST NOT observe packets). Since applicability is in part a set of recommendations to application designers, normative language might make sense there... but the document is informational, so normative language here has to reference or be trivially derived from normative language in one of the base drafts. To simplify things, I'd just scrub all the SHOULDs, MAYs, and MUSTs.

Revised text:
applicability, and issues that application developers must consider when using QUIC as a transport for their application.  2. QUIC uses UDP as a substrate.  This enables both userspace
Original text:
even if TFO was successfully negotiated (see PaaschNanog). Any fallback mechanism is likely to impose a degradation of <del> performance; however, fallback MUST not silently violate the </del>  application's expectation of confidentiality or integrity of its payload data.

Reviewer comments:
note: don't merge yet, still need to make the pass on applicability but working on the CI issue at the moment
done. mergeable if ok.
There are a few instances that might be read as normative statements. Is that really wise? Examples: cannot? Maybe this isn't something that this document needs to say. It could just say that fallback to unencrypted TCP might not be a desirable outcome. There is also a bunch of "MUST"-level statements in the 0-RTT section, but I've proposed a rewrite that (I hope) eliminates them.
Fixed in : removed all 2119 language.
Not clear if these documents should use normative language at all. The applicability statement also sometimes uses normative language to recommend the implementation of certain interfaces; I don't think this is the right document for that but as we also don't have another document, we should decide if we want to do that or not!
Manageability is a user's guide to the wire image, as such there's no sense to normative language (though I suppose some might like to add MUST NOT observe packets). Since applicability is in part a set of recommendations to application designers, normative language might make sense there... but the document is informational, so normative language here has to reference or be trivially derived from normative language in one of the base drafts. To simplify things, I'd just scrub all the SHOULDs, MAYs, and MUSTs.

Revised text:
even if TFO was successfully negotiated (see PaaschNanog). Any fallback mechanism is likely to impose a degradation of  <ins> performance; however, fallback must not silently violate the </ins> application's expectation of confidentiality or integrity of its payload data.