jiebi/TextFlow huggingface dataset:
Original text:
The client's TLS ClientHello may contain a Server Name Indication (SNI) RFC6066 extension, by which the client reveals the name of the server it intends to connect to, in order to allow the server to <del> present a certificate based on that name.  It may also contain an Application-Layer Protocol Negotiation (ALPN) RFC7301 extension, by which the client exposes the names of application-layer protocols it supports; an observer can deduce that one of those protocols will be used if the connection continues. </del>  Work is currently underway in the TLS working group to encrypt the contents of the ClientHello in TLS 1.3 TLS-ECH.  This would make SNI-

Reviewer comments:
"Here we assume a bidirectional observer", let's also state that there is no section about unidirectional observer ?
Not sure if we add something because I think it okay to state assumptions...
"unless noted" states that we'll note when something is unidirectionally observable, I'm reviewing the language now to see if we missed any...

Revised text:
The client's TLS ClientHello may contain a Server Name Indication (SNI) RFC6066 extension, by which the client reveals the name of the server it intends to connect to, in order to allow the server to  <ins> present a certificate based on that name.  SNI information is available to unidirectional observers on the client-to-server path, if present. The TLS ClientHello may also contain an Application-Layer Protocol Negotiation (ALPN) RFC7301 extension, by which the client exposes the names of application-layer protocols it supports; an observer can deduce that one of those protocols will be used if the connection continues. </ins> Work is currently underway in the TLS working group to encrypt the contents of the ClientHello in TLS 1.3 TLS-ECH.  This would make SNI-
Original text:
recognition of the handshake, as illustrated in handshake.  It can also be inferred during the flow's lifetime, if the endpoints use the spin bit facility described below and in Section 17.3.1 of QUIC- <del> TRANSPORT. </del>  3.8.1.

Reviewer comments:
"Here we assume a bidirectional observer", let's also state that there is no section about unidirectional observer ?
Not sure if we add something because I think it okay to state assumptions...
"unless noted" states that we'll note when something is unidirectionally observable, I'm reviewing the language now to see if we missed any...

Revised text:
recognition of the handshake, as illustrated in handshake.  It can also be inferred during the flow's lifetime, if the endpoints use the spin bit facility described below and in Section 17.3.1 of QUIC-  <ins> TRANSPORT.  RTT measurement is available to unidirectional observers when the spin bit is enabled. </ins> 3.8.1.
Original text:
that the load balancer will redirect the next Client Initial packet to a different server in that pool. <del> 6.3. QUIC provides for multiple Server and Client Connection IDs to be used simultaneously by a given connection, which allows seamless connection migration when one of the endpoints changes IP address and/or UDP port.  Section 6.11.5 of QUIC describes how to use this facility to reduce the risk of exposing a link among these addresses to observers on the network.  However, analysis of the lifetimes of six-tuples (source and destination addresses as well as the migrated CID) may expose these links anyway. In practice, a finite set of flows will be undergoing migration within any one time window as seen from any given observation point in the network, and any migration must keep at least one endpoint address constant during the migration.  Because of this, a key insight here is that this finite set of flows represents the anonymity set for any one flow undergoing migration within it.  For endpoints with low volume, this anonymity set will be necessarily small, so there remains a significant risk of linkage exposure through timing-based analysis. The most efficient mitigation for these attacks is operational, by increasing the size of the anonymity set as seen from a passive observer in the Internet, either by using a load balancing architecture that loads more flows onto a single server-side address, by coordinating the timing of migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means. </del> 7. Versioning in QUIC may change the protocol's behavior completely,

Reviewer comments:
Tries to I resisted the urge to reference the QUIC-LB draft, which isn't adopted. The major substantive change is that I removed the prohibition on non-routing information in the CID. I'm happy to discuss this if people have object.
LGTM. will go ahead and land this, then fix up the lint issues.
NAME missed this during the inconsistency, will fix in working copy
(this is done)
BTW, this was meant to address
Moving URL to the ops repo.
see also -- in any case the text that is there now is not great.
NAME can you please review the existing text (orginially provided by NAME and state what else is needed? Please have also a look at issue
This is a bit OBE, but I think there might still be value in discussing how a server implementer should think about connection IDs. Fortunately, NAME has been doing a bunch of work on this in his load balancer draft. I would suggest that we leave this issue open, and either point to the LB draft or use text from it.
fixed this
Write section to provide guidance; maybe in the same section than guidance in port selection in general

Revised text:
that the load balancer will redirect the next Client Initial packet to a different server in that pool.  7. Versioning in QUIC may change the protocol's behavior completely,
Original text:
semantics as needed for HTTP/2 QUIC-HTTP.  Based on current deployment practices, QUIC is encapsulated in UDP and encrypted by default.  The current version of QUIC integrates TLS QUIC-TLS to <del> encrypt all payload data and most control information.  Given QUIC is an end-to-end transport protocol, all information in the protocol header, even that which can be inspected, is is not meant to be mutable by the network, and is therefore integrity-protected to the extent possible. </del>  This document provides guidance for network operation on the management of QUIC traffic.  This includes guidance on how to

Reviewer comments:
Address .
The section on "Passive network performance measurement and troubleshooting" is probably a bit too pessimistic. It's probably worth pointing out that one part of network troubleshooting -- "find out which box to blame" -- is substantially easier. Thanks to integrity protection, most middleboxes, can drop, delay/rate limit, and corrupt, and that's about it. These are fairly easy behaviors to diagnose. I've had some conversations with customers afraid of not having their TCP headers anymore, and I believe this fear is largely misguided. If people agree this belongs in the draft, I can file a PR.
I agree the wording is very pessimistic. However, I don't think your observation belongs in this section because it's about measurement of performance metrics. There is a sentence in the introduction: "Given QUIC is an end-to-end transport protocol, all information in the protocol header, even that which can be inspected, is is not meant to be mutable by the network, and is therefore integrity-protected to the extent possible." Maybe it makes sense to add another sentence right there to also emphasis the positive effect of that, like: "While more limited information compared to TCP is visible to the network, integrity protection can also make troubleshooting easier as none of the nodes on the network path can modify the transport layer information."
LGTM, will fix Jana's suggestion manually.One nit, but LGTM. The nit is to avoid ambiguity that might arise from "transport" -- one might read that QUIC integrity-protects UDP headers as well, since those are technically transport.

Revised text:
semantics as needed for HTTP/2 QUIC-HTTP.  Based on current deployment practices, QUIC is encapsulated in UDP and encrypted by default.  The current version of QUIC integrates TLS QUIC-TLS to  <ins> encrypt all payload data and most control information. Given that QUIC is an end-to-end transport protocol, all information in the protocol header, even that which can be inspected, is not meant to be mutable by the network, and is therefore integrity- protected.  While less information is visible to the network than for TCP, integrity protection can also simplify troubleshooting because none of the nodes on the network path can modify the transport layer information. </ins> This document provides guidance for network operation on the management of QUIC traffic.  This includes guidance on how to
Original text:
Without this optimization, it is not possible, not even in theory, to achieve the minimum number of flights.  This optimization makes it <del> possible also in practice, since the last message of the EDHOC </del>  protocol can be made relatively small (see Section 1 of I-D.ietf- lake-edhoc), thus allowing additional OSCORE protected CoAP data within target MTU sizes.

Reviewer comments:
Clean-up after URL As the content-from-edhoc branch seems to be the most up-to-date one (in which the parts changed are introduced in the first place), this builds on , and only the latest commit is actually relevant.
Compared to the original bstridentifier mapping, this is a different int-to-bstr mapping, but one that's most likely efficient to implement. I have not made any statement on the efficiencies, but some guidance we could give is that from a coding density point of view, numeric Cx should only be used with -24..23; for all other values, doing it in a bstr is just as good and saves a byte in OSCORE. (In fact we may want to make that normative, so that only the single-byte case needs to be implemented where this needs explicit implementation).

Revised text:
Without this optimization, it is not possible, not even in theory, to achieve the minimum number of flights.  This optimization makes it  <ins> possible also in practice since the last message of the EDHOC </ins> protocol can be made relatively small (see Section 1 of I-D.ietf- lake-edhoc), thus allowing additional OSCORE protected CoAP data within target MTU sizes.
Original text:
EDHOC data and the OSCORE ciphertext, using the newly defined EDHOC option for signalling. <del> 4. The approach defined in this specification consists of sending EDHOC message_3 inside an OSCORE protected CoAP message. The resulting EDHOC + OSCORE request is in practice the OSCORE Request from fig-non-combined, sent to a protected resource and with the correct CoAP method and options, with the addition that it also transports EDHOC message_3. Since EDHOC message_3 may be too large to be included in a CoAP Option, e.g. if containing a large public key certificate chain, it has to be transported through the CoAP payload. The use of this approach is explicitly signalled by including an EDHOC Option (see signalling) in the EDHOC + OSCORE request. 4.1. </del>  The Client prepares an EDHOC + OSCORE request as follows.

Reviewer comments:
Clean-up after URL As the content-from-edhoc branch seems to be the most up-to-date one (in which the parts changed are introduced in the first place), this builds on , and only the latest commit is actually relevant.
Compared to the original bstridentifier mapping, this is a different int-to-bstr mapping, but one that's most likely efficient to implement. I have not made any statement on the efficiencies, but some guidance we could give is that from a coding density point of view, numeric Cx should only be used with -24..23; for all other values, doing it in a bstr is just as good and saves a byte in OSCORE. (In fact we may want to make that normative, so that only the single-byte case needs to be implemented where this needs explicit implementation).

Revised text:
EDHOC data and the OSCORE ciphertext, using the newly defined EDHOC option for signalling.  <ins> 5.2. </ins> The Client prepares an EDHOC + OSCORE request as follows.
Original text:
the CBOR sequence built at step 3. Signal the usage of this approach within the EDHOC + OSCORE <del> request, by including the new EDHOC Option defined in signalling. </del>  <del> 4.2. </del>  <del> When receiving an EDHOC + OSCORE request, the Server performs the following steps. </del>  <del> Check the presence of the EDHOC option defined in signalling, to determine that the received request is an EDHOC + OSCORE request. If this is the case, the Server continues with the steps defined below. </del>  Extract CIPHERTEXT_3 from the payload of the EDHOC + OSCORE request, as the first CBOR byte string in the CBOR sequence.

Reviewer comments:
Clean-up after URL As the content-from-edhoc branch seems to be the most up-to-date one (in which the parts changed are introduced in the first place), this builds on , and only the latest commit is actually relevant.
Compared to the original bstridentifier mapping, this is a different int-to-bstr mapping, but one that's most likely efficient to implement. I have not made any statement on the efficiencies, but some guidance we could give is that from a coding density point of view, numeric Cx should only be used with -24..23; for all other values, doing it in a bstr is just as good and saves a byte in OSCORE. (In fact we may want to make that normative, so that only the single-byte case needs to be implemented where this needs explicit implementation).

Revised text:
the CBOR sequence built at step 3. Signal the usage of this approach within the EDHOC + OSCORE  <ins> request, by including the new EDHOC Option defined in edhoc- option. </ins>  <ins> 5.3. </ins>  <ins> When receiving a request containing the EDHOC option, i.e. an EDHOC + OSCORE request, the Server MUST perform the following steps. </ins>  <ins> Check that the payload of the EDHOC + OSCORE request is a CBOR sequence composed of two CBOR byte strings.  If this is not the case, the Server MUST stop processing the request and MUST respond with a 4.00 (Bad Request) error message. </ins> Extract CIPHERTEXT_3 from the payload of the EDHOC + OSCORE request, as the first CBOR byte string in the CBOR sequence.
Original text:
derivation, as per Section 5.4.3 and Section 7.2.1 of I-D.ietf- lake-edhoc, respectively.  Extract the OSCORE ciphertext from the payload of the EDHOC + OSCORE request, as the value of the second CBOR byte string in the CBOR sequence.

Reviewer comments:
Clean-up after URL As the content-from-edhoc branch seems to be the most up-to-date one (in which the parts changed are introduced in the first place), this builds on , and only the latest commit is actually relevant.
Compared to the original bstridentifier mapping, this is a different int-to-bstr mapping, but one that's most likely efficient to implement. I have not made any statement on the efficiencies, but some guidance we could give is that from a coding density point of view, numeric Cx should only be used with -24..23; for all other values, doing it in a bstr is just as good and saves a byte in OSCORE. (In fact we may want to make that normative, so that only the single-byte case needs to be implemented where this needs explicit implementation).

Revised text:
derivation, as per Section 5.4.3 and Section 7.2.1 of I-D.ietf- lake-edhoc, respectively. <ins> If the applicability statement used in the EDHOC session specifies that EDHOC message_4 shall be sent, the Server MUST stop the EDHOC processing and consider it failed, as due to a client error. </ins> Extract the OSCORE ciphertext from the payload of the EDHOC + OSCORE request, as the value of the second CBOR byte string in the CBOR sequence.
Original text:
7.  This document has the following actions for IANA. 7.1.

Reviewer comments:
Clean-up after URL As the content-from-edhoc branch seems to be the most up-to-date one (in which the parts changed are introduced in the first place), this builds on , and only the latest commit is actually relevant.
Compared to the original bstridentifier mapping, this is a different int-to-bstr mapping, but one that's most likely efficient to implement. I have not made any statement on the efficiencies, but some guidance we could give is that from a coding density point of view, numeric Cx should only be used with -24..23; for all other values, doing it in a bstr is just as good and saves a byte in OSCORE. (In fact we may want to make that normative, so that only the single-byte case needs to be implemented where this needs explicit implementation).

Revised text:
7. <ins> RFC Editor: Please replace "[[this Document]]" with the RFC number of this document and delete this paragraph. </ins> This document has the following actions for IANA. 7.1.
Original text:
[ The CoAP option numbers 13 and 21 are both consistent with the <del> properties of the EDHOC Option defined in signalling, and they both </del>  allow the EDHOC Option to always result in an overall size of 1 byte. This is because:

Reviewer comments:
Clean-up after URL As the content-from-edhoc branch seems to be the most up-to-date one (in which the parts changed are introduced in the first place), this builds on , and only the latest commit is actually relevant.
Compared to the original bstridentifier mapping, this is a different int-to-bstr mapping, but one that's most likely efficient to implement. I have not made any statement on the efficiencies, but some guidance we could give is that from a coding density point of view, numeric Cx should only be used with -24..23; for all other values, doing it in a bstr is just as good and saves a byte in OSCORE. (In fact we may want to make that normative, so that only the single-byte case needs to be implemented where this needs explicit implementation).

Revised text:
[ The CoAP option numbers 13 and 21 are both consistent with the  <ins> properties of the EDHOC Option defined in edhoc-option, and they both </ins> allow the EDHOC Option to always result in an overall size of 1 byte. This is because:
Original text:
unassigned in the "CoAP Option Numbers" registry, as first available and consistent option numbers for the EDHOC option.  ] 

Reviewer comments:
Clean-up after URL As the content-from-edhoc branch seems to be the most up-to-date one (in which the parts changed are introduced in the first place), this builds on , and only the latest commit is actually relevant.
Compared to the original bstridentifier mapping, this is a different int-to-bstr mapping, but one that's most likely efficient to implement. I have not made any statement on the efficiencies, but some guidance we could give is that from a coding density point of view, numeric Cx should only be used with -24..23; for all other values, doing it in a bstr is just as good and saves a byte in OSCORE. (In fact we may want to make that normative, so that only the single-byte case needs to be implemented where this needs explicit implementation).

Revised text:
unassigned in the "CoAP Option Numbers" registry, as first available and consistent option numbers for the EDHOC option. <ins> This document suggests 21 (TBD21) as option number to be assigned to the new EDHOC option, since both 13 and 21 are consistent for the use case in question, but different use cases or protocols may make better use of the option number 13. </ins> ] <ins> 7.2. IANA is asked to enter the following entries to the "EDHOC Exporter Label" registry defined in I-D.ietf-lake-edhoc. </ins>
Original text:
Outer Observe value, it stops processing the message, as specified in ver-res. <del> It the server accepts the Observe registration, a Partial IV must be </del>  included in all notifications (both successful and error).  To secure the order of notifications, the client SHALL maintain a Notification Number for each Observation it registers.  The Notification Number is

Reviewer comments:
This PR should (hopefully) conclude the main rewrite of Observe which was triggered by the security analysis and additional reviews of Observe. It should (hopefully) now be clear what part of the Observe related processing can be omitted in case Observe is not supported or in case intermediaries are not used. A new appendix E is covering the latter case.

Revised text:
Outer Observe value, it stops processing the message, as specified in ver-res.  <ins> In order to support Observe processing in OSCORE-unaware intermediaries, for messages with the Observe option the Outer Code SHALL be set to 0.05 (FETCH) for requests and to 2.05 (Content) for responses. 4.1.3.4.2. It the server accepts an Observe registration, a Partial IV must be </ins> included in all notifications (both successful and error).  To secure the order of notifications, the client SHALL maintain a Notification Number for each Observation it registers.  The Notification Number is
Original text:
Partial IV MUST always be compared with the Notification Number, which thus MUST NOT be forgotten after 128 seconds.  Further details of replay protection of notifications are specified in replay- <del> protection.  The client MAY ignore the Observe option value. </del>  Clients can re-register observations to ensure that the observation is still active and establish freshness again (RFC7641 <del> Section 3.3.1).  When an OSCORE observation is refreshed, not only the ETags, but also the partial IV (and thus the payload and OSCORE option) change.  The server uses the new request's Partial IV as the 'request_piv' of new responses. </del>  4.1.3.5.

Reviewer comments:
This PR should (hopefully) conclude the main rewrite of Observe which was triggered by the security analysis and additional reviews of Observe. It should (hopefully) now be clear what part of the Observe related processing can be omitted in case Observe is not supported or in case intermediaries are not used. A new appendix E is covering the latter case.

Revised text:
Partial IV MUST always be compared with the Notification Number, which thus MUST NOT be forgotten after 128 seconds.  Further details of replay protection of notifications are specified in replay-  <ins> protection. </ins> Clients can re-register observations to ensure that the observation is still active and establish freshness again (RFC7641  <ins> Section 3.3.1).  When an OSCORE protected observation is refreshed, not only the ETags, but also the partial IV (and thus the payload and OSCORE option) change.  The server uses the new request's Partial IV as the 'request_piv' of new responses. </ins> 4.1.3.5.