jiebi/CodeConvo huggingface dataset:
Code change:
Addressing this . NAME NAME PTAL
I am really growing to dislike these "here is the alert you must use" constructions. Are they necessary? A lot of this was born out of the deprecate TLS 1/1.1 RFC that spun this I-D off. I believe this is the thread back in mid-2019: URL spt

Related discussion:
text: 4. Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages. <del> If no other signature algorithms are available (for example, if the client does not send a signature_algorithms extension), the server MUST abort the handshake with a handshake_failure alert or select a different cipher suite. </del> <ins> If the client receives a ServerKeyExchange message indicating MD5 or SHA-1, then it MUST abort the connection with an illegal_parameter alert. </ins> 5. Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages. If a server receives a CertificateVerify message with MD5 or SHA-1 it <del> MUST abort the connection with handshake_failure or insufficient_security alert. </del> <ins> MUST abort the connection with an illegal_parameter alert. </ins> 6.
Code change:
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

Related discussion:
text: Connection racing: Happy Eyeballs V2 RFC8305 describes techniques for performing connection racing.  The Transport Services <del> Architecture implementation from I-D.ietf-taps-impl also describes how connections may race across interfaces and address families. In cases where clients have early data to send and want to minimize or avoid ticket re-use, unique tickets for each unique connection attempt are useful.  Moreover, as some servers may implement single-use tickets (and even session ticket encryption keys), distinct tickets will be needed to prevent premature ticket </del> <ins> Architecture implementation from TAPS also describes how connections may race across interfaces and address families.  In cases where clients have early data to send and want to minimize or avoid ticket re-use, unique tickets for each unique connection attempt are useful.  Moreover, as some servers may implement single-use tickets (and even session ticket encryption keys), distinct tickets will be needed to prevent premature ticket </ins> invalidation by racing. Connection priming: In some systems, connections may be primed or
Code change:
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

Related discussion:
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. <del> Clients may indicate to servers their desired number of tickets via the following "ticket_request" extension: </del> <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:
Code change:
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

Related discussion:
text: send more than 255 tickets to clients. Servers that support ticket requests MUST NOT echo "ticket_request" <del> in the EncryptedExtensions. </del> <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.
Code change:
.
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.

Related discussion:
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> <ins> WebTransport over HTTP/3 does not support 0-RTT. </ins> 3.4.
Code change:
.
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.

Related discussion:
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>
Code change:
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.

Related discussion:
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.
Code change:
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

Related discussion:
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> <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 <del> question. </del> <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
Code change:
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).

Related discussion:
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> <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.
Code change:
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

Related discussion:
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> <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:
Code change:
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. >

Related discussion:
text: With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further <del> privacy concerns. </del> <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
Code change:
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.

Related discussion:
text: Connection Identifiers for DTLS 1.2 <del> draft-ietf-tls-dtls-connection-id-07 </del> <ins> draft-ietf-tls-dtls-connection-id-latest </ins> Abstract
Code change:
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.

Related discussion:
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> <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 <del> over a longer period of time since the established keys will only need to be updated once the key lifetime expires. </del> <ins> over a long period of time since the established keys will only need to be updated once the key lifetime expires. </ins> <del> In the current version of DTLS, the IP address and port of the peer </del> <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
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <ins> and the MAC calculations for those ciphers differ slightly. </ins> <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> <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.
Code change:
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.

Related discussion:
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> <ins> Value of the negotiated CID (variable length). </ins> 1 byte field indicating the length of the negotiated CID. <del> The length (in bytes) of the serialised DTLSInnerPlaintext. </del> <ins> The length (in bytes) of the serialised DTLSInnerPlaintext (two- byte integer). </ins> The length MUST NOT exceed 2^14. Note "+" denotes concatenation.