jiebi/CodeConvo huggingface dataset:
Change:
Integer (non-negative) <del> This property represents an unbounded hierarchy of priorities.  It can specify the priority of a Message, relative to other Messages sent over the same Connection. </del> <ins> This property represents a hierarchy of priorities.  It can specify the priority of a Message, relative to other Messages sent over the same Connection. </ins> <del> A Message with Niceness 0 will yield to a Message with Niceness 1, which will yield to a Message with Niceness 2, and so on.  Niceness </del> <ins> A Message with Priority 0 will yield to a Message with Priority 1, which will yield to a Message with Priority 2, and so on.  Priorities </ins> may be used as a sender-side scheduling construct only, or be used to specify priorities on the wire for Protocol Stacks supporting prioritization. Note that this property is not a per-message override of the <del> connection Niceness - see conn-niceness.  Both Niceness properties </del> <ins> connection Priority - see conn-priority.  Both Priority properties </ins> may interact, but can be used independently and be realized by different mechanisms.

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:
QUIC is expected to evolve rapidly, so new versions, both experimental and IETF standard versions, will be deployed on the <del> Internet more often than with traditional Internet- and transport- layer protocols.  Using a particular version number to recognize valid QUIC traffic is likely to persistently miss a fraction of QUIC flows and completely fail in the near future, and is therefore not recommended.  In addition, due to the speed of evolution of the protocol, devices that attempt to distinguish QUIC traffic from non- QUIC traffic for purposes of network admission control should not rely on the version number field.  Instead it is recommended to admit all QUIC traffic regardless of version in order to support continuous version-based evolution and avoid unnecessary deployment delays. </del> <ins> Internet more often than with other commonly deployed Internet- and transport-layer protocols.  Use of the version number field for traffic recognition will therefore behave differently than with these protocols.  Using a particular version number to recognize valid QUIC traffic is likely to persistently miss a fraction of QUIC flows, and completely fail in the near future.  Reliance on the version number field for the purposes of admission control is similarly likely to rapidly lead to unintended failure modes.  Admission of QUIC traffic regardless of version avoids these failure modes, avoids unnecessary deployment delays, and supports continuous version-based evolution. </ins> 3.

Discussion:
Instead of making an explicit policy recommendation with respect to version recognition, clarify the downsides of doing so.
NAME I think this addresses the objection to policy recommendations on version recognition; PTAL. thanks!!
I can live with the latest wording here, thanks! And I didn't imagine that "traditional" was non-inclusive language; traditions are an inexorable aspect of many cultures...
I can see how some uses of the word tradition or traditional are non-inclusive. The occurences here do not strike me that way and the alternatives presented weaken the point of the text. We can proceed with an open mind to whether the term needs to be changed in response to wider review via subsequent review in the process.
My understanding is that "traditional" is also flagged because it's usually not a clear term in technical documents and I think that's the case here as well. There is no tradition about deploying certain protocols. We could just say "older" or "other protocols used so far" or something like this.
If you editors would like to replace it with a different term that conveys your intent, that's fine by me. Perhaps switch traditional for "other commonly used"
s/traditional/most other/g?
other commonly used is also good, but requires a manual rewrap. :)
thanks for addressing the in-solidarity bot
Change:
TIAS = AS * 1000 * 0.95 - 50 * 40 * 8 The 50 is based on 50 packets per second, the 40 is based on an <del> estimate of total header size, the 1000 is to change the unit from kbps to bps and the 0.95 is to allocate 5% to RTCP.  If more accurate control of bandwidth is needed, "TIAS" should be used instead of "AS". </del> <ins> estimate of total header size, the 1000 changes the unit from kbps to bps (as required by TIAS) and the 0.95 is to allocate 5% to RTCP.  If more accurate control of bandwidth is needed, "TIAS" should be used instead of "AS". </ins> For any "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2.

Discussion:
This is an update of Fippo's
See PR
LGTM
lgtm with comma
Change:
A stateless reset is provided as an option of last resort for an endpoint that does not have access to the state of a connection.  A crash or outage might result in peers continuing to send data to an <del> endpoint that is unable to properly continue the connection.  A stateless reset is not appropriate for signaling error conditions. </del> <ins> endpoint that is unable to properly continue the connection.  An endpoint MAY send a stateless reset in response to receiving a packet that it cannot associate with an active connection. A stateless reset is not appropriate for signaling error conditions. </ins> An endpoint that wishes to communicate a fatal connection error MUST use a CONNECTION_CLOSE frame if it has sufficient state to do so.

Discussion:
I know that we made this a design issue, and these do change 2119 language, but those normative requirements were implied anyway. That is, the text used cannot vs. MUST NOT.
I was also wondering about the rate limit in SR - I too thought it was there. But now, after thinking a bit, the rate limit was probably removed because it is a DoS vector. It can force state to maintained where it is not wanted.
This is a weird statement to make. It is absolutely the place of the spec to do that! If what you mean is that this is entirely optional, then I'm happy to make it a MAY. My concern is not so much what level of force the spec uses, just that the level of force is clear.
Before I merge this, NAME NAME might want to check that I'm not making technical changes. (There is new 2119 language, but my view is that this is converting from implied to express, but I want to give a chance to run a consensus call if you think that's appropriate.)
Those sorts of conversions have surprised people before, and is design anyway, so let's do run that consensus call. If it's ready to go, add and we'll run it up the virtual flagpole.
NAME take a look at what I just proposed.
While there are some prohibitions, and an explicit MAY for responding to Long Headers, there is no normative statement for the usual use case for Stateless Reset. I believe it's a SHOULD, but maybe someone thinks it's a MUST. Relatedly, in 10.4.1, MUST we attempt to detect Stateless Reset, or MAY endpoints just drop after decrypt failure? At the end of 10.4.2, MUST we not reuse connection IDs if there's a static key? (I think the answer is yes)
Thanks, NAME this LGTM.Thank you, this addresses the original issue. One nit below.
Change:
graph and send multiple signatures in parallel (each for a branch of the dependency graph). <del> In case of simulcast or K-SVC, each spatial layer sould be </del> <ins> In case of simulcast or K-SVC, each spatial layer should be </ins> authenticated with different signatures to prevent the SFU to discard frames with the signature info.

Discussion:
Rewrite the Key management section Add MLS subsection Update the SFrame format Fixed typos
Change:
netconf-keystore, and "ietf-tcg-algs.yang" ref-ietf-tcg-algs. Additionally references are made to RFC8032, RFC8017, RFC6933, TPM1.2-Commands, TPM2.0-Arch, TPM2.0-Structures, TPM2.0-Key, <del> TPM1.2-Structures, PC-Client-EFI-TPM-1.2, ima-log, and netequip-boot- log. </del> <ins> TPM1.2-Structures, PC-Client-EFI-TPM-1.2, ima-log, BIOS Log Event Type and netequip-boot-log. </ins> 2.1.1.1.

Discussion:
NAME - if spaces are allowed in kramdown references, then this should work. AFAIK, this is ready to post to IETF.
Change:
The string "proofOfPossession-01" <del> An array of certificates, in Base64-encoded DER format, that </del> <ins> An array of certificates, in Base64url-encoded DER format, that </ins> contain acceptable public keys. In response to this challenge, the client uses the private key

Discussion:
They should be base64url rather than base64, for symmetry with rest of spec.
Don't think this is totally necessary, since we say at the front that when we say "base64", we mean the special variant. But happy to be clearer here.
Change:
"token_type" is a 2-octet integer, which matches the type in the challenge. <del> "token_key_id" is the least significant byte of the "key_id" in network byte order (in other words, the last 8 bits of "key_id"). </del> <ins> "truncated_token_key_id" is the least significant byte of the "token_key_id" in network byte order (in other words, the last 8 bits of "token_key_id"). </ins> "blinded_msg" is the Nk-octet request defined above.

Discussion:
cc NAME NAME
Let's use different names to make this distinction clear.
This helps, thanks!
Change:
with the corresponding hash algorithm as defined in SHS.  These values refer solely to signatures which appear in certificates (see server-certificate-selection) and are not defined for use in <del> signed TLS handshake messages. </del> <ins> signed TLS handshake messages, although they MAY appear in "signature_algorithms" and "signature_algorithms_cert" for backward compatibility with TLS 1.2, </ins> Indicates a signature algorithm using ECDSA ECDSA, the corresponding curve as defined in ANSI X9.62 X962 and FIPS 186-4

Discussion:
The only thing that might need text (though I'm not certain) is that this doesn't describe what it means to have signaturealgorithmscert and not signaturealgorithms. I assume that it means that a signature isn't possible. However, in previous versions it would be interpreted to mean something else based on default values for signaturealgorithms.
Change:
Configuration of the TURN or STUN servers used by the WHIP client is out of the scope of this document. <del> It is RECOMMENDED that broadcasting server provides an HTTP interface for provisioning the TUNR/STUN servers url and short term credentiasl as in I-D.draft-uberti-behave-turn-rest-00.  Note that the authentication information or the url of this API are not related to the WHIP enpoint URLs or authentication. </del> <ins> It is RECOMMENDED that the broadcasting server provides an HTTP interface for provisioning the STUN/TURN servers' URLs and short term credentials as in I-D.draft-uberti-behave-turn-rest-00.  Note that neither the authentication information nor the URLs of the STUN/TURN servers are related to the WHIP endpoint. </ins> <del> It could also be possilble to configure the STUN/TURN server URLS and long term credentials provided by the either broadcasting service or an external TURN provider. </del> <ins> It is also possible to configure the STUN/TURN server URLs with long term credentials provided by either the broadcasting service or an external TURN provider. </ins> 4.5. <del> Authentication and authorization is supported by the Authorization HTTP header with a bearer token as per RFC6750. </del> <ins> Authentication and authorization MAY be supported on the WHIP endpoint and the WHIP resource by providing the Authorization HTTP header with a bearer token as per RFC6750. </ins> 4.6. Both simulcast and scalable video coding (including K-SVC modes) MAY <del> be supported by both media servers and WHIP clients and negotiated in the SDP O/A. </del> <ins> be supported by both the media servers and WHIP clients through negotiation in the SDP offer/answer. </ins> If the client supports simulcast and wants to enable it for publishing, it MUST negotiate the support in the SDP offer according

Discussion:
I gave the spec a good read through and would like to propose some minor language edits as my first contribution. Most of these are straight forward such as: WebRTC not webrtc URI not uri signaling not signalling offer/answer not O/A some grammatical changes There is one somewhat significant correction here in that the header on the example WHIP endpoint reply pointed at the RFC for the extension. I believe this is incorrect and the intent is that this points at a WHIP resource. I have updated the example as such.
Change:
4.1. <ins> Any WebTransport protocol SHALL provide the following operations on the session: Create a new WebTransport session given a URI RFC3986 and the origin RFC6454 of the requester. Terminate the session while communicating to the peer an unsigned 32-bit error code and an error reason string of at most 1024 bytes.  The error code and string are optional; the default values are 0 and "". Any WebTransport protocol SHALL provide the following events: Indicates that the WebTransport session has been terminated, either by the peer or by the local networking stack, and no user data can be exchanged on it any further.  If the session has been terminated as a result of the peer performing the "terminate a session" operation above, a corresponding error code and an error string can be provided. 4.2. </ins> A datagram is a sequence of bytes that is limited in size (generally to the path MTU) and is not expected to be transmitted reliably.  The general goal for WebTransport datagrams is to be similar in behavior

Discussion:
Currently, in the W3C API draft, we cite the HTTP/3 draft and RFC 9000 directly. This does not work with WebTransport over HTTP/2, hence we need for the overview draft to provide a common set of operations that both H3 and H2 versions of the draft are expected to implement.
cc NAME NAME NAME NAME
How does this square with the set of features that we list in the overview draft -- right now it looks like we'll just have two lists. Do we want to do anything to relate them / break things down as being part of each feature? (Not saying that's strictly necessary, just curious if we'd thought about it)
Chair: discussed at 113, request for folks to review this PR
Thanks everyone for the comments! I've revised the PR; please take another look. By features, you mean the requirements in the section above that? Those are somewhat different in nature, I feel. The features are the list of things that I should be able to do with a WebTransport, whereas the requirements are on how it is supposed to work (e.g. you must use TLS, etc).
(no hats) overall this LGTM, my comments are minor
Change:
If set to true, this element indicates that the client must authenticate with a certificate by sending Certificate and a <del> CertificateVerify message.  The server MUST omit the CertificateRequest message, as its contents are redundant. OPEN ISSUE: We don't actually say that you can omit empty messages, so we need to add that somewhere. </del> <ins> CertificateVerify message.  If the CertificateRequest message does not add information not already conveyed in the template, the server SHOULD omit it. </ins> In JSON, this value is represented as "true" or "false".

Discussion:
Empty messages must now be included. If the body is known to be empty from the template, this costs one byte. This change also adjusts the explanation of and , and corrects the example.
NAME points out that EndOfEarlyData is an empty message that is semantically meaningful and cannot be predicted by the recipient.
Change:
unpredictable values.  The last 16 bytes of the datagram contain a Stateless Reset Token. <del> An endpoint that receives a packet where removal of packet protection fails MUST check the last 16 bytes of that packet.  If the last 16 bytes of the packet are identical to a stateless reset token corresponding to a packet that was recently sent, the endpoint MUST NOT send any further packets; all state for the connection can then be discarded. </del> To entities other than its intended recipient, a stateless reset will be appear to be a packet with a short header.  For the packet to appear as valid, the Unpredictable Bits field needs to include at

Discussion:
We don't want to prohibit the use of long headers in other versions - in case they want to share the stateless reset design, but there is no sense in sending long headers.
While I agree with the issue, the PR says that other versions might want to reset with a long header and therefore the receiver must inspect long headers anyway. I can see this, but given that, I think it is pointless to require the current version to only send resets for short headers. A general advice ought to suffice since the MUST is not enforceable anyway.
The requirement exists to protect those packets from detection.
Please don't close issues until AFTER consensus is declared (not just called).
I suspect Martin was confused because this issue was tagged has-proposal 15 days ago.
Right. The trigger is , not .
But it's understandable Martin would have assumed this was one of the issues that was sent out in the batch of issues a week and a half ago, given this has been tagged with has-proposal for 15 days.
Change:
to a different issuer or a different token type, to allow clients to choose a preferred issuer or type. <ins> An origin MUST NOT assume that token challenges will always yield a valid token.  Clients might experience issues running the issuance protocol, e.g., because the attester or issuer is unavailable, or clients might simply not support the requested token type.  Origins SHOULD account for such operational or interoperability failures by offering clients an alternative type of challenge such as CAPTCHA for accessing a resource. To mitigate the risk of deployments becoming dependent on tokens, clients and servers SHOULD grease their behavior unless explicitly configured not to.  In particular, clients SHOULD ignore token challenges with some non-zero probability.  Likewise, origins SHOULD randomly choose to not challenge clients for tokens with some non- zero probability.  Moreover, origins SHOULD include random token types in token challenges with some non-zero probability. </ins> 4. The security properties of token challenges vary depending on whether

Discussion:
From IETF 114 discussion: For the general captcha use cases, we don't want websites to rely on privacy pass always working, to preventing locking out other clients. We should likely have discussion in the architecture document to suggest approaches to make sure servers can't rely on this for generic clients (like browsers). Randomly not responding with tokens, other client-side heuristics.
I would put this in the auth-scheme document, where we already discuss user experience things. I'll propose some text that we can wordsmith.
Change:
Implementers need to pay close attention to the isolation and protection of the Attester and the factory processes for provisioning <del> the Attestation key material.  When either of these are compromised, </del> <ins> the Attestation key material.  If either of these are compromised, </ins> the remote attestation becomes worthless because the attacker can forge Evidence.

Discussion:
Signed-off-by: Dave Thaler
"It is assumed that the Attester is located in an isolated environment of a device like a process, a dedicated chip a TEE or such that collects the Claims, formats them and signs them with an Attestation Key." The grammar seems off to me. Should be: "It is assumed that the Attester is located in an isolated environment of a device such as; a process, a dedicated chip, a TEE, a virtual machine, a secure mode of operation or other forms of domain isolation that allows collection of Claims from the target environment where the target environment cannot lie or interfere with the claims collection function. Additionally, the Attester formats collected Claims and integrity protects them with an Attestation Key that also is domain isolated such that the target environment or some other entity other than the Attester is not able to undermine the Attester's protections"
Change:
where <del> label is a registered uint from the EDHOC Exporter Label registry (exporter-label) </del> <ins> exporter_label is a registered uint from the EDHOC Exporter Label registry (exporter-label) </ins> context is a bstr defined by the application

Discussion:
In the latest commit there are new names to distinguish infolabel and exporterlabel, the former is extended to be int. I also noted an error in the CDDL reference section C.2.
The current design of encryption of message2 in EDHOC limits the size of the message to 8160 bytes when SHA-256 is used. Is that a problem? message2 consists of the fields GY IDCREDR SignatureorMAC2 CR and optional fields: ? PAD2 ? EAD2 While these message fields could be very small, depending on use case, some may be arbitrarily large. The field IDCREDR would typically be a reference to an authentication credential, but may contain the credential itself, for example a certificate chain. EAD2 is defined by the application so may a priori be large. One example is revocation information. John: SHA-384 has the limit 12240 bytes and SHA-512 has the limit 16320 bytes. SHAKE128 and SHAKE256 have much much larger limits (2^2040 − 1 bits)
Some of the alternatives: Do nothing / this is not a problem Replace HKDF with HKDF', which allows larger length of output Use HKDF for message2 size < 8160, HKDF' for larger message2 Replace message_2 encryption with AES-CTR / ChaCha20 Use KMAC instead of HKDF Edit: Multiple applications of HKDF, to produce sufficiently long keystream John: HKDF' here refer only to HKDF-Expand. HKDF-Extract would stay the same. John: HKDF' would still be HKDF but not HKDF as specified in RFC 5869. The original HKDF paper just states that the counter is fixed length. RFC 5869 unfortunately chose 1 byte. URL
It seems that this is a concern if/when GY or SignatureorMAC2 becomes one of the monstrous Post-Quantum algorithms, or a HSS. I think that we should rule that out of scope, say that when it happens that we'll do EDHOC2 based upon new constraints at the time. I think that 8K is probably enough for the certificate chain. That's a lot (100) of 802.15.4 fragments. So unless switching to HKDF' is really cheap, don't bother.
Thanks Michael.

Yes, the assumption so far has been "this is not a problem". NAME It would be good to understand the impact on implementation if we would come to a different conclusion. Please comment, on the examples below. Replace HKDF with HKDF', which allows larger length of output HKDF is constructed from HMAC using a counter which is 8 bits long. By defining HKDF' with 16 / 32 bits counter would make the output 2 MB / 137 GB (if I did the maths right) before the counter wraps. How is HKDF implemented today? Is it feasible to define your own variant, say with 32 bits counter? Use HKDF for message2 size >
PR is included in -16