jiebi/TextFlow huggingface dataset:
Original text:
e.g., public key cryptographic operations, avoiding waste is desirable.  3. <del> Clients may indicate to servers their desired number of tickets via the following "ticket_request" extension: </del>  Clients may send this extension in ClientHello.  It contains the following structure:

Reviewer comments:
Good catch -- will fix. Good suggestion! We can certainly add this. As the extension is merely a hint to servers when deciding how many tickets to vend, I think this is out of scope for the document. It's intended to be once per session, and we'll add that. Also a good catch. Like other extensions that are not affected by the possibly updated ClientHello, it must not change. We need to specify the server side behavior, too. That seems reasonable to me.
Thanks! Approved pending

Revised text:
e.g., public key cryptographic operations, avoiding waste is desirable. <ins> Decline resumption: Clients may indicate they have no intention of resuming connections by sending a ticket request with count of zero. </ins> 3.  <ins> Clients may indicate to servers their desired number of tickets for a single connection via the following "ticket_request" extension: </ins> Clients may send this extension in ClientHello.  It contains the following structure:
Original text:
send more than 255 tickets to clients. Servers that support ticket requests MUST NOT echo "ticket_request" <del> in the EncryptedExtensions. </del>  4.

Reviewer comments:
Good catch -- will fix. Good suggestion! We can certainly add this. As the extension is merely a hint to servers when deciding how many tickets to vend, I think this is out of scope for the document. It's intended to be once per session, and we'll add that. Also a good catch. Like other extensions that are not affected by the possibly updated ClientHello, it must not change. We need to specify the server side behavior, too. That seems reasonable to me.
Thanks! Approved pending

Revised text:
send more than 255 tickets to clients. Servers that support ticket requests MUST NOT echo "ticket_request"  <ins> in the EncryptedExtensions message.  A client MUST abort the connection with an "illegal_parameter" alert if the "ticket_request" extension is present in the EncryptedExtensions message. Clients MUST NOT change the value of TicketRequestContents.count in second ClientHello messages sent in response to a HelloRetryRequest. </ins> 4.
Original text:
From the client's perspective, a WebTransport session is established when the client receives a 200 response.  From the server's perspective, a session is established once it sends a 200 response. <del> Both endpoints MUST NOT open any streams or send any datagrams on a given session before that session is established.  WebTransport over HTTP/3 does not support 0-RTT. </del>  3.4.

Reviewer comments:
.
cc NAME NAME
Looks great!
For a simple application that wants to send "hello world" over a WebTransport stream, it would take a minimum of 2.5 round trips for the data to arrive on the server. This is still an improvement over WebSockets but I'm wondering if we could do better. If the client is able to create streams prior to receiving the CONNECT response, then it would remove a round trip. The server would need to buffer any data received on streams associated with an unknown WebTransport session. If the server responds with a non-200 status code, then these streams are discarded. I believe 0-RTT is disabled for WebTransport because CONNECT is not idempotent and would be subject to replay attacks. An idempotent CONNECT would remove a round trip when 0-RTT is used... although I'm not sure this is a good idea.
I think this is a reasonable optimization
The client requirement is odd in comparison to MASQUE / CONNECT-UDP which says "client can risk sending datagrams before getting a 200 response, a different response means that datagrams will be discarded". What is the motivation for the requirement in WebTransport? If you need some kind of ordering guarantees, then stream IDs provide that.
Discussed at IETF 110. There were no objections to buffering (with some limits), so I think we should go ahead and add it.
After the client initiates the WebTransport session by sending a CONNECT request, the server sends a 200 response and is free to create streams. This means that a server-initiated stream may arrive prior to the CONNECT response. Is the client able to infer that the session was successfully established, or does the client need to buffer this stream until it receives a proper response?
Since there are no ordering guarantees across streams on the receiver side, I'd say you have to buffer until the 200 is processed.
I agree with Lucas here. We also had a similar problem in QuicTransport (server has to buffer streams before checking the origin), and we handled it by buffering.
Discussed at IETF 110. There were no objections to buffering (with some limits), so I think we should go ahead and add it.

Revised text:
From the client's perspective, a WebTransport session is established when the client receives a 200 response.  From the server's perspective, a session is established once it sends a 200 response.  <ins> WebTransport over HTTP/3 does not support 0-RTT. </ins> 3.4.
Original text:
This document Both 

Reviewer comments:
.
cc NAME NAME
Looks great!
For a simple application that wants to send "hello world" over a WebTransport stream, it would take a minimum of 2.5 round trips for the data to arrive on the server. This is still an improvement over WebSockets but I'm wondering if we could do better. If the client is able to create streams prior to receiving the CONNECT response, then it would remove a round trip. The server would need to buffer any data received on streams associated with an unknown WebTransport session. If the server responds with a non-200 status code, then these streams are discarded. I believe 0-RTT is disabled for WebTransport because CONNECT is not idempotent and would be subject to replay attacks. An idempotent CONNECT would remove a round trip when 0-RTT is used... although I'm not sure this is a good idea.
I think this is a reasonable optimization
The client requirement is odd in comparison to MASQUE / CONNECT-UDP which says "client can risk sending datagrams before getting a 200 response, a different response means that datagrams will be discarded". What is the motivation for the requirement in WebTransport? If you need some kind of ordering guarantees, then stream IDs provide that.
Discussed at IETF 110. There were no objections to buffering (with some limits), so I think we should go ahead and add it.
After the client initiates the WebTransport session by sending a CONNECT request, the server sends a 200 response and is free to create streams. This means that a server-initiated stream may arrive prior to the CONNECT response. Is the client able to infer that the session was successfully established, or does the client need to buffer this stream until it receives a proper response?
Since there are no ordering guarantees across streams on the receiver side, I'd say you have to buffer until the 200 is processed.
I agree with Lucas here. We also had a similar problem in QuicTransport (server has to buffer streams before checking the origin), and we handled it by buffering.
Discussed at IETF 110. There were no objections to buffering (with some limits), so I think we should go ahead and add it.

Revised text:
This document Both <ins> 7.5. The following entry is added to the "HTTP/3 Error Code" registry established by HTTP3: H3_WEBTRANSPORT_BUFFERED_STREAM_REJECTED 0x3994bd84 WebTransport data stream rejected due to lack of associated session. This document. </ins>
Original text:
encoded using the QUIC variable length integer scheme described in RFC9000.  4.1. Once established, both endpoints can open unidirectional streams.

Reviewer comments:
The H3 draft is light on error handling guidance. There are number of cases for bad session IDs: The session ID is not a client initiated bidirectional stream ID The session ID refers to a stream that did not perform a WebTransport handshake The session ID refers to a stream that has been closed or reset Presumably there is no error when a DATAGRAM arrives with a bad session id -- you just drop it? For streams, perhaps HTTPIDERROR is appropriate? Issues and both refer to cases where you receive a session ID that has not been created yet. Best to keep the discussion there, but it's likely we want to allow clients/servers to buffer some of these at their own discretion rather than require an error.
For 1, I think it should be an error. For 2, we may want to clarify that the headers should be already known at that point, but it should be an error. For 3, I am not sure how to enforce this without running into potential race conditions, so we may want to leave those as-is. As for the datagrams, I think h3-datagram draft should handle this.
Thinking about 2 more, I think there's also a race condition in which a data stream could be received between the stream being open and headers being processed. I'll write up a PR for 1.
I think for 2, I meant the ID refers to a stream where the headers were known but it was not a CONNECT stream.
Discussed at IETF 111. Sense of the room for MUST close for 1, MAY close in other scenarios.

Revised text:
encoded using the QUIC variable length integer scheme described in RFC9000. <ins> If at any point a session ID is received that cannot a valid ID for a client-initiated bidirectional stream, the recepient MUST close the connection with an H3_ID_ERROR error code. </ins> 4.1. Once established, both endpoints can open unidirectional streams.
Original text:
set to "webtransport", the HTTP/3 server can check if it has a WebTransport server associated with the specified ":authority" and ":path" values.  If it does not, it SHOULD reply with status code 404 <del> (Section 15.5.4, HTTP).  If it does, it MAY accept the session by replying with a 2xx series status code, as defined in Section 15.3 of HTTP.  The WebTransport server MUST verify the "Origin" header to </del>  ensure that the specified origin is allowed to access the server in <del> question. </del>  From the client's perspective, a WebTransport session is established when the client receives a 2xx response.  From the server's

Reviewer comments:
In URL, it was suggested that 403 status code should be used when Origin verification fails.
Thank you for suggestions! Applied.
Thank you for reviews! If this looks good can someone merge this?
Looking good, thank you! Added a few suggestions to cause it to generate links to the actual sections referenced, even if it makes it a little more repetitive.Approved modulo one small change

Revised text:
set to "webtransport", the HTTP/3 server can check if it has a WebTransport server associated with the specified ":authority" and ":path" values.  If it does not, it SHOULD reply with status code 404  <ins> (Section 15.5.5 of HTTP).  When the request contains the "Origin" header, the WebTransport server MUST verify the "Origin" header to </ins> ensure that the specified origin is allowed to access the server in  <ins> question.  If the verification fails, the WebTransport server SHOULD reply with status code 403 (Section 15.5.4 of HTTP).  If all checks pass, the WebTransport server MAY accept the session by replying with a 2xx series status code, as defined in Section 15.3 of HTTP. </ins> From the client's perspective, a WebTransport session is established when the client receives a 2xx response.  From the server's
Original text:
A research challenge would be the optimization of the NFV service function chaining, considering a virtualized infrastructure and other SATCOM specific functions, to guarantee an efficient radio usage and <del> easy-to-deploy SATCOM services. </del>  5.3.

Reviewer comments:
I have no idea what this section means. Virtualised antennas? virtualised reflectors? Good luck with that. chin-nfvrg-cloud-5g-core-structure-yang referring to an expired -00 internet-draft does not add credibility.
MJM : But on the virtualization comment: we had presentations in the group on NFV (network virtualization) with NC for satellites. I am sure that the authors of this work could add to Lloyd’s comments on that section.
We have added a research challenge and changed the title of section in PR . The section aims at identifying research challenge related to the interaction between NC and virtualization (function chaining, buffer management, etc).

Revised text:
A research challenge would be the optimization of the NFV service function chaining, considering a virtualized infrastructure and other SATCOM specific functions, to guarantee an efficient radio usage and  <ins> easy-to-deploy SATCOM services.  Moreover, another challenge related to a virtualized SATCOM terminals is the management of limited buffered equipments. </ins> 5.3.
Original text:
5. <del> This document discuses some opportunities to introduce these </del>  techniques at a wider scale in satellite telecommunications systems. Even though this document focuses on satellite systems, it is worth

Reviewer comments:
First sentence, the use of "these techniques" is ambiguous. Which techniques?
Thanks. Updated in PR

Revised text:
5.  <ins> This document discuses some opportunities to introduce coding </ins> techniques at a wider scale in satellite telecommunications systems. Even though this document focuses on satellite systems, it is worth
Original text:
An endpoint uses a frame (type=0x04) to abruptly terminate the sending part of a stream. <del> After sending a , an endpoint ceases transmission and retransmission of frames on the identified stream.  A receiver of can discard any data that it already received on that stream. </del>  The frame defines the following fields:

Reviewer comments:
Reset stream doesn't cease retransmission.
retransmission of WTSTREAM frames on the identified stream. A receiver of WTRESET_STREAM can discard any data that it already received on that stream." This is using TCP and should not talk about ceasing retransmissions.
Very good point! Will clean up

Revised text:
An endpoint uses a frame (type=0x04) to abruptly terminate the sending part of a stream.  <ins> After sending a , an endpoint ceases transmission of frames on the identified stream.  A receiver of can discard any data that it already received on that stream. </ins> The frame defines the following fields:
Original text:
With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further <del> privacy concerns. </del>  Importantly, the sequence number makes it possible for a passive attacker to correlate packets across CID changes.  Thus, even if a

Reviewer comments:
Based on URL
Thanks!
Martin wrote: URL LGTM. I would strike ", if these privacy properties are important in a given deployment" from the acknowledgments section (which is an odd place for the accompanying statement. I would add an explicit note about the lack of CID update making this unsuitable for mobility scenarios. That's a common use case for this sort of mechanism, but this design lacks any defense against linkability. >

Revised text:
With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further  <ins> privacy concerns.  The lack of a CID update mechanism makes this extension unsuitable for mobility scenarios where correlation must be considered. </ins> Importantly, the sequence number makes it possible for a passive attacker to correlate packets across CID changes.  Thus, even if a
Original text:
Connection Identifiers for DTLS 1.2 <del> draft-ietf-tls-dtls-connection-id-07 </del>  Abstract

Reviewer comments:
We incorrectly put a normative reference on the RRC draft in the DTLS 1.2 CID draft.
I lost somehow the track on that RRC and the discussion around it. The referred document mentions: and I would assume, that a on-path adversary could black hole traffic in both directions, even without CID. Not only message sent to a peer could be dropped, it would also be easy to drop a message sent back from that peer (at least, if the route back is on the same path). I would also assume, that a on-path adversary, which is able to change the source address, would also be able to change the destination address. So a simple traffic redirect will also be possible even without CID. In my opinion, the only threat left, which is caused by the usage of a CID, would be a DDoS attack using amplified traffic towards third party. For that it seems to be most important to throttle the traffic by limiting the number and size of messages until the address is verified. Though such a DDoS will be naturally less efficient, because the adversary has to wait for messages to change the sources-address, throttling would make it even more unattractive.

Revised text:
Connection Identifiers for DTLS 1.2  <ins> draft-ietf-tls-dtls-connection-id-latest </ins> Abstract
Original text:
1. <del> The Datagram Transport Layer Security (DTLS) protocol was designed for securing connection-less transports, like UDP.  DTLS, like TLS, starts with a handshake, which can be computationally demanding (particularly when public key cryptography is used).  After a successful handshake, symmetric key cryptography is used to apply </del>  data origin authentication, integrity and confidentiality protection. This two-step approach allows endpoints to amortize the cost of the initial handshake across subsequent application data protection. Ideally, the second phase where application data is protected lasts <del> over a longer period of time since the established keys will only need to be updated once the key lifetime expires. </del>  <del> In the current version of DTLS, the IP address and port of the peer </del>  are used to identify the DTLS association.  Unfortunately, in some cases, such as NAT rebinding, these values are insufficient.  This is a particular issue in the Internet of Things when devices enter

Reviewer comments:
This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

Revised text:
1.  <ins> The Datagram Transport Layer Security (DTLS) RFC6347 protocol was designed for securing connection-less transports, like UDP.  DTLS, like TLS, starts with a handshake, which can be computationally demanding (particularly when public key cryptography is used).  After a successful handshake, symmetric key cryptography is used to apply </ins> data origin authentication, integrity and confidentiality protection. This two-step approach allows endpoints to amortize the cost of the initial handshake across subsequent application data protection. Ideally, the second phase where application data is protected lasts  <ins> over a long period of time since the established keys will only need to be updated once the key lifetime expires. </ins>  <ins> In DTLS as specified in RFC 6347, the IP address and port of the peer </ins> are used to identify the DTLS association.  Unfortunately, in some cases, such as NAT rebinding, these values are insufficient.  This is a particular issue in the Internet of Things when devices enter
Original text:
an endpoint to use a globally constant length for such connection identifiers.  This can in turn ease parsing and connection lookup, for example by having the length in question be a compile-time <del> constant.  Implementations, which want to use variable-length CIDs, are responsible for constructing the CID in such a way that its length can be determined on reception.  Such implementations must still be able to send CIDs of different length to other parties. Note that there is no CID length information included in the record itself. </del>  In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session only.  There is no dedicated "CID update" message that allows new

Reviewer comments:
This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

Revised text:
an endpoint to use a globally constant length for such connection identifiers.  This can in turn ease parsing and connection lookup, for example by having the length in question be a compile-time  <ins> constant.  Such implementations MUST still be able to send CIDs of different length to other parties.  Implementations that want to use variable-length CIDs are responsible for constructing the CID in such a way that its length can be determined on reception.  Note that there is no CID length information included in the record itself. </ins> In DTLS 1.2, CIDs are exchanged at the beginning of the DTLS session only.  There is no dedicated "CID update" message that allows new
Original text:
record is found in DTLSInnerPlaintext.real_type after decryption. The CID value, cid_length bytes long, as agreed at the time the <del> extension has been negotiated. </del>  The encrypted form of the serialized DTLSInnerPlaintext structure.

Reviewer comments:
This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

Revised text:
record is found in DTLSInnerPlaintext.real_type after decryption. The CID value, cid_length bytes long, as agreed at the time the  <ins> extension has been negotiated.  Recall that (as discussed previously) each peer chooses the CID value it will receive and use to identify the connection, so an implementation can choose to always recieve CIDs of a fixed length.  If, however, an implementation chooses to receive different lengths of CID, the assigned CID values must be self-delineating since there is no other mechanism available to determine what connection (and thus, what CID length) is in use. </ins> The encrypted form of the serialized DTLSInnerPlaintext structure.
Original text:
5. Several types of ciphers have been defined for use with TLS and DTLS <del> and the MAC calculation for those ciphers differs slightly. </del>  <del> This specification modifies the MAC calculation defined in RFC6347 and RFC7366 as well as the definition of the additional data used with AEAD ciphers provided in RFC6347 for records with content type </del>  tls12_cid.  The modified algorithm MUST NOT be applied to records that do not carry a CID, i.e., records with content type other than tls12_cid.

Reviewer comments:
This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

Revised text:
5. Several types of ciphers have been defined for use with TLS and DTLS  <ins> and the MAC calculations for those ciphers differ slightly. </ins>  <ins> This specification modifies the MAC calculation as defined in RFC6347 and RFC7366, as well as the definition of the additional data used with AEAD ciphers provided in RFC6347, for records with content type </ins> tls12_cid.  The modified algorithm MUST NOT be applied to records that do not carry a CID, i.e., records with content type other than tls12_cid.
Original text:
The following fields are defined in this document; all other fields are as defined in the cited documents. <del> Value of the negotiated CID. </del>  1 byte field indicating the length of the negotiated CID. <del> The length (in bytes) of the serialised DTLSInnerPlaintext. </del>  The length MUST NOT exceed 2^14. Note "+" denotes concatenation.

Reviewer comments:
This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.

Revised text:
The following fields are defined in this document; all other fields are as defined in the cited documents.  <ins> Value of the negotiated CID (variable length). </ins> 1 byte field indicating the length of the negotiated CID.  <ins> The length (in bytes) of the serialised DTLSInnerPlaintext (two- byte integer). </ins> The length MUST NOT exceed 2^14. Note "+" denotes concatenation.