jiebi/CodeConvo huggingface dataset:
Change:
Expand functions as defined for HKDF RFC5869, as well as the functions defined below: <del> The Hash function and the HKDF hash are the cipher suite hash algorithm.  Hash.length is its output length in bytes.  Messages are the concatenation of the indicated handshake messages, including the handshake message type and length fields, but not including record layer headers.  Note that in some cases a zero-length HashValue (indicated by "") is passed to HKDF-Expand-Label. </del> <ins> The Hash function used by Transcript-Hash and HKDF are the cipher suite hash algorithm.  Hash.length is its output length in bytes. Messages are the concatenation of the indicated handshake messages, including the handshake message type and length fields, but not including record layer headers.  Note that in some cases a zero- length HashValue (indicated by "") is passed to HKDF-Expand-Label. </ins> Note: with common hash functions, any label longer than 12 characters requires an additional iteration of the hash function to compute.

Discussion:
HKDF-Expand-Label has changed between draft -19 and -20, clarify that "HDF Hash" refers to the hash algorithm and not a version-specific instance of HKDF-Expand-Label which is populated with a hash algorithm.
Change:
section if its mid property is non-null; otherwise it is said to be disassociated.  The associated m= section is determined using a mapping between transceivers and m= section indices, formed when <del> creating an offer or applying a remote offer.  An RtpTransceiver is never associated with more than one m= section, and once a session description is applied, a m= section is always associated with exactly one RtpTransceiver. </del> <ins> creating an offer or applying a remote offer. An RtpTransceiver is never associated with more than one m= section, and once a session description is applied, a m= section is always associated with exactly one RtpTransceiver.  However, in certain cases where a m= section has been rejected, as discussed in sec.subsequent-offers below, that m= section will be "recycled" and associated with a new RtpTransceiver with a new mid value. </ins> RtpTransceivers can be created explicitly by the application or implicitly by calling setRemoteDescription with an offer that adds

Discussion:
PTAL
Section 3.5.1 talks about a "recycled m= section" without any context for what this means. Please provide a forward reference to the section that discusses m= section recycling.
is where m= section recycling is first defined, but it's as a bullet point in how to generate an offer, which makes a direct reference problematic. I guess we could say "as spelled out in [ref]"
Change:
with any other value as a connection error of type PROTOCOL_VIOLATION. <del> Early data within the TLS connection MUST NOT be used.  As it is for other TLS application data, a server MUST treat receiving early data on the TLS connection as a connection error of type PROTOCOL_VIOLATION. </del> 4.6. A server rejects 0-RTT by rejecting 0-RTT at the TLS layer.  This

Discussion:
As of -12, TLS records are not used in QUIC (TLS handshake messages are directly transmitted instead), and therefore it is impossible in QUIC to transmit early data using the machinery provided by TLS.
Change:
13. <del> See sec-privacy.  Further discussion of security properties can be found in sec-iana-media. </del> <ins> Sensor data can contain a wide range of information ranging from information that is very public, such as the outside temperature in a given city, to very private information that requires integrity and confidentiality protection, such as patient health information.  The SenML format does not provide any security and instead relies on the protocol that carries it to provide security.  Applications using SenML need to look at the overall context of how this media type will be used to decide if the security is adequate. See also sec-privacy. </ins> 14.

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:
identify the components that constitute the RD server.  The identification refers to information about for example client-server incompatibilities, supported features, required updates and other <del> aspects.  The URI discovery address, a described in section 4 of </del> <ins> aspects.  The URI discovery address, as described in section 4 of </ins> RFC6690 can be used to find the identification. It would typically be stored in an implementation information link

Discussion:
Thanks, merged. (If questions come up around the normative-language RECOMMENDED: I agere that from the capitals NOT before it, this was already intended to be normative.)
Change:
6. This section describes a variant of the issuance protocol in private- <del> flow for producing publicly verifiable tokens.  It differs from the previous variant in that the output tokens are publicly verifiable by anyone with the Issuer Public Key. This means any Origin can select a given Issuer to produce tokens, as long as the Origin has the Issuer public key, without explicit coordination or permission from the Issuer.  This is because the Issuer does not learn the Origin that requested the token during the issuance protocol. </del> <ins> flow for producing publicly verifiable tokens using the protocol in BLINDRSA.  In particular, this variant of the issuance protocol works for the RSABSSA-SHA384-PSS-Deterministic and RSABSSA-SHA384-PSSZERO- Deterministic blind RSA protocol variants described in Section 5 of BLINDRSA. The publicly verifiable issuance protocol differs from the protocol in private-flow in that the output tokens are publicly verifiable by anyone with the Issuer Public Key. This means any Origin can select a given Issuer to produce tokens, as long as the Origin has the Issuer public key, without explicit coordination or permission from the Issuer.  This is because the Issuer does not learn the Origin that requested the token during the issuance protocol. </ins> Beyond this difference, the publicly verifiable issuance protocol variant is nearly identical to the privately verifiable issuance

Discussion:
This link is broken in a few ways. Note that the links has an trailing period in it, which is only part of the problem there; there is no Section 5.1.2 or Section "5.1.2.". Also, the function is called "BlindSign" in that version of the draft.
In the issuance protocol draft, there are a few places where it is assumed that a value will be a certain length, but no effort has been made to explicitly set a length. In : Is the 0x0002 two octets? Sure, you might readily assume that, but nothing says that explicitly. The same assumption appears in Sections 5.1 and 5.5.
Change:
use of temporary addresses, the resulting Connection cannot use IPv4, because temporary addresses do not exist in IPv4.  Second, temporary local addresses might involve trading off privacy for performance. <del> For instance, temporary addresses can interfere with resumption mechanisms that some protocols rely on to reduce initial latency. </del> <ins> For instance, temporary addresses (e.g., RFC8981) can interfere with resumption mechanisms that some protocols rely on to reduce initial latency. </ins> 6.2.14.

Discussion:
Adding this issue from Fernando via the TAPS list: The terminology employed in this subsection seems a bit confusing, or at least deviates from what we normally use in v6-circles. I suggest taking a look at RFC7721 -- certainly not flawless, but it was 6man's shot to try to agree on terminology. For example, I don't think we use "permanent" and "stable" interchangeably. e.g. the "Local" in "useTemporaryLocalAddress" might be misleading to some. -- e.g. could be interpreted as related with link-locals or ULAs. Aside, I believe there's much more to dig regarding address properties. e.g., we have given it a shot at: URL e.g., the choice of ipv6 addresses has more than one dimension... and there are tradeoffs involved, which IMHO deserve discussion. And aside from the regular address systems normally configure, if one were to specify an API one would probably want to provide a mechanism for apps to be able to request sole/single-use addresses (.e.g., one address per app or container).
"Local" has a meaning in the TAPS context, I don't think we need to change it for universalization with the full set of IPv6 terminology. There's also not much point in going all the way down the rabbithole for this particular property, given that we don't do so for any other -- this document is meant as a universal interface to networking for the future, not an unbounded treatise on the future of networking. That said, the linked draft does seem to address the issues here and it's fairly alive, so no harm in adding an informative reference to it.
I agree with the comments of NAME and NAME
Change:
MUST forget not only the ephemeral keys used by the connection but also any information that could be used to recompute those keys. <ins> Using EAP-AKA' FS once provides forward secrecy.  Forward secrecy limits the effect of key leakage in one direction (compromise of a key at time T2 does not compromise some key at time T1 where T1 < T2).  Protection in the other direction (compromise at time T1 does not compromise keys at time T2) can be achieved by rerunning ECDHE frequentle.  If a long-term authentication key has been compromised, rerunning EAP-AKA' FS gives protection against passive attackers. Using the terms in {{RFC7624}}, forward secrecy without rerunning ECDHE does not stop an attacker from doing static key exfiltration. Frequently rerunning EC(DHE) forces an attacker to do dynamic key exfiltration (or content exfiltration). </ins> The following security properties of EAP-AKA' are impacted through this extension:

Discussion:
Not sure the attacks actually attacked the smart cards. Changed to "smart card supply chain" in the abstract and intro. This is very much related to zero trust principles. added a sentence about this. Any modern standard track EAP method should provide mandatory client identity protection. Copied the text from EAP-TLS 1.3 Motivation for the chosen curves is missing. Added link to the definition of SUCI encryption in appendix C.3.4. of TS 33.501 Added more text in security consideration on the attacks an attacker can do. Added more text in security consideration on frequent use of ECDHE.
Great! There's one typo but I'll fix it.
Change:
congestion window, or a pacer might pace out packets handed to it by the congestion controller.  Timely delivery of ACK frames is important for efficient loss recovery.  Packets containing only ACK <del> frames should therefore not be paced, to avoid delaying their </del> <ins> frames SHOULD therefore not be paced, to avoid delaying their </ins> delivery to the peer. Sending multiple packets into the network without any delay between

Discussion:
This my need a design issue because I suggest to use two SHOULDs instead of should. However, I would first like to get some feedback if people agree.
I think this is editorial, because it fixes an error. I always intended these to be normative SHOULD/SHOULD NOT
I'm going with editorial also.
Yup, this is editorial.
Thanks, this is certainly what I meant when I wrote this text.
Change:
the server given an established TLS connection, a certificate, and a corresponding private key.  Clients MUST NOT send an authenticator without a preceding authenticator request; for servers an <del> authenticator request is optional. The authenticator uses the message structures from Section 4.4 of TLS13, but different parameters.  These messages do not include the TLS record layer and are therefore not encrypted with a handshake key. </del> <ins> authenticator request is optional.  The authenticator uses the message structures from Section 4.4 of TLS13, but different parameters.  These messages do not include the TLS record layer and are therefore not encrypted with a handshake key. </ins> 4.1.

Discussion:
the newline was being introduced by trailing whitespace at the end of line 136.
In the , there's a newline between two sentences that apparently can't decide whether they want to be in separate paragraphs or not.
Change:
The number of tickets the server expects to send in this connection. <del> Servers MUST NOT send the "ticket_request" extension in ServerHello or HelloRetryRequest messages.  A client MUST abort the connection with an "illegal_parameter" alert if the "ticket_request" extension is present in either of these messages. </del> <ins> Servers MUST NOT send the "ticket_request" extension in any handshake message, including ServerHello or HelloRetryRequest messages.  A client MUST abort the connection with an "illegal_parameter" alert if the "ticket_request" extension is present in any server handshake message. </ins> If a client receives a HelloRetryRequest, the presence (or absence) of the "ticket_request" extension MUST be maintained in the second

Discussion:
I opted to go with "new connection" instead of "full handshake" (where appropriate), since that seemed to be the more natural phrase. Please let me know what you think! cc NAME (and thanks for the review!)
Change:
The tokens are protected using AES128-GCM as follows: <del> The token key and IV are retrieved using the Key Sequence. </del> <ins> The Key Sequence is the 8 bit identifier to retrieve the token key and IV. </ins> <del> The nonce, N, is formed by combining the IV with the 96 bit unique token number.  The 96 bits of the unique token number are left- padded with zeros to the size of the IV.  The exclusive OR of the padded unique token number and the IV forms the AEAD nonce. </del> <ins> The AEAD IV, is a 96 bit data which produced by implementer's custom AEAD IV derivation function. The AEAD nonce, N, is formed by combining the AEAD IV with the 96 bit unique token number.  The 96 bits of the unique token number are left-padded with zeros to the size of the IV.  The exclusive OR of the padded unique token number and the AEAD IV forms the AEAD nonce. </ins> The associated data is a formatted as a pseudo header by combining the cleartext part of the token with the IP address of the client.

Discussion:
Made the changes to merge this.
Hi martin: The defination of and brought me a great confusion when I implement the share-state retry service. Though finally I got what the draft want to express, I still suggest we should give more information about them According to section 1.5 of rfc5084: According to section 3.4 of rfc5116 I guess that in current draft is the define in rfc5116, is just a random value(or a incrementing number) to generate . If I were true, please consider my PR for my suggestion.
Additional, it's no need to make the length of (current draft define) variable, just 96 bit is sufficient. Current aes-128-gcm related cipher suites all use this value
We can also add some illustration of , draft use in other place
Change:
Tokens, it is not accessible from Web Platform APIs (such as those commonly accessed via JavaScript in web browsers). <del> 7. </del> <ins> 5. </ins> <del> 7.1. </del> <ins> 5.1. </ins> This document will request IANA to register the following entry in the "HTTP/3 Settings" registry: <del> 7.2. </del> <ins> 5.2. </ins> This document will request IANA to register the following entry in the "HTTP/3 Error Codes" registry: <del> 7.3. </del> <ins> 5.3. </ins> This document will request IANA to register the following entry in the "HTTP Field Name" registry: <del> 7.4. </del> <ins> 5.4. </ins> This document establishes a registry for HTTP capsule type codes. The "HTTP Capsule Types" registry governs a 62-bit space.

Discussion:
NAME thank you for the suggestions over on URL David and I worked through your proposal from top to bottom and turned it into this PR, which accepts many suggestions but not all. Please review and let us know if you're happy with it. NAME we believe some of your comments are addressed here too (unless tracked on a separate ticket). Please take a look.
While the argument in Section 2 "requests are strictly serialised in the connection, therefore demultiplexing is not needed" is technically correct, Section 4. further restricts the use of HTTP/1.1 connections to a single stream of capsules/HTTP datagrams. I would prefer to see this restriction as an argument here.
The sentence "Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP." seems a little misleading … During the IETF 113 discussions, I understood capsules as general mechanism reliable datagrams/wire encoding over HTTP In the draft however, Section 1 state "Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP." contradicts this impression. Can we clarify this?
Why is the ebnf instead of ? Should this allow request/upgrade methods to append a list of additional parameters?
Yes, allows parameters but does not. We didn't see a good reason to ban future parameters
Maybe you should mention it and require intermediaries to pass and ignore them in case they don't understand them.
as per recent changes in HTTPland specs, the ABNF adds confusion. My suggestion is to remove the ABNF. That might still leave a question over the structured types, but that is answered by the Structured Field value specs and we are unlikely to need to state anything ourselves. I can take a pass at this.
LGTM, thanks!
Change:
values, these two values are always the same. Note: Although the resumption main secret depends on the client's <del> second flight, a server which does not request client authentication MAY compute the remainder of the transcript independently and then send a NewSessionTicket immediately upon sending its Finished rather than waiting for the client Finished.  This might be appropriate in cases where the client is expected to open multiple TLS connections in parallel and would benefit from the reduced overhead of a resumption handshake, for example. </del> <ins> second flight, a server which does not request certificate-based client authentication MAY compute the remainder of the transcript independently and then send a NewSessionTicket immediately upon sending its Finished rather than waiting for the client Finished. This might be appropriate in cases where the client is expected to open multiple TLS connections in parallel and would benefit from the reduced overhead of a resumption handshake, for example. </ins> %%% Ticket Establishment

Discussion:
Based on the PSK authentication was not included in the past. I think specification has some places where "Client Authentication" refer to only certificate-based client authentication and not client authentication is general. Not a big thing, but I think it might confuse some readers, and would be good to clarify.
Change:
for endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in URI form otherwise; the RD SHOULD recognize either.  The "anchor" attribute is usable for resource lookups, and, <del> if queried, MUST be for in URI form as well. </del> <ins> if queried, MUST be in URI form as well. </ins> Endpoints that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource

Discussion:
Thanks, merged. (If questions come up around the normative-language RECOMMENDED: I agere that from the capitals NOT before it, this was already intended to be normative.)
Change:
provide application programming interfaces by which clients and servers may request and verify exported authenticator messages. <del> Notwithstanding the success cases described below, all APIs MUST fail if: </del> <ins> Notwithstanding the success conditions described below, all APIs MUST fail if: </ins> the connection uses a TLS version of 1.1 or earlier, or the connection is TLS 1.2 and the extended master secret RFC7627 was not used <del> Given an established connection, the application SHOULD be able to call the following APIs: </del> <ins> The following sections describes APIs that are considered necessary to implement exported authenticators.  These are informative only. </ins> <del> "request", which takes as input: </del> <ins> 5.1. The "request" API takes as input: </ins> certificate_request_context (from 0 to 255 bytes)

Discussion:
There are lots of changes here. I did stage this as separate commits to some extent, so feel free to cherry-pick. There is one maybe-technical change here. It wasn't clear about the precedence between handshake and authenticator request for extensions. I've chosen to be clear about this and say that if the authenticator request exists, then it is the only thing that matters. That's 8c0b166. I can drop that from the CL and do that separately if you prefer.
Thanks for the comments. The technical clarification you made is the correct one, the request supersedes the handshake for extension choices if present.
Change:
optionally a sector (abbreviated "d" for historical reasons), <ins> a group resource location inside the RD ("href"), </ins> zero or one multicast addresses expressed as a base URI ("base"), and is composed of zero or more registrations (endpoints).

Discussion:
This executes the renaming of con to base and domain to sector as agreed on in the last meeting. Two follow-up commits create consistency in the ER diagram (which had to be modified anyway for the renaming) and the accompanying text, both internally (describe groups the same way as resources) and within the document (we describe several properties of a group that the ER did not show).
Change:
Since the new member is expected to process the Add message for itself, the Welcome message should reflect the state of the group before the new user is added.  The sender of the Welcome message can <del> simply copy all fields except the "leaf_secret" from its GroupState object. </del> <ins> simply copy all fields from their GroupState object. </ins> [[ OPEN ISSUE: The Welcome message needs to be synchronized in the same way as the Add.  That is, the Welcome should be sent only if the

Discussion:
There is no "leaf_secret" field in GroupState. While there might be one in the group state struct that the implementation maintains locally, I think it's safe to recommend copying everything from the GroupState object as it's defined earlier in the document.
Change:
"expectedExtensions": an array of "ExtensionType" names. <ins> "selfDelimitingExtensions": an array of "ExtensionType" names. </ins> "allowAdditional": "true" or "false". If "predefinedExtensions" or "expectedExtensions" is empty, it MAY be

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.