jiebi/CodeConvo huggingface dataset:
Change:
The client then generates a ClientHelloInner value.  In addition to the normal values, ClientHelloInner MUST also contain: <del> an "ech_nonce" extension </del> <ins> an "ech_nonce" extension, containing "ech_nonce_value" derived above </ins> TLS padding RFC7685 (see padding)

Discussion:
We'll request early codepoints after we get some implementation experience.
Yeah, as I was specifying the extension codepoint I noticed the collision between this variable, so I figured changing it here was best.
I have no objection to echononce -> echononce_value but did you mean to do it in this PR?
Change:
The "signature" field of the JWS will contain the MAC value computed with the MAC key provided by the CA. <ins> If a CA requires that new-account requests contain an "external- account-binding" field, then it MUST provide the value "true" in the "external-account-required" subfield of the "meta" field in the directory object.  If the CA receives a new-account request without an "external-account-binding" field, then it should reply with an error of type "externalAccountRequired". </ins> When a CA receives a new-account request containing an "external- account-binding" field, it decides whether or not to verify the binding.  If the CA does not verify the binding, then it MUST NOT

Discussion:
While addressing Dale's Gen-ART comments, it occurred to me that while the document said that a CA could require external account binding, it didn't say how. This PR adds a "meta" field and an error code to support that requirements proactively and reactively.
Merging based on NAME review
:ship:
Change:
4. <del> When using external PSK authentication, the use of previously established PSKs allows TLS endpoints to authenticate the endpoint identities.  However, these keys do not provide privacy protection of endpoint identities (see endpoint-privacy), nor do they provide non- repudiation (one endpoint in a connection can deny the conversation). </del> <ins> The use of a previously established PSK allows TLS nodes to authenticate the endpoint identities.  It also offers other benefits, including resistance to attacks in presence of quantum computes; see entropy for related discussion.  However, these keys do not provide privacy protection of endpoint identities, nor do they provide non- repudiation (one endpoint in a connection can deny the conversation); see endpoint-privacy for related discussion. </ins> PSK authentication security implicitly assumes one fundamental property: each PSK is known to exactly one client and one server, and

Discussion:
NIT: Might be better to say: Just drops some redundant words.
I think some things that should be more positive: -- For both PSK authentication and PSK key exchange without (EC)DHE the bad security properties such as lack of identity protection and lack of forward secrecy can be overcome by using one-time PSKs. External PSKs with short lifetimes are quite common in many real deployments. I think this should be mentioned. -- I think quantum resistance should be mentioned earlier in the document. Quantum resistance is a security property, not use a use case. Some things that should be more negative: -- In the list in 4.1 you can add "4. Any group member can blame any other group member." Other comments: -- "then PSK-only key establishment modes are secure against both active and passive attack." I think this you need to describe the exact attacks you have in mind rather than use the work "secure". My view would be that acceptable security in 2021 includes both identity protection and forward secrecy. But more on a system level, then necessarily by TLS itself. -- "DH" I think it would be good to change all “DH” to “DHE” and all “Diffie-Hellman” to “ephemeral Diffie-Hellman” to avoid confusion with the static DH cipher suites in obsolete versions of TLS. -- "As discussed in Section 6, there are use cases where it is desirable for multiple clients or multiple servers to share a PSK." "However, as discussed in Section 6, there are application scenarios that may rely on sharing the same PSK among multiple nodes." Unless you have any real deployments to share, I think this should be reformulated. These are Gedankenexperiments used to illustrate the attack, not real-world applications. I would reformulate and remove "desirable", group PSKs should be very much discouraged. Suggestion: "As discussed in Section 6, to illustrate their attack, [Akhmetzyanova] describes scenarios where multiple clients or multiple servers share a PSK."
Change:
Thus the "confirmed_transcript_hash" field in a GroupContext object represents a transcript over the whole history of MLSPlaintext Commit messages, up to the confirmation tag field in the current <del> MLSPlaintext message.  The confirmation tag and signature fields are then included in the transcript for the next epoch.  The interim transcript hash is passed to new members in the GroupInfo struct, and enables existing members to incorporate a Commit message into the transcript without having to store the whole MLSPlaintextCommitAuthData structure. </del> <ins> MLSPlaintext message.  The confirmation tag is then included in the transcript for the next epoch.  The interim transcript hash is passed to new members in the GroupInfo struct, and enables existing members to incorporate a Commit message into the transcript without having to store the whole MLSPlaintextCommitAuthData structure. </ins> As shown above, when a new group is created, the "interim_transcript_hash" field is set to the zero-length octet

Discussion:
As discussed in the mailing list, not having the signature contribute to the new epoch's key schedule leads to a one-off effect where parties stay in sync (with respect to keys) for one more epoch, before inevitably go out of sync. This pull request addresses this issue by including the signature in the confirmed transcript hash rather than the interim transcript hash. See the mailing list for a security consideration of this change. Credit: This pull request was primarily authored by Marta Mularczk; I'm just posting it here for administrative reasons.
Change:
"coap://[MCD1]/.well-known/core?rt=core.rd*".  RDs within the multicast scope will answer the query. <del> When answering a multicast request directed at a link-local address, </del> <ins> When answering a multicast request directed at a link-local group, </ins> the RD may want to respond from a routable address; this makes it easier for registrants to use one of their own routable addresses for registration.

Discussion:
Use case HA/BA: Expand and reference term "6LBR" Use case HA/BA: Use term 'IoT' that's more common in that area these days
Change:
risk of packets being dropped by middleboxes (which may only support QUIC version 1) <del> Congestion Control, RTT measurements and PMTU discovery should be per-path (following QUIC-TRANSPORT) </del> <ins> Congestion Control must be per-path (following QUIC-TRANSPORT) which usually also requires per-path RTT measurements PMTU discovery should be performed per-path </ins> A path is determined by the 4-tuple of source and destination IP address as well as source and destination port.  Therefore there

Discussion:
The sentence above is part of the introduction, but the should is misleading for congestion control at least (we have a MUST for per-path congestion control later). I would suggest to split the above sentence in two parts: Congestion Control must be performed per-path Path MTU should be performed per path We should probably list somewhere in the document the state that must/should be maintained on a per-path basis and the state that is related to the connection. This could clarify some of the mechanisms. Concerning PathMTU, I would suggest to stay with a should and not a must since an implementation could simply track the minimum MTU among the different paths without maintaining per-path MTU. Such an implementation would work and if the MTUs do not differ significantly, it would probably be simpler than an implementation than maintains per-path MTU and needs to adjust the packets based on the path where each packet is sent. Concerning RTT, we discuss the problem of measuring the RTT later with the packet number spaces discussion. Furthermore, some congestion control schemes need an accurate per-path RTT while others do not strictly require rtt estimations.
NAME this "should" in the intro was not meant to be normative. However, I anyway created PR to clarify. However, I didn't address your point about having a list of all state. Do we really need that? If so, where does that below? A new section somewhere? Can you provide such a list or create a PR? Or should we open a new separate issue for that?
I agree that specifying PMTUD per path is a good idea. We do have a slight ambiguity, because the draft uses the overlapping notions of "path" and "number space", with the number space tied to the DCID of packets. The DCID may change over time for privacy reasons, or because the server wants to retire old CIDs tied to a previous configuration of the load balancer. In these cases, there is no need to restart PMTUD or reset congestion control.
Change:
regarding whether an address is safe to expose.  If so, expose the candidate and abort this process. <del> Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE candidate's IP address.  If one exists, skip ahead to Step 6. </del> <ins> Check whether the ICE agent has previously generated, registered, and stored an mDNS hostname for this IP address as per Steps 3, 4, and 6.  If it has, skip ahead to Step 7. </ins> Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local".

Discussion:
PR for
In the section gather candidates, it says: "Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE candidate’s IP address. If one exists, skip ahead to Step 6." We, maybe, should clarify this refers to a registered mDNS hostname as produce by this spec, not another (possibly meaningful) name created in some other context.
Makes sense as an editorial cleanup.
Fixed by
Change:
This document requests that IANA add the following entry to the QUIC version registry: <del> Value: TBD </del> <ins> Value: 0x709a50c4 </ins> <del> Status: permanent </del> <ins> Status: provisional </ins> Specification: This Document

Discussion:
Get one from IANA
I'll ask for 0x70 9a 50 c4 .
Feedback from NAME was that you should do that after publishing a revision with that number in it. I second that.
Change:
Simple registration could be used to circumvent address-based access control: An attacker would send a simple registration request with the victim's address as source address, and later look up the <del> victim's .well-known/core content in the RD.  Mitigation for this is </del> <ins> victim's /.well-known/core content in the RD.  Mitigation for this is </ins> recommended in simple. The Registration Resource path is visible to any client that is

Discussion:
Even disregarding the examples that necessarily have the slash, this (vs. plain .well-known/core) version was the more common in the text so far. Closes: URL
This actually
Current master branch text is really unclear: What does it mean : "used to find the identification" ? Can we say intead "used to identify the components" ? How can the URI discovery process identify client-server incompatibilities? CoAP doesn't let you discover supported protocol versions, options, etc. as far as I know, by default. For those implementations not supporting I-D.bormann-t2trg-rel-impl , it is really unclear what to do with this paragraph.
Oups, wrong link in the commit -- sorry for the noise
The intention behind this paragraph is merely to point those who want versioning and more RD metadata that is immaterial to the regular operation to a place where they can safely do so. I see, however, how the "it is necessary to" makes this sound like more than there really is to it. Accordingly, the incompatibilities part is not about finding that something can't work in the first place (that works on a positive-list base using rt and that like), but more for understanding later why things don't work (say, client X produces a document that upsets RD implementation Y in versions earlier than 0.4.1). The address is in section 4 of 6690 (ie. just .well-known/core); now referred to by the name it has there.
A couple of places has ".well-known/core" as resource name, while in most places it says "/.well-known/core". Proposal is to update all occurrences to the latter form. (Maybe this is already addressed in the pull requests with nits, but there are so many - hard to check...)
Change:
attacker could not take advantage of this information leakage to recover any meaningful amount of information (see PETAL). <del> 7.6. </del> <ins> 7.3. </ins> An attacker can try to cause an endpoint to exhaust its memory. QPACK is designed to limit both the peak and stable amounts of memory

Discussion:
Magnus Nystrom : not be able (based on no current known attack against static Huffman encodings) to mount the previously described "probing" attack? If so, adding a sentence at the end of the section along the lines of "Thus, the previously mentioned probing attack is not known to be applicable for any fields where static Huffman encoding is used."
This section is not related to the probing attack. I think some of the confusion here is lost formatting when importing from RFC 7541. The TOC should be:
Change:
section.  An encoder MUST emit field representations in the order they appear in the input field section. <del> QPACK is designed to contain the more complex state tracking to the encoder, while the decoder is relatively simple. </del> <ins> QPACK is designed to place the burden of optional state tracking on the encoder, resulting in relatively simple decoders. </ins> 2.1.1.

Discussion:
Inspired by NAME suggestion;
Is "to the encoder" intended? Should this be "within the encoder" or might "contain" be made "limit" or something else? Original: QPACK is designed to contain the more complex state tracking to the encoder, while the decoder is relatively simple.
"Limit" is probably the closest if we want to keep the phrase as-is. Writing something de novo might be better, but I'm having trouble coming up with anything pithy.
Some alternatives (aka throwing mud at the wall) "The design of QPACK requires an encoder to implement relatively more-complex state tracking than a decoder." "QPACK's design requires state tracking in various degrees of complexity. In relative terms, encoders have complex requirements, while decoders are more simple. "QPACK is designed to put the state tracking complexity onus on encoders, resulting in relatively simple decoders."
I like the third one.
Fixed in with a variant of the third option.
LGTM
Change:
Namespaces for each of the keywords provided in the IANA protocol numbers registry (see https://www.iana.org/assignments/protocol- <del> numbers/protocol-numbers.xhtml), translated to lower-case and with characters other than letters, numbers, and hyphens deleted, are reserved for Protocol Specific Properties and MUST not be used for vendor or implementation-specific properties. </del> <ins> numbers/protocol-numbers.xhtml), reformatted where necessary to conform to an implementation's naming conventions, are reserved for Protocol Specific Properties and MUST not be used for vendor or implementation-specific properties. </ins> 4.2.2.

Discussion:
Updates PR to remove reference to lower-case in namespaces corresponding to IANA protocol names. Express that strict adherence to the doc's naming convention is not required, but that symbols in different languages should be visually similar.
NAME NAME Last minute PR
Change:
Identical to the encrypted_record field in a TLS 1.3 record. <del> 14 bit sequence number field. </del> <ins> The DTLSCiphertext header is tightly bit-packed, as shown below: The low order two bits of the epoch. The low order 14 bits of the record sequence number. </ins> Identical to the length field in a TLS 1.3 record.

Discussion:
This pull request aims to address the open issues regarding sequence number encryption. The approach chosen follows the design used in QUIC.
Change:
optionally indicate a preference for which address it would get assigned. <del> The ADDRESS_REQUEST capsule contains a sequence of zero or more </del> <ins> The ADDRESS_REQUEST capsule contains a sequence of one or more </ins> Requested Addresses. If the IP Address is all-zero (0.0.0.0 or ::), this indicates that

Discussion:
"The ADDRESS_REQUEST capsule contains a sequence of zero or more Requested Addresses." In cases there are zero Requested Addresses what does this mean? It appears that this is an even less determined form than the all zero block , that at least indicates an address family support or preference as well as prefix length by including one or two all-zero address of the families the endpoint want assigned? Should this be explicitly stated?
Change:
An Object sends an Event: An Action takes a set of Parameters; an Event contains a set of <del> Parameters: </del> <ins> Parameters.  Action parameters whose names are suffixed with a question mark are optional. </ins> Actions associated with no Object are Actions on the abstract interface itself; they are equivalent to Actions on a per-application

Discussion:
Even though all the languages we want to support don't have convenient syntax for optional parameters to functions/methods, it would be nice to note that we intend for some parameters to not be mandatory on every call.
Looks good! This approach certainly clarifies things.LGTM except for the paragraph that I commented on; I'd just delete that.Fine withe mit (with some minor knit)
Change:
Hostname (string): <del> Port (a 16-bit integer) or a Service (string) that maps to a port: </del> <ins> Port (a 16-bit integer): Service (an identifier that maps to a port; either a the name of a well-known service, or a DNS SRV service name to be resolved): </ins> IP address (IPv4 or IPv6 address):

Discussion:
Would there be any benefit of having something like "WithServiceName" to qualify a specifier for use with NAPTR/SRV? Or is the thinking that the resolution of the thing handed down through WithHostname is restricted to A/AAAA?
yes, probably.
We do have this for mDNS services in Network.framework, and internally have tested with SRV. These are useful indeed.
Actually, doesn't WithService do this? Should we clarify that this can use SRV as opposed to just looking up in /etc/services.
Interim: Yes, this is a nice solution. Let's mention how to use withService for SRV types in the text.
Change:
Encoding considerations: Must be encoded as using RFC7049.  See RFC- AAAA for details. <del> Security considerations: Sensor data can contain a wide range of information ranging from information that is very public, such the outside temperature in a given city, to very private information that requires integrity and confidentiality protection, such as patient health information.  This format does not provide any security and instead relies on the transport protocol that carries it to provide security.  Given applications need to look at the overall context of how this media type will be used to decide if the security is adequate. </del> <ins> Security considerations: See sec-sec of RFC-AAAA. </ins> Interoperability considerations: Applications should ignore any key value pairs that they do not understand.  This allows backwards

Discussion:
Alternatively we can have the same text 9 times instead of 8
Alexey confirmed in the CoRE session that this is OK, so let's go forward with this.
The IANA types review list explicitly wanted all of this repeated because they don't read the draft on the email and each type needs it's own email. It is insane. So I would not make this change. LGTM
Change:
STOP_SENDING requests that a peer cease transmission on a stream. A STOP_SENDING frame can be sent for streams in the Recv or Size <del> Known states; see stream-send-states.  Receiving a STOP_SENDING frame </del> <ins> Known states; see stream-recv-states.  Receiving a STOP_SENDING frame </ins> for a locally-initiated stream that has not yet been created MUST be treated as a connection error of type STREAM_STATE_ERROR.  An endpoint that receives a STOP_SENDING frame for a receive-only stream

Discussion:
Tommy points out that we accidentally cited the sending parts, but these are receive states.
Very editorial nit: The section has the following text: The states referenced here are in fact receive stream states, not send stream states. Should this be: The same goes for MAXSTREAM_DATA:
Change:
is expected to both expire earlier than the PTO and be less likely to spuriously retransmit data. <del> 5.3. </del> <ins> 5.2.2. </ins> The initial probe timeout for a new connection or new path SHOULD be set to twice the initial RTT.  Resumed connections over the same

Discussion:
I believe this section was mistakenly on the wrong level. I also added a reference to a later section to the last sentence. Alternatively this sentence could just be removed as this is normatively specified later on.
Change:
3. This section details use-cases where coding techniques could improve <del> the overall performance of a SATCOM system (e.g. considering a more </del> <ins> the overall performance of a SATCOM system (e.g., considering a more </ins> efficient usage of the satellite resource, delivery delay, delivery ratio).

Discussion:
Introduction physical-layer reliability mechanisms -- hyphenate adjectival terms style: e.g. should be in a clause separated by commas, not brackets. 500 ms one-way delivery delay (or path -- i.e. not propagation)
Intro must do the same, clarifying also it's not a standard, and give an estimation of the support it collected during discussion within the group. For instance (taken from rfc 8406): This document is the product of and represents the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG); it is not an IETF product and is not a standard. .
I think PR solves the issue.
Change:
have semantics "BUNDLE", and MUST include the mid identifiers of each m= section. <del> Attributes that are common between all m= sections MAY be moved to session-level, if explicitly defined to be valid at session-level. </del> <ins> Attributes which SDP permits to either be at the session level or the media level SHOULD generally be at the media level even if they are identical.  This promotes readability, especially if one of a set of initially identical attributes is subsequently changed. </ins> Attributes other than the ones specified above MAY be included, except for the following attributes which are specifically

Discussion:
This is OK with me but fine if we want to call out identity or anything that is different.
How's this?
LGTM
S 5.2.1 says: Attributes that are common between all m= sections MAY be moved to session-level, if explicitly defined to be valid at session-level. This seems like it would be better as a should
Discussed in DC: Some concerns that things that appear at the session level have, in the past, missed by bad implementations.
Dc - decdie to change to SHOULD NOT and for things that are big, like idientiy, will put MUST