jiebi/CodeConvo huggingface dataset:
Change:
8. QUIC allows the application to abruptly terminate (reset) individual <del> streams or the entire connection when an error is encountered.  These are referred to as "stream errors" or "connection errors" and are described in more detail in QUIC-TRANSPORT. </del> <ins> streams or the entire connection; see Sections 2.4 and 5.3 of QUIC- TRANSPORT.  These are referred to as "stream errors" or "connection errors" (see Section 11 of QUIC-TRANSPORT) and have associated error codes, but do not necessarily indicate a problem with the connection or either implementation.  For example, a stream can be reset if the requested resource is no longer needed. </ins> An endpoint MAY choose to treat a stream error as a connection error under certain circumstances.  Implementations need to consider the

Discussion:
The application may reset a stream, for example, when a browser tab is closed or when the pushed resource is found in cache. It might close the connection when the application is closed. These are not errors per se, even though the term "stream error" and "connection error" is used for these events, and they have an associated "error code".
Change:
aware of the fact that DTLS messages it transmits toward the media distributor are being tunneled to the key distributor. <del> The endpoint MUST include the </del> <ins> The endpoint MUST include a unique identifier in the </ins> <del> DTLS extension I-D.thomson-mmusic-sdp-uks in the </del> <ins> SDP RFC4566 attribute sent by the endpoint in both offer and answer RFC3264 messages as per I-D.ietf-mmusic-dtls-sdp.  Further, the endpoint MUST include this same unique identifier in the </ins> <del> message when establishing a DTLS association.  Likewise, the </del> <ins> DTLS extension I-D.ietf-mmusic-sdp-uks in the </ins> <del> SDP RFC4566 attribute MUST be included in SDP sent by the endpoint in both the offer and answer RFC3264 messages as per I-D.ietf-mmusic- dtls-sdp. </del> <ins> message when establishing a DTLS association. </ins> When receiving a

Discussion:
Changes for -07 of the tunnel draft include: Updated references Change status to informational Align terminology with newer UKS draft
LGTM
LGTM
Change:
as follows I-D.irtf-cfrg-hpke RFC8446: The hash used for the MLS transcript hash is the one referenced in <del> the ciphersuite name.  In the ciphersuites defined above, "SHA256" and "SHA512" refer to the SHA-256 and SHA-512 functions defined in SHS. </del> <ins> the ciphersuite name.  In the ciphersuites defined above, "SHA256", "SHA384", and "SHA512" refer to the SHA-256, SHA-384, and SHA-512 functions defined in SHS. </ins> It is advisable to keep the number of ciphersuites low to increase the chances clients can interoperate in a federated environment, <del> therefore the ciphersuites only inlcude modern, yet well-established </del> <ins> therefore the ciphersuites only include modern, yet well-established </ins> algorithms.  Depending on their requirements, clients can choose between two security levels (roughly 128-bit and 256-bit).  Within the security levels clients can choose between faster X25519/X448

Discussion:
I suggest that we consider including a ciphersuite that enables AES256 GCM with SHA384 and that for signatures ECDSA with P-384 (and SHA-384) is also permitted. The NSA restricts commercial applications to certain algorithms for applications that are used in or in coordination with the U.S. federal government and, from a general availability perspective, adding this could expand protocol use potential.
I presume you're thinking of here? I realize that the table specifies P-384 and SHA-384; is it your understanding that it forbids using bigger curves/hashes?
Both Suite B and alignment to the . The other options currently in the spec, size accounted for, do not align to requirements.
You didn't answer my question about forbidding the use of bigger curves/hashes. Would the cases you're interested in be covered by the AES-256 / SHA-512 / P-521 suite?
If this is needed for the reasons mentioned in the issue, I have no objections.
Change:
value.  This Destination Connection ID MUST be at least 8 bytes in length.  Until a packet is received from the server, the client MUST use the same Destination Connection ID value on all packets in this <del> connection.  This Destination Connection ID is used to determine packet protection keys for Initial packets. </del> <ins> connection. The Destination Connection ID field from the first Initial packet sent by a client is used to determine packet protection keys for Initial packets.  These keys change after receiving a Retry packet; see Section 5.2 of QUIC-TLS. </ins> The client populates the Source Connection ID field with a value of its choosing and sets the Source Connection ID Length field to

Discussion:
This is better defined elsewhere, but it doesn't hurt to repeat it.
Initial or Retry packet from the server, the client populates the Destination Connection ID field with an unpredictable value. This Destination Connection ID MUST be at least 8 bytes in length. Until a packet is received from the server, the client MUST use the same Destination Connection ID value on all packets in this connection. This Destination Connection ID is used to determine packet protection keys for Initial packets. I had understood that you changed keys for the later initial packets when DCID changed. No?
That is correct. I guess the confusion comes from the "This" in the last sentence. We should make clear which CID it is referring to.
Depends why it changed. Retry starts a new connection attempt, with a new DCID, and new Initial keys. But the Initial keys don't change when the server's Initial provides a new SCID.
Change:
Issuers are configured with Private and Public Key pairs, each denoted skI and pkI, respectively, used to produce tokens.  Each key <del> pair SHALL be generated as as specified in FIPS 186-4 DSS. </del> <ins> pair SHALL be generated as as specified in FIPS 186-4 DSS.  These key pairs MUST NOT be reused in other protocols. </ins> The key identifier for a keypair (skI, pkI), denoted "token_key_id", is computed as SHA256(encoded_key), where encoded_key is a DER-

Discussion:
diverges from . In the earlier section: In the latter, this approximates to: ... with no 0x0002.
I would be fine with adding a token type separator to the type2 variant. It's a simple enough change to make and deploy right now. NAME NAME thoughts?
NAME is there a reason the type 1 key ID needs 0x0001 concatenated to it?
We did this for separation between privacy pass and other potential uses of the same key. I don't remember exactly why we didn't do this for type2.
Had a call, proposing to make things consistent by removing the for Type 1, since it doesn't seem to add any benefit, since the token_input is already binding the protocol to the type and challenge. Also recommending adding more text (in security considerations) to make it very clear that keys ought to not be reused across protocols.
Change:
specified in I-D.ietf-mmusic-msid, Section 3.2, and its value stored. <del> Any "a=candidate" attributes MUST be parsed as specified in RFC5245, Section 4.3, and their values stored. Any "a=remote-candidates" attributes MUST be parsed as specified in RFC5245, Section 4.3, but their values are ignored. If present, a single "a=end-of-candidates" attribute MUST be parsed as specified in I-D.ietf-ice-trickle, Section 8.2, and its presence or absence flagged and stored. </del> Any "a=imageattr" attributes MUST be parsed as specified in RFC6236, Section 3, and their values stored.

Discussion:
Rewrite intro to be clearer Move table to appendix Fix some parsing instructions that were in the wrong place
LGTM (other than the little bad xml issue)
Change:
The HelloRetryRequest is the same as the ServerHello above but without the unnecessary sentinel Random value. <del> OPEN ISSUE: Does "server_hello_extensions" apply to "HelloRetryRequest"? </del> <ins> OPEN ISSUE: Should we define a "hello_retry_request_extensions" template element?  Or is this too far off the happy path to be worth optimizing? </ins> 4.

Discussion:
NAME Ping. This is the last thing blocking a refreshed cTLS draft.
Just missed this. LGTM
Change:
their definition.  When encoding a "static vector", its length prefix is omitted. <del> In addition to the static vectors implied by various template elements, "Extension.extension_data" is always static in cTLS if the extension is any type listed in Section 4.2 of RFC8446 except "padding".  cTLS implementations MUST be able to parse any of these extensions that the other party is permitted to send, but no other support is required. </del> For example, suppose that the cTLS template is: Then, the following structure:

Discussion:
In the case a cTLS handshake uses a self-delimiting extension (in additional extensions) that is not present in section 4.2 of RFC 8446, its length is always serialized. With this PR, the type of this extension can be stored in and its length can be omitted.
Change:
of the TLS handshake messages being integrated into the calculation of secrets, the inclusion of the QUIC transport parameters extension ensures that handshake and 1-RTT keys are not the same as those that <del> might be produced by a server running TLS over TCP.  However, 0-RTT keys only include the ClientHello message and might therefore use the same secrets.  To avoid the possibility of cross-protocol key synchronization, additional measures are provided to improve key separation. </del> <ins> might be produced by a server running TLS over TCP.  To avoid the possibility of cross-protocol key synchronization, additional measures are provided to improve key separation. </ins> The QUIC packet protection keys and IVs are derived using a different label than the equivalent keys in TLS. To preserve this separation, a new version of QUIC SHOULD define new labels for key derivation for packet protection key and IV, plus the <del> header protection keys. </del> <ins> header protection keys.  This version of QUIC uses the string "quic". Other versions can use a version-specific label in place of that string. </ins> <del> The initial secrets also use a key that is specific to the negotiated QUIC version.  New QUIC versions SHOULD define a new salt value used in calculating initial secrets. </del> <ins> The initial secrets use a key that is specific to the negotiated QUIC version.  New QUIC versions SHOULD define a new salt value used in calculating initial secrets. </ins> 10.

Discussion:
This includes the suggestion from NAME to remove the 0-RTT text. Plus some text explaining the choice of label.
Change:
same base name "2001:db8::2/3306/0/", hence full names for resources are "2001:db8::2/3306/0/5850", etc. <del> The CoAP RFC7252 iPATCH and FETCH methods RFC8132 enable accessing and updating parts of a resource or multiple resources with one request. </del> <ins> The CoAP RFC7252 iPATCH, PATCH, and FETCH methods RFC8132 enable accessing and updating parts of a resource or multiple resources with one request. </ins> This document defines two new media types, one using the JavaScript Object Notation (JSON) RFC8259 and one using the Concise Binary Object Representation (CBOR) RFC7049, that can be used with the CoAP iPATCH, PATCH, and FETCH methods for resources represented with the SenML data model.  The semantics of the new media types are the same <del> for the CoAP PATCH and iPATCH methods. </del> <ins> for the CoAP PATCH and iPATCH methods.  The rest of the document uses term "(i)PATCH" when referring to both methods. </ins> 2.

Discussion:
using "(i)PATCH" to refer to both PATCH methods Clarified defaulting rules Clarified name resolving rules Clarified use of "resource" Added note that application of Patch Packs is idempotent Removed "more details in RFC-AAA" from media type encoding considerations (there are no more details actually)
Change:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 3.

Discussion:
Resolve comments from Ben Smyth.
NAME can you please cut a new version of the draft?
Done. Revision -02 has been submitted.
I am getting a permission error when I try to set the tag for "draft-ietf-tls-external-psk-guidance-02". Everything else is done, and I have used my local file to submit the Internet-Draft. Please set the tag when you have a minute.
Change:
1001 <ins> [[The RFC Editor is requested to remove this editorial note at publication.]] This document uses a placeholder value for a system port pending IANA assignment which needs to be replaced with the finalized value at the time of publication.  Please apply the following replacement: "WEBPUSH-PORT" --> the assigned port value for "webpush" </ins>

Discussion:
Based on the IANA review: Update IANA Considerations to indicate the System Port 1001 is a suggestion Update inline references to 1001 to "TBD"
LGTM (I'll let you merge this one).
Change:
and UDP.  Below, we amend this description for other protocols (if applicable): <del> Relative niceness: for SCTP, this can be done using the primitive CONFIGURE_STREAM_SCHEDULER.SCTP described in section 4 of RFC8303. </del> <ins> Priority (Connection): for SCTP, this can be done using the primitive CONFIGURE_STREAM_SCHEDULER.SCTP described in section 4 of RFC8303. </ins> Timeout for aborting Connection: for SCTP, this can be done using the primitive CHANGE_TIMEOUT.SCTP described in section 4 of

Discussion:
Not many text fixes needed - quite a bit of text reflected the old choice of Priority anyway and wasn't correctly updated for Niceness :-)
At 8.1.2 you say lower values have higher priorities for connPrio. But later, at msgPrio, higher values have higher priority, and in the examples where you speak of the interaction of connPrio and msgPrio, you imply that higher means higher for both properties. Please check for consistency and clarify.
Lower values having higher priorities for connPrio is a remnant that we must have missed when we flipped this, e.g. PR which I don't know... too many iterations have mangled the text.
Aha, now I see what happened: following some more PRs, also , in PR , NAME re-introduced some text saying that sends on Connections with lower-priority values will be prioritized over sends on Connections with a higher-priority value. This reverses the logic for some part of the text - I suspect that NAME (very understandably!) forgot what happened and this created this mix. We have been editing these documents for way too long!
Fine with me. The max_prio problem can be addressed separately.
Change:
the frame.  These frames are explained in more detail in frame- formats. <del> The "Packets" column in frame-types does not form part of the IANA registry; see iana-frames.  This column lists the types of packets that each frame type could appear in, indicated by the following characters: </del> <ins> The "Pkts" column in frame-types lists the types of packets that each frame type could appear in, indicated by the following characters: </ins> Initial (packet-initial)

Discussion:
After considering this a little more it seems helpful to bring some of the special handling rules up into the summary. We don't really give up-front treatment of ack-eliciting, probing, and other important distinctions, so an extra column seemed useful. A table of this size just fits in the text format.
I had almost exactly those changes in a previous version. It was a near thing.
That is super helpful, and is the direction I was hoping for!
In Section Frame Types and Formats, there is a very useful summary of frame types by packet type. As a person with a CC and transport protocol interest, it would be really nice to have had a summary table of key properties that included whether each frame type is ack-eliciting; whether transmission is controlled by flow-control; and whether transmission is controlled by congestion-control. Is there any chance we can add an extra column say to this table?
The problem with the table is that it is already essentially the full width available to us. That makes the addition of more information quite difficult. The rules for most of these are simple enough that I'm not sure that the table is the best way to present it. That is: ack-eliciting: all except ACK, PADDING congestion-controlled: all except ACK flow controlled: only STREAM
I wouldn't want to mess-up the table format to include the info. However, it would be really nice to have the info in a compact way close to the table somehow so that readers quickly confirm this. Would a note below the table possibly work, saying just this?
Change:
5.3. <del> TBD. </del> <ins> A QUIC connection is a stateful interaction between a client and server, the primary purpose of which is to support the exchange of data by an application protocol.  Streams (streams) are the primary means by which an application protocol exchanges information. Each connection starts with a handshake phase, during which client and server establish a shared secret using the cryptographic handshake protocol QUIC-TLS and negotiate the application protocol. The handshake (handshake) confirms that both endpoints are willing to communicate (validate-handshake) and establishes parameters for the connection (transport-parameters). An application protocol can also operate in a limited fashion during the handshake phase.  0-RTT allows application messages to be sent by a client before receiving any messages from the server.  However, 0-RTT lacks certain key security guarantees.  In particular, there is no protection against replay attacks in 0-RTT; see QUIC-TLS. Separately, a server can also send application data to a client before it receives the final cryptographic handshake messages that allow it to confirm the identity and liveness of the client.  These capabilities allow an application protocol to offer the option to trade some security guarantees for reduced latency. The use of connection IDs (connection-id) allows connections to migrate to a new network path, both as a direct choice of an endpoint and when forced by a change in a middlebox.  migration describes mitigations for the security and privacy issues associated with migration. For connections that are no longer needed or desired, there are several ways for a client and server to terminate a connection (termination). </ins> 5.4.

Discussion:
URL now we know how many holes it takes to fill the Albert Hall. This section has existed for a long time as "TBD". No longer. It also takes the opportunity to explain a little bit about what 0-RTT is for.
Retry is there, but at one level higher up (confirms that endpoints are willing to communicate ({{validate-handshake}})).
So we have little diagrams for send and receive stream states. Any chance this section could include a state diagram and transitions for the overall connection state?
There's a lot of text in the transport draft that assumes you know what 0-RTT / early data are. The term "early data" occurs only once, and doesn't even appear until describing the 0-RTT packet type. The introductory sections should probably contain some high-level description of Early Data, then point off to TLS for more detailed considerations. Purely editorial -- nothing new needs to be specified, but an uninitiated reader will need some context. This could possibly be part of .
I didn't see any other TBDs in the draft -transport doc or an existing issue, so opening this for tracking purposes.
Whoops!
I noticed you didn't write anything about Retry. Was that intentional?
Change:
registries and their allocation policies (unchanged from RFC4346) are listed below. <del> TLS ClientCertificateType Identifiers Registry: Future values in the range 0-63 (decimal) inclusive are assigned via Standards Action RFC2434.  Values in the range 64-223 (decimal) inclusive are assigned via Specification Required RFC2434.  Values from 224-255 (decimal) inclusive are reserved for Private Use RFC2434. </del> TLS Cipher Suite Registry: Future values with the first byte in the range 0-191 (decimal) inclusive are assigned via Standards Action RFC2434.  Values with the first byte in the range 192-254

Discussion:
This PR includes CertificateRequest changes discussed at the TLS WG Interim: Removes certificate_types, which are no longer needed. Adds client cert selection by certificate extension values. This helps make CertificateRequest more specific and eliminate the need for the confusing "Choose a certificate" UI.
Change:
Most CSM Options are useful mainly as initial messages in the connection. <del> Both capability and settings options are cumulative, i.e., a Capability and Settings message does not invalidate a previously made capability indication or setting even if that is not repeated, and a capability message without any option is a no-operation (and can be used as such).  An option that is given might override a previous value for the same option; the option defines how to handle this, if </del> <ins> Both capability and settings options are cumulative.  A Capability and Settings message does not invalidate a previously sent capability indication or setting even if it is not repeated.  A capability message without any option is a no-operation (and can be used as such).  An option that is sent might override a previous value for the same option.  The option defines how to handle this case if </ins> needed. <del> Default values given below for CSM Options are not default values for the option (this would mean that an empty Capability and Settings message would set the option back to its default value).  Instead they give the base value for the Capability and Setting before any Capability and Settings message sends a modified value. </del> <ins> Base values are listed below for CSM Options.  These are the values for the Capability and Setting before any Capability and Settings messages sends a modified value. These are not default values for the option as defined in Section 5.4.4 in RFC7252.  A default value would mean that an empty Capability and Settings message would result in the option being set to its default value. </ins> Capability and Settings messages are indicated by the 7.01 code (CSM).

Discussion:
Consistent language for empty messages. Edits to Signaling section - including replacing Default Value in tables with Base Value for clarity.
Change:
TLS 1.2 or below.  Note that doing so would overwrite the downgrade signal for TLS 1.3 (see RFC8446, Section 4.1.3). <ins> The "ech_is_inner" is expected to have an empty payload.  If the payload is non-empty (i.e., the length of the "extension_data" field is non-zero) then the backend server MUST abort the handshake with an "illegal_parameter" alert. </ins> 8. Unlike most TLS extensions, placing the SNI value in an ECH extension

Discussion:
~It's sufficient to ignore it, I think.~ The backend server enforces the extension's emptiness.
Change:
Compute the updated path secrets. <del> Identify a node in the filtered direct path for which the local member is in the subtree of the non-updated child. </del> <ins> Identify a node in the filtered direct path for which the recipient is in the subtree of the non-updated child. </ins> Identify a node in the resolution of the copath node for which <del> this node has a private key. </del> <ins> the recipient has a private key. </ins> Decrypt the path secret for the parent of the copath node using the private key from the resolution node.

Discussion:
This PR adds two clarifications suggested by NAME Clarifying some antecedents in UpdatePath processing Explaining how the example trees can come about in practice