jiebi/CodeConvo huggingface dataset:
Change:
Change 404 to 406 Not Acceptable
Current text: >Upon receiving an extended CONNECT request with a field set to , the HTTP server checks if the identified resource supports WebTransport sessions. If the resource does not, the server SHOULD reply with status code 404 ({{Section 6.5.4 of !RFC7231}}). If it does, it MAY accept the session by replying with a 2xx series status code, as defined in Section 15.3 of {{!SEMANTICS=I-D.ietf-httpbis-semantics}}. The WebTransport server MUST verify the header to ensure that the specified origin is allowed to access the server in question. Originally posted by NAME in URL
The corresponding text in HTTP/3 appears to be: This is correct, though I am not sure how necessary it is.
Discussed in editor's call: 406 sounds good

Discussion:
Upon receiving an extended CONNECT request with a ":protocol" field set to "webtransport", the HTTP server checks if the identified resource supports WebTransport sessions.  If the resource does not, <del> the server SHOULD reply with status code 404 (Section 6.5.4 of RFC7231).  If it does, it MAY accept the session by replying with a </del> <ins> the server SHOULD reply with status code 406 (Section 15.5.7 of RFC9110).  If it does, it MAY accept the session by replying with a </ins> 2xx series status code, as defined in Section 15.3 of SEMANTICS.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question.
Change:
This is not a bad thing. In fact it's a deliberate choice. It might be worth noting the redundancy so people don't think we're a bit dim. We might also add that this padding is less tunable than h2 padding.
Do we actually need WT_PADDING, and if so, does it need to be in this document?
NAME do you remember why we deliberately chose to have this separate padding instead of just relying on the h2 padding?
I don't recall the specifics 18 months on. However, the basic problems are invariant. The different padding schemes offer different capabilities due to a bunch of different design trade-offs and inherent properties of each approach. h2 padding only applies to one hop, but WTPADDING would traverse intermediaries (because it is application data as far as they are concerned). Consequently, you might want to use WTPADDING if your goal is to protect against leaks on remote hops. This is because each operates on a different scope. WTPADDING doesn't get to be smaller than the minimum capsule size, but h2 padding can be any size. That means that a padding strategy is potentially more efficient in h2 as you need to include WTPADDING and its overheads. This is because the more padding integration in h2 is more complete, but also more complex. Finally, there are all the usual software engineering constraints. Maybe you have access to padding functions in your WT stack, but not the h2 stack.
Many thanks NAME Added a version of that to the padding section (noting that padding is a generic capsule being defined here, so others can use it even if not over HTTP/2).

Discussion:
between other HTTP datagrams and can also be used to provide protection against traffic analysis or for other reasons. <ins> Note that, when used with WebTransport over HTTP/2, the capsule exists alongside the ability to pad HTTP/2 frames (Section 10.7 of RFC9113).  HTTP/2 padding is hop-by-hop and can be modified by intermediaries, while the capsule traverses intermedaries.  The capsule is also constrained to be no smaller than the capsule overhead itself. </ins> The Padding field MUST be set to an all-zero sequence of bytes of any length as specified by the Length field.
Change:
The document currently mentions HTTP status code 200 explicitly, instead of following the usual convention of saying "any 2xx" status code. We already made this change in WebTransport over HTTP/3, we should do the same in this doc.
Ack, we're a bit mixed in the HTTP/2 document right now, will update so we're consistent everywhere.

Discussion:
WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. <del> A WebTransport session is established when the server sends a 200 </del> <ins> A WebTransport session is established when the server sends a 2xx </ins> response.  A server generates that response from the request header, not from the contents of the request.  To enable clients to resend data when attempting to re-establish a session that was rejected by a
Change:
Expand description of flow control and add additional notes NAME already wrote up a very nice overview of the layers we have, so added a little bit extra there and filled in the last little bit on limiting streams within a session to round everything out.
Document how MAXDATA interacts with the enclosing HTTP/2 flow control scheme Originally posted by NAME in URL
I tend to think we might want to have a section entirely on flow control since we've now got several layers: HTTP/2 connection level HTTP/2 stream for the CONNECT stream WTMAXDATA for the WT session Noting that this is different than the HTTP/2 layer's CONNECT stream, since we want to be able to indicate the sum of stream data separately from other control frames WTMAXSTREAMDATA for each WT stream And stream-count flow control HTTP/2 stream limits don't really apply once you've got the WT session up WTMAX_STREAMS limits stream counts within a WT session Just indicating the intended usage of each of these knobs would be helpful.
(From : Since QUIC's flow control credits work differently from H2, it may be worth explicitly stating how this works here.)
Chair notes from IETF 112 meeting: no one objected to proposal of resolving this by documenting how flow control works and pitfalls
Why do we need WTMAXDATA in first place? I thought that since we have flow control from the HTTP/2 side, we don't need it.
We want to be able to say "don't send me any more data on this stream" while still allowing control frames on that stream

Discussion:
HTTP/2 stream flow control, which limits the data on a single HTTP/2 stream.  For a WebTransport session, this includes all <del> capsules, including those that are exempt from session-level flow control. </del> <ins> capsules, including those that are exempt from WebTransport session-level flow control. </ins> WebTransport session-level flow control, which limits the total amount of stream data that can be sent or received on streams <del> within the WebTransport session. </del> <ins> within the WebTransport session.  Note that this does not limit other types of capsules within a WebTransport session, such as control messages or datagrams. </ins> WebTransport stream flow control, which limits data on individual streams within a session.

3.4.2. <ins> This document defines a capsule (WT_MAX_STREAMS) that allows each endpoint to limit the number of streams its peer is permitted to open as part of a WebTransport session.  There is a separate limit for bidirectional streams and for unidirectional streams.  Note that, unlike WebTransport over HTTP/3 WEBTRANSPORT-H3, because the entire WebTransport session is contained within HTTP/2 DATA frames on a single HTTP/2 stream, this limit is the only mechanism for an endpoint to limit the number of WebTransport streams that its peer can open on a session. 3.4.3. </ins> WebTransport over HTTP/2 uses several capsules for flow control, and all of these capsules define special intermediary handling as described in Section 3.2 of HTTP-DATAGRAM.  These capsules, referred
Change:
Suggest a column name. Deprecate the old connection_id codepoint.
NAME
We currently have an early allocation of the TLS extensiontype codepoint 53 that was allocated on 2019-07-02. An implementation of the draft at that time will no longer interoperate with the current specification due to changes in how the MAC inputs and AAD are laid out. If we want to allocate a new extensiontype value for the new semantics, we should tell IANA that there is an existing early allocation and, e.g., that it should be left to expire (and what version of the draft to use as a reference until it does), with a new codepoint to be allocated in its stead. We also have the option to direct IANA that "once this document is approved for publication, the early allocation will be deprecated and the following assignment will be made".
I think we should take your last option.
See suggestion inline, though even as-is this is probably enough to cause the right things to happen at IANA and the RPC.

Discussion:
10.1. <del> IANA is requested to add an extra column to the "TLS ExtensionType Values" registry to indicate whether an extension is only applicable to DTLS and to include this document as an additional reference for the registry. </del> <ins> IANA is requested to add an extra column named "DTLS-Only" to the "TLS ExtensionType Values" registry to indicate whether an extension is only applicable to DTLS and to include this document as an additional reference for the registry. </ins> 10.2. IANA is requested to allocate an entry to the existing "TLS ExtensionType Values" registry, for connection_id(TBD1) as described <del> in the table below. </del> <ins> in the table below.  Although the value 53 has been allocated by early allocation for a previous version of this document, it is incompatible with this document.  Once this document is approved for publication, the early allocation will be deprecated in favor of this assignment. </ins> Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document
Change:
Partly addresses
URL
Regarding: We could streamline that a bit: removing the affiliations (who knows which have become stale in the meantime?), and also Besides, is "task force" the right term? Would "QUIC CID design team" be a better designation? Robert Wilton has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Hi, I'm no DTLS expert, but I found the concepts/explanation in this document easy to follow. I was slightly confused by the requirement to encode the length in variable length CIDs, and had to read the relevant text a second time. As a suggestion, it might help if these two sentences were reworded the other way round: OLD: 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. NEW: Since the CID length information is not included in the record itself, implementations that want to use ... . One minor question. In the contributors, I noted that Jana is listed as being associated with Google, but it might be worth checking if that is still accurate. Regards. Rob

Discussion:
identifiers.  This can in turn ease parsing and connection lookup, for example by having the length in question be a compile-time constant.  Such implementations MUST still be able to send CIDs of <del> 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. </del> <ins> different length to other parties.  Since the CID length information is not included in the record itself, 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. </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
Change:
attempt at addressing Warren's concern about the use of "globally"
You're right, the "globally" seems to be used in the sense of a "programming language", so the scope is a peer and the CID emitted by this peer for other peers to be used, when the other peers sends records to the emitting peer. Maybe we find a better term than "globally" to describe that.
maybe "sitewide"?

Discussion:
Because each party sends the value in the "connection_id" extension it wants to receive as a CID in encrypted records, it is possible for <del> 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 constant.  Such implementations MUST still be able to send CIDs of different length to other parties.  Since the CID length information is not included in the record itself, 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. </del> <ins> an endpoint to use a deployment-specific 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 constant.  Such implementations MUST still be able to send CIDs of different length to other parties.  Since the CID length information is not included in the record itself, 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. </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
Change:
discussed in YUL. NAME
URL Still contains the content types removed in PR . alertwithcid(25) handshakewithcid(26) applicationdatawithcid(27) heartbeatwithcid(28) I guess, it should be updated towards PR ? tls12cid(25)
The PR can be found here: URL
The PR will fix it.
If you subscribe to the theory that DTLS has to mux with the realtime protocols, this takes a good slice of the remaining codepoints space. Though TLS has between 20 and 63, DTLS 1.3 takes 32-63 and the registration of 4 more would leave just 3: 29, 30, and 31. I submit that we might be better considering the TLS 1.3 record construction with a single codepoint. That would get us content type encryption and arbitrary padding as a secondary benefit. All for the modest cost of one octet.
If DTLS 1.3 used a demux prefix scheme like the one proposed , this should be no longer an issue.
Addressed in

Discussion:
records without knowing how long the Connection ID is. In order to allow a receiver to determine whether a record has CID or <del> not, connections which have negotiated this extension use new record types for all protected records. new-cid-content-types shows the record types to use: </del> <ins> not, connections which have negotiated this extension use a distinguished record type tls12_cid(25).  Use of this content type has the following two implications: The CID field is present The true content type is inside the encryption envelope, as described below. </ins> 5. <del> The CID value, when present, is included in the MAC calculation for the DTLS record.  The MAC algorithm described in Section 4.1.2.1 of RFC6347 and Section 6.2.3.1 of RFC5246 is extended as follows: </del> <ins> When CID is being used, the DTLSCompressed value is first wrapped along with the true content type and padding into a DTLSWrappedCompressed value prior to encryption.  The DTLSWrappedCompressed value is then encrypted. The value of DTLSCompressed.fragment The true content type. Padding, as defined in RFC8446. In addition, the CID value is included in the MAC calculation for the DTLS record as shown below.  The MAC algorithm described in Section 4.1.2.1 of RFC6347 and Section 6.2.3.1 of RFC5246 is extended as follows: </ins> 6.
Change:
This is pretty trivial, but the first use of CID in the draft isn't mated to the expanded "connection ID". Probably more seriously, that first mention is actually to cite a struct: The structure is called .

Discussion:
rebinding leads to connection failure, with the resulting cost of a new handshake. <del> This document defines an extension to DTLS to add a connection ID to the DTLS record layer.  The presence of the connection ID is </del> <ins> This document defines an extension to DTLS to add a connection ID (CID) to the DTLS record layer.  The presence of the connection ID is </ins> negotiated via a DTLS extension. 2.

The extension type is specified as follows. The extension_data field of this extension, when included in the <del> ClientHello, MUST contain the CID structure, which carries the CID which the client wishes the server to use when sending messages towards it.  A zero-length value indicates that the client is prepared to send with a connection ID but does not wish the server to use one when sending (alternately, this can be interpreted as the </del> <ins> ClientHello, MUST contain the ConnectionId structure, which carries the CID which the client wishes the server to use when sending messages towards it.  A zero-length value indicates that the client is prepared to send with a connection ID but does not wish the server to use one when sending (alternately, this can be interpreted as the </ins> client wishes the server to use a zero-length CID; the result is the same).

With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further <del> privacy concerns.  In order to prevent this, implementations SHOULD attempt to use fresh connection IDs whenever they change local addresses or ports (though this is not always possible to detect). </del> <ins> privacy concerns. </ins> Importantly, the sequence number makes it possible for a passive attacker to correlate packets across CID changes.  Thus, even if a
Change:
URL Still contains the content types removed in PR . alertwithcid(25) handshakewithcid(26) applicationdatawithcid(27) heartbeatwithcid(28) I guess, it should be updated towards PR ? tls12cid(25)
The PR can be found here: URL
The PR will fix it.

Discussion:
"ExtensionType Values" registry, defined in RFC5246, for connection_id(TBD) defined in this document. <del> IANA is requested to allocate the following new values in the "TLS ContentType Registry": alert_with_cid(25) handshake_with_cid(26) application_data_with_cid(27) heartbeat_with_cid(28) </del> <ins> IANA is requested to allocate tls12_cid(25) in the "TLS ContentType Registry". </ins>
Change:
To address URL
Thanks! This PR fixes the missing size of the introduced length.
I miss the hint for the size of . I would assume it's a 2 bytes value. Is that right? Is this information already in the document and have overseen it? Both introduce a special "length" and use different approaches to do so. One with extra definition, one with a included definition. Is this intended?
Fixed with

Discussion:
All other fields are as defined in the cited documents. The length (in bytes) of the serialised DTLSInnerPlaintext.  The <del> length MUST NOT exceed 2^14. </del> <ins> length MUST NOT exceed 2^14.  This field is of type uint16. </ins> 6.
Change:
Addresses URL
Thanks! This PR clarifies the used cid value.
In my opinion, it's the actual cid on the record header, not the negotiated cid, even if both are intended to be the same. Therefore it is . Or has this changed? Is the MAC now extended by the negotiated CID?
Fixed with

Discussion:
<del> Value of the negotiated CID. </del> <ins> The DTLSCiphertext.cid value. </ins> <del> 1 byte field indicating the length of the negotiated CID. </del> <ins> 1 byte field indicating the length of the DTLSCiphertext.cid. </ins> All other fields are as defined in the cited documents.
Change:
URL If this PR is postponed to that date (12. April), may be the final values could be used. We have received a request for early code-point assignment of values for draft-ietf-tls-dtls-connection-id-04. We believe that only editorial changes are pending. Please respond to this list of you have concerns about these assignments by April 12, 2019. Thanks, Joe, Sean and Chris

Discussion:
To allow a receiver to determine whether a record has a CID or not, connections which have negotiated this extension use a distinguished <del> record type tls12_cid(25).  Use of this content type has the </del> <ins> record type tls12_cid(TBD2).  Use of this content type has the </ins> following three implications: The CID field is present and contains one or more bytes.

produce the final DTLSCiphertext. The outer content type of a DTLSCiphertext record carrying a CID <del> is always set to the value 25 (tls12_cid).  The actual content type of the record is found in DTLSInnerPlaintext.real_type after decryption. </del> <ins> is always set to tls12_cid(TBD2).  The real content type of the record is found in DTLSInnerPlaintext.real_type after decryption. </ins> The CID value, cid_length bytes long, as agreed at the time the extension has been negotiated.

IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for <del> connection_id(TBD) defined in this document. </del> <ins> connection_id(TBD1) defined in this document. </ins> <del> IANA is requested to allocate tls12_cid(25) in the "TLS ContentType </del> <ins> IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType </ins> Registry".
Change:
... IANA consideration section based on issue raised by Sean (see URL) ... Security consideration section based on issue raised by Thomas (see URL)
This PR aims to replace PR & PR
A couple of tweaks are needed for the IANA Considerations Section: Based on input from the IANA TLS DEs, it seems like we need a column added to the TLS ExtensionType Values registry to indicate that an extension is DTLS-only. The column values for TLS 1.3 and Recommended are missing. Suggest blank for TLS 1.3 and N for Recommended. Add a note to say that connectionid is DTLS1.2 only. Add instructions for IANA to assign "Y" to DTLS-okay column for tls12cid content type.
That results in "DTLS only" for TLS extensions and "DTLS-OK" for TLS parameters. I'm not sure, if that just represents more the "current" usage than the "logic" behind it. I would be afraid, that this will hold up other ideas, which doesn't match that "only for extensions / ok for parameters" pattern.
I am not sure what "DTLS-OK" for TLS parameters means
For TLS parameters there's a column "DTLS-OK", And for TLS extensions a column "DTLS only". Does this explain my comment?
We added text to the draft-ietf-tls-dtls-connection-id-06 about the IANA consideration section. I believe this issue is closed.

Discussion:
multi-homing or mobility, the use of the CID is not different to the use of the 5-tuple. <ins> An on-path adversary can also black-hole traffic or create a reflection attack against third parties because a DTLS peer has no means to distinguish a genuine address update event (for example, due to a NAT rebinding) from one that is malicious.  This attack is of concern when there is a large asymmetry of request/response message sizes. </ins> With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further privacy concerns.  The lack of a CID update mechanism makes this

IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for <del> connection_id(TBD1) defined in this document. </del> <ins> connection_id(TBD1) as described in the table below.  IANA is requested to add an extra column to the TLS ExtensionType Values registry to indicate whether an extension is only applicable to DTLS. Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document describes an extension for DTLS 1.2 only; it is not to TLS (1.3). The DTLS 1.3 functionality is described in I-D.ietf-tls-dtls13. </ins> IANA is requested to allocate tls12_cid(TBD2) in the "TLS ContentType <del> Registry". </del> <ins> Registry".  The tls12_cid ContentType is only applicable to DTLS 1.2. </ins>