jiebi/CodeConvo huggingface dataset:
Change:
Make the variable names of various secrets correspond to the labels used for Derive-Secret(). This is not a wire format change, but just a change in the internal variable names.
NAME NAME you see any misses here?
The legends for the message flows still say "trafficsecretN" for the "[]" parts. Also, "Updating Traffic Keys and IVs" still uses "trafficsecretN" in the formula and text prior to it.
In the key schedule

Discussion:
0-RTT data to ensure that an application is always aware that it is sending or receiving data that might be replayed. <del> The same warnings apply to any use of the early_exporter_secret. </del> <ins> The same warnings apply to any use of the early_exporter_master_secret. </ins> The remainder of this document provides a detailed description of TLS.

Once the handshake is complete, it is possible for either side to update its sending traffic keys using the KeyUpdate handshake message defined in key-update.  The next generation of traffic keys is <del> computed by generating client_/server_traffic_secret_N+1 from client_/server_traffic_secret_N as described in this section then re- deriving the traffic keys as described in traffic-key-calculation. </del> <ins> computed by generating client_/server_application_traffic_secret_N+1 from client_/server_application_traffic_secret_N as described in this section then re-deriving the traffic keys as described in traffic- key-calculation. </ins> <del> The next-generation traffic_secret is computed as: </del> <ins> The next-generation application_traffic_secret is computed as: </ins> <del> Once client/server_traffic_secret_N+1 and its associated traffic keys have been computed, implementations SHOULD delete client_/ server_traffic_secret_N and its associated traffic keys. </del> <ins> Once client/server_application_traffic_secret_N+1 and its associated traffic keys have been computed, implementations SHOULD delete client_/server_application_traffic_secret_N and its associated traffic keys. </ins> 7.3.

The exporter value is computed as: <del> Where Secret is either the early_exporter_secret or the exporter_secret.  Implementations MUST use the exporter_secret unless explicitly specified by the application.  The early_exporter_secret is define for use in settings where an exporter is needed for 0-RTT data.  A separate interface for the early exporter is RECOMMENDED, especially on a server where a single interface can make the early exporter inaccessible. </del> <ins> Where Secret is either the early_exporter_master_secret or the exporter_master_secret.  Implementations MUST use the exporter_master_secret unless explicitly specified by the application.  The early_exporter_master_secret is define for use in settings where an exporter is needed for 0-RTT data.  A separate interface for the early exporter is RECOMMENDED, especially on a server where a single interface can make the early exporter inaccessible. </ins> If no context is provided, the context_value is zero-length. Consequently, providing no context computes the same value as
Change:
RFC 7301 defines the ALPN extension and defined a new alert "noapplicationprotocol". TLS 1.3 uses ALPN but currently misses the alert in Section 6.
URL You also need to add it to the Error Alerts section with a description.

Discussion:
Sent by servers when a client certificate is desired but none was provided by the client. <ins> Sent by servers when a client advertises protocols that the server does not support. </ins> New Alert values are assigned by IANA as described in iana- considerations.
Change:
Note that I'm not entirely convinced we need the GCM reference because RFC 5116, which is referenced in B.4 for the suites, includes a reference to it.
ID nits complains of the following unused references: == Unused Reference: 'AES' is defined on line 4147, but no explicit reference was found in the text == Unused Reference: 'GCM' is defined on line 4305, but no explicit reference was found in the text == Unused Reference: 'PKCS6' is defined on line 4339, but no explicit reference was found in the text == Unused Reference: 'PKCS7' is defined on line 4342, but no explicit reference was found in the text == Unused Reference: 'RFC4279' is defined on line 4371, but no explicit reference was found in the text == Unused Reference: 'RFC4507' is defined on line 4392, but no explicit reference was found in the text == Unused Reference: 'RFC5054' is defined on line 4401, but no explicit reference was found in the text == Unused Reference: 'RFC5746' is defined on line 4425, but no explicit reference was found in the text == Unused Reference: 'RFC5878' is defined on line 4436, but no explicit reference was found in the text == Unused Reference: 'RFC7366' is defined on line 4479, but no explicit reference was found in the text
Looking at the editor's copy only AES and GCM remain. I think we can safely remove both because those references are picked up but the cipher suite definitions.
Strike that since we're defining some suites we need to include GCM and move it normative. We can drop the AES reference because it's picked up by the GCM reference.

Discussion:
In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the <del> TLS_AES_128_GCM_SHA256 cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256 cipher suites. (see cipher-suites) </del> <ins> TLS_AES_128_GCM_SHA256 GCM cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 GCM and TLS_CHACHA20_POLY1305_SHA256 RFC7539 cipher suites.  (see cipher-suites) </ins> A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for
Change:
Is it strictly necessary to include the following in the TLS1.3 draft: Finally, this document obsoletes the TLS HashAlgorithm Registry and the TLS SignatureAlgorithm Registry, both originally created in [RFC5246]. IANA [SHALL update/has updated] the TLS HashAlgorithm Registry to list values 7-223 as “Reserved” and the TLS SignatureAlgorithm Registry to list values 4-223 as “Reserved”. If this text wasn't in the TLS1.3 draft everything would be fine right? If that's the case, then this text from s10 should be moved to .
Sorry, I'm not following the issue. I'm happy to move it out, though.
It kind of seems like the move of registries should be done atomically, which is ~guaranteed by doing it in the same document, but could still be done atomically if the two documents are advanced at the same time. (I, like ekr, am not really clear on what the issue is, though.)
I guess I see reserving the remaining values as essentially slamming the door on future assignments. Was that the intent? spt
I should have also added that URL already includes a paragraph indicating that Compression Method Identifiers, HashAlgorithm, and SignatureAlgorithm are obsoleted by TLS1.3; adds a note to the registries indicating as much. spt
My understanding was that yes, "don't look here, go look over there" was the idea. Any new allocation would need to go in the SignatureScheme registry, regardless of whether it also ended up in the HashAlgorithm or SignatureAlgorithm registry as well for someone's convenience. Since you have to go to the new registry anyway, it doesn't seem like there would be value in also adding it to the old/deprecated registry.
Okay that makes sense and it explains why the values in the Compression Method Identifiers isn’t also “reserved”. I guess I’m off the mind that this para could safely be move to the IANA draft.
Specially move the text to s13 of .

Discussion:
in signature-algorithms.  The following values SHALL be marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. <del> Finally, this document obsoletes the TLS HashAlgorithm Registry and the TLS SignatureAlgorithm Registry, both originally created in RFC5246.  IANA [SHALL update/has updated] the TLS HashAlgorithm Registry to list values 7-223 as "Reserved" and the TLS SignatureAlgorithm Registry to list values 4-223 as "Reserved". </del>
Change:
NAME and NAME had an editors' discussion (see URL) about how to specify the handling of ICE restarts in the context of Trickle ICE. One possible approach would be to send a new ufrag and pwd without triggering a full offer/answer exchange, because Trickle (and ICE itself) can be used with application protocols that are not tied to O/A. There is an SDP dependency on the a= line, but we've disengaged Trickle ICE from SDP, too. Also, if the sender doesn't include a media description then a new offer might not be necessary anyway. I'm hoping that NAME can propose text...
At IETF 95, there was support for explicitly indicating which ufrag/pwd the candidate applies to. But the specifics are signaling-specific. So perhaps we should just update the text to say "SHOULD be explicit" in some way. URL
I am fine also adding to the spec a sample way of labeling them (the way Trickle for SIP does) Emil , Peter Thatcher EMAIL wrote:
By the way, this came up in the JSEP work recently, that with ICE restarts being roll-back-able, the explicit ufrag is really needed for edge cases there. We think the right solution is using a ufrag on the JS object, not on the SDP (since we also need to include it on the end of candidates message, and since it would look weird being duplicated in so many lines in the current remote description).
It looks like we already have a paragraph that indicates an implementation should have an explicit ufrag (or other correlation). Great! So, I made a PR to add some examples: URL
resolved

Discussion:
Also, candidate trickling needs to be correlated to a specific ICE negotiation session, so that if there is an ICE restart, any delayed updates for a previous session can be recognized as such and ignored <del> by the receiving party. </del> <ins> by the receiving party.  For example, applications that choose to signal candidates via SDP may include a ufrag value in the SDP that represents candidates (such as "a=candidate ... ufrag abc").  Or as another exmaple, WebRTC implementations may include a ufrag in the JavaScript objects that represent candidates. </ins> One important aspect of Vanilla ICE is that connectivity checks for a specific foundation and component are attempted simultaneously by
Change:
…S and COMMENT) On December 18, 2020 at 10:42:24 AM, Pascal Thubert (pthubert) (pthubert=EMAIL) wrote: Hello Michael and all: Yes, I expected policies that would validate the right of a Leaf to participate to a DODAG ,or to remap the information from the leaf (could be the RPI, the opaque field in the EARO, or the 6-tuple) into an RPI. Yes, as I said in my response I thought it was quite common. I'm surprised to find little art to quote. Cool, we're good! Pascal Roll mailing list EMAIL URL Roll mailing list EMAIL URL

Discussion:
Terminology defined in RFC7102 applies to this document: LLN, RPL, RPL domain and ROLL. <ins> Consumed: A Routing Header is consumed when the Segments Left field is zero, which indicates that the destination in the IPv6 header is the final destination of the packet and that the hops in the Routing Header have been traversed. </ins> RPL Leaf: An IPv6 host that is attached to a RPL router and obtains connectivity through a RPL Destination Oriented Directed Acyclic Graph (DODAG).  As an IPv6 node, a RPL Leaf is expected to ignore a

storing network on traffic that is leaving the LLN, but this document should not preclude such a future innovation.  It should just be noted that an incoming RH3 must be fully consumed, or very carefully <del> inspected. </del> <ins> inspected to match a policy that applies to this network and is correctly processed by the leaves. </ins> The RPI, if permitted to enter the LLN, could be used by an attacker to change the priority of a packet by selecting a different
Change:
RPL was missing a good definition of a LEAF. this clarifies.
updated the deprecated ref to rul draft

Discussion:
Terminology defined in RFC7102 applies to this document: LLN, RPL, RPL Domain and ROLL. <del> RPL-aware-node: A device which implements RPL.  Please note that the device can be found inside the LLN or outside LLN. </del> <ins> RPL Leaf: An IPv6 host that is attached to a RPL router and obtains connectivity through a RPL Destination Oriented Directed Acyclic Graph (DODAG).  As an IPv6 node, a RPL Leaf is expected to ignore a consumed Routing Header and as an IPv6 host, it is expected to ignore a Hop-by-Hop header.  It results that a RPL Leaf can correctly receive a packet with RPL artifacts.  On the other hand, a RPL Leaf is not expected to generate RPL artifacts or to support IP-in-IP encapsulation.  For simplification, this document uses the standalone term leaf to mean a RPL leaf. </ins> <del> RPL-Aware-Leaf(RAL): A RPL-aware-node which is a leaf of a (Destination Oriented Directed Acyclic Graph) DODAG. </del> <ins> RPL-aware-node (RAN): A device which implements RPL.  Please note that the device can be found inside the LLN or outside LLN. RPL-Aware-Leaf(RAL): A RPL-aware-node that is also a RPL Leaf. </ins> RPL-unaware-node: A device which does not implement RPL, thus the device is not-RPL-aware.  Please note that the device can be found inside the LLN. <del> RPL-Unaware-Leaf(RUL): A RPL-unaware-node which is a leaf of a (Destination Oriented Directed Acyclic Graph) DODAG. </del> <ins> RPL-Unaware-Leaf(RUL): A RPL-unaware-node that is also a RPL Leaf. </ins> 6LoWPAN Node (6LN): RFC6775 defines it as: "A 6LoWPAN node is any host or router participating in a LoWPAN.  This term is used when

The final node should be able to remove one or more IPv6-in-IPv6 headers which are all addressed to it.  The final node does not process the RPI, the node ignores the RPI.  Further details about <del> this are mentioned in I-D.thubert-roll-unaware-leaves, which specifies RPL routing for a 6LN acting as a plain host and not being aware of RPL. </del> <ins> this are mentioned in I-D.ietf-roll-unaware-leaves, which specifies RPL routing for a 6LN acting as a plain host and not being aware of RPL. </ins> The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to zero in order to aid in compression RFC6437.
Change:
Section 4.2 says "Editors SHOULD make pull requests for all substantial changes rather than committing directly to the "master" branch of the repository." Adding a short explanation will help make this more likely to happen.

Discussion:
changes from a fork (or any branch) into their copy. Editors SHOULD make pull requests for all substantial changes rather <del> than committing directly to the "master" branch of the repository. Pull requests that address substantive issues SHOULD mention the issue they address in the opening comment. </del> <ins> than committing directly to the "master" branch of the repository.  A pull request creates an artifact that records the reasons for changes and provides other contributors with an opportunity to review the change.  Pull requests that address substantive issues SHOULD mention the issue they address in the opening comment. </ins> This document assumes that there is a unified effort on a document, all concentrated on a git "master" branch.  More
Change:
For , but not all of it.
Some working groups use GitHub to manage changes to charters or other working group materials, like agendas and presentations for sessions. I'd suggest that no great amount of detail is needed because these aren't the primary focus of the document, but it probably should include at least a passing mention of these uses and acknowledge that they are permitted.
Discussed in Singapore; MT to add text.
Closed in .
How this fits into existing processes is something that needs more thorough investigation if we're publishing an RFC on this.
Discussed in Singapore; no objections, merged, and closing.

Discussion:
This document is meant as a supplement to existing Working Group practices.  It provides guidance to Working Group chairs and participants on how they can best use GitHub within the framework <del> established by RFC 2418 RFC2418.  The small number of rules in this document are there to ensure common usage patterns between Working Groups and to avoid issues that have been encountered in the past. </del> <ins> established by RFC 2418 RFC2418.  This document aims to establish norms that reduce the variation in usage patterns between different Working Groups and to avoid issues that have been encountered in the past. </ins> A companion document, GH-CONFIG, describes administrative processes that support the practices described in this document.

For both sets of users, this document aims to provide some amount of advice on practices that have proven to be effective. <ins> This document only aims to address use of GitHub in developing documents.  Working Groups could choose to use the tool to aid in managing their charter or session materials such as agendas, minutes, and presentations.  Though the advice here might apply more broadly, using GitHub to manage other material is out of scope for this document. </ins> 1.5. The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are
Change:
This consolidates text about notices in the "communicating policies" section, which seems most appropriate.
Thanks!

Discussion:
GitHub prominently links to the CONTRIBUTING file on certain pages. This file SHOULD be used in preference to the README for information <del> that new contributors need.  A link to the CONTRIBUTING file from the README is advised. </del> <ins> that new contributors need.  The README SHOULD contain a link to the CONTRIBUTING file. </ins> In addition to Working Group policies, notices on repositories MUST <del> include citations for BCPs 78 and 79 (COPYRIGHT, IPR) and other IETF contribution policies.  A copy or reference to the IETF Note Well [6] is ideal. </del> <ins> include citations for the IETF Note Well [6]. </ins> 3.

A document editor can still use GitHub independently for documents that they edit, even if the Working Group does not expressly choose <del> to use GitHub.  Any such public repository MUST follow the guidelines in BCPs 78 and 79 (COPYRIGHT, IPR) and bear notices to that effect. This recognizes that editors have traditionally chosen their own methods for managing the documents they edit but preserves the need for contributors to understand their obligations with respect to IETF processes. </del> <ins> to use GitHub.  Any such public repository MUST follow the IETF Note Well and bear notices; see notices.  This recognizes that editors have traditionally chosen their own methods for managing the documents they edit but preserves the need for contributors to understand their obligations with respect to IETF processes. </ins> 3.2.
Change:
LGTM.
This is a very important section, but I found it to be a little muddy. In particular, the directionality of the phrase A is compatible with B was unclear. An example would help here, I think.

Discussion:
Version compatibility is not symmetric: it is possible for version A to be compatible with version B and for B not to be compatible with A.  This could happen for example if version B is a strict superset <del> of version A. </del> <ins> of version A: if version A includes the concept of streams and STREAM frames, and version B includes the concepts of streams and tubes along with STREAM and TUBE frames, then A would be compatible with B but B would not be compatible with A. </ins> Note that version compatibility does not mean that every single possible instance of a first flight will succeed in conversion to the
Change:
Section 2.5 says unconditionally that the client chooses the most compatible version. This isn't right, because the most compatible version isn't what it is looking to end up on. What the client should choose is probably the most compatible version of those that are compatible (directionality ?) with its most preferred version.
Rereading this, I think the directionality is correct in the existing text. But perhaps we could figure out better wording.
LGTM with the following edits.

Discussion:
2.5. <del> The client's first connection attempt SHOULD be made using the version that the server is most likely to support.  The client selects the version most likely to be supported from the versions that are compatible with the client's most preferred version. Without additional information this could mean selecting the oldest </del> <ins> When the client picks its original version, it will try to avoid incompatible version negotiation to save a round trip.  Therefore, the client SHOULD pick an original version to maximize the combined probability that both: The server knows how to parse first flights from the original version. The original version is compatible with the client's preferred version. Without additional information, this could mean selecting the oldest </ins> version that the client supports. 3.
Change:
editorial nit: for consitency with RFC 9000, consider changing you reference name from [INV] -> [QUIC-INVARIANTS]

Discussion:
1. <del> The version-invariant properties of QUIC INV define a Version Negotiation packet but do not specify how an endpoint reacts when it receives one.  QUIC version 1 QUIC allows the server to use a Version Negotiation packet to indicate that the version the client chose is unacceptable, but doesn't allow the client to safely make use of that information to create a new connection with a mutually supported version. </del> <ins> The version-invariant properties of QUIC QUIC-INVARIANTS define a Version Negotiation packet but do not specify how an endpoint reacts when it receives one.  QUIC version 1 QUIC allows the server to use a Version Negotiation packet to indicate that the version the client chose is unacceptable, but doesn't allow the client to safely make use of that information to create a new connection with a mutually supported version. </ins> With proper safety mechanisms in place, the Version Negotiation packet can be part of a mechanism to allow two QUIC implementations

The client initiates a QUIC connection by choosing an initial version and sending a first flight of QUIC packets with a long header to the <del> server INV.  The client's first flight includes Version Information (see vers-info) which will be used to optionally enable compatible version negotation (see compat-vn), and to prevent version downgrade attacks (see downgrade). </del> <ins> server QUIC-INVARIANTS.  The client's first flight includes Version Information (see vers-info) which will be used to optionally enable compatible version negotation (see compat-vn), and to prevent version downgrade attacks (see downgrade). </ins> Upon receiving this first flight, the server verifies whether it knows how to parse first flights from the original version.  If it

Clients will ignore a Version Negotiation packet if it contains the original version attempted by the client.  The client also ignores a Version Negotiation packet that contains incorrect connection ID <del> fields; see INV. </del> <ins> fields; see QUIC-INVARIANTS. </ins> Upon receiving the Version Negotiation packet, the client will search for a version it supports in the list provided by the server.  If it

2.4. <del> QUIC connections are shared state between a client and a server INV. The compatible version negotiation mechanism defined in this document (see compat-vn) is performed as part of a single QUIC connection; that is, the packets with the client's chosen version are part of the same connection as the packets with the negotiated version. </del> <ins> QUIC connections are shared state between a client and a server QUIC- INVARIANTS.  The compatible version negotiation mechanism defined in this document (see compat-vn) is performed as part of a single QUIC connection; that is, the packets with the client's chosen version are part of the same connection as the packets with the negotiated version. </ins> In comparison, the incompatible version negotiation mechanism, which leverages QUIC Version Negotiation packets (see incompat-vn)