jiebi/CodeConvo huggingface dataset:
Change:
5.3.3.1. Silence suppression in the answer is handled as described in <del> sec.voiceactivitydetection1. </del> <ins> sec.voiceactivitydetection1, with one exception: if support for silence suppression was not indicated in the offer, the VoiceActivityDetection parameter has no effect, and the answer should be generated as if VoiceActivityDetection was set to false.  This is done on a per-codec basis (e.g., if the offerer somehow offered support for CN but set "usedtx=0" for Opus, setting VoiceActivityDetection to true would result in an answer with CN codecs and "usedtx=0"). </ins> 5.4.

Discussion:
We reviewed the handling for G.729 and it's similar to Opus; there's a dtx=foo fmtp parameter to control receipt of DTX. I suggest we leave this parameter to createOffer as an indication on whether you want the remote side to use DTX, and add a frob on RtpSender (TBD exactly where) to directly control whether you use DTX. That frob is out of scope for this PR. For the PSAP/E911 case, the call will typically be over PCMU, and so it's covered through either of a) setting this parameter (which drops CN from the offered codecs), or b) the PSAP not responding with CN in the answer. So that's not an issue. We may need to add some text in the handling-a-remote-description section to make it clear that if the remote side says to use DTX (either through presence of CN, or usedtx=1), DTX MUST be engaged by the browser. We could also spell out the no-DTX case, if desired.
So plan is make this just about SDP, both offer and answer, along lines of Justin text. Then file issue to deal with happens with RTP sender.
Put in all Justin's comments from prev review.
In some codecs (e.g., Opus) requests to not do silence suppression are advisory. We should consider whether we require browsers to respect them so that counterparties which need the browser to not do silence suppression can force that.
I think it would make the most sense for this to behave identically regardless of codec. IOW, if not offered, it can't be indicated in the answer. The answer can of course reject a proposal to use VAD (currently via AnswerOptions), but there could perhaps be another surface for this.
Decision in Kirkland: if offer indicates no VAD (either through lack of CN, or usedtx=0), answer MUST not specify VAD. This is done on a per-codec basis, e.g. if answerer receives CN + usedtx=0, and answerer says Vad:True, answer will have CN + usedtx=0.
Fixed by
Change:
The WT_RESET_STREAM frame defines the following fields: <del> Stream ID: A variable-length integer encoding of the WebTransport stream ID of the stream being terminated. </del> <ins> A variable-length integer encoding of the WebTransport stream ID of the stream being terminated. </ins> <del> Application Protocol Error Code: A variable-length integer containing the application protocol error code that indicates why the stream is being closed. </del> <ins> A variable-length integer containing the application protocol error code that indicates why the stream is being closed. </ins> Final Size: A variable-length integer indicating the final size of the stream by the WT_RESET_STREAM sender, in units of bytes.  This is

Discussion:
Make the definition of fields use definition lists. Use superscripts where appropriate. Also, fix this so that it is 2^62-1 and not 2^61 (parentheses were used incorrectly).
Change:
adjust the maximum idle timeout based on the number of open or expected connections as shorter timeout values may free-up memory more quickly.  If an application desires to keep the connection open <del> for longer than the announced timeout, it can send keep-alives </del> <ins> for longer than the announced timeout, it can send keep-alive </ins> messages, or a QUIC implementation may provide an option to defer the <del> time-out to avoid unnecessary load, as specified in Section 10.2.2 of </del> <ins> time-out to avoid unnecessary load, as specified in Section 10.1.2 of </ins> QUIC.  See resumption-v-keepalive for further guidance on keep- alives.

Discussion:
The ops drafts often reference the core drafts by section number; make sure these section number references are correct for the WGLC drafts.
Correcting overcorrections regarding capitalization, but this seems benign.
Change:
block traffic, and some method to alert the user.  Common methods of alerting the user involve modifying HTTP or DNS traffic. <del> Problems with captive portal implementations have been described in I-D.nottingham-capport-problem.  [If that document cannot be published, consider putting its best parts into an appendix of this document.] </del> This document standardizes an architecture for implementing captive portals that provides tools for addressing most of those problems. We are guided by these principles:

Discussion:
This was an old, expired submission, unlikely to be revived. The intro provides enough context about what is wrong with captive portals. A problem statement rfc could always be made in the future if necessary, so let's just keep this document focused on the solution.
This paragraph still exists in the document: Problems with captive portal implementations have been described in [I-D.nottingham-capport-problem]. [If that document cannot be published, consider putting its best parts into an appendix of this document.] Maybe pull in sections 3 & 4 from URL ?
NAME I'm fine taking Dave's suggestion to pull in those sections. However, I'm not sure of the best way to attribute the content to that original document/its author. I imagine simply acknowledging Mark is sufficient, but if there is a better practice, please let me know.
Though I am somewhat concerned that it's a lot of text, and could be contentious if we're adding it after last call. For example statements like the one about access only being possible to steal in an insecure wireless network--I'm not convinced that's actually true. Given that this document wasn't really vetted, perhaps it'd be better to just try to summarize in the intro some of the more salient points.
Yes, if we pull in additional text, then I might feel obligated to run another last call. We can ask Mark for permission (not at-mentioning here yet), but I want to understand what this document lacks that Mark's has. My sense is that the text can be just cut, or the problem statement summarized in one of two paragraphs.
Good question. I think the nottingham problem statement was very useful for thinking about the problem and what to avoid. But we do have the guiding principles in the introduction. It would certainly be easier to just drop the mention of it, and focus on what should be vs. what should not be.
Change:
future TLS versions or new TLS extensions introduced in the future may vary this computation.) <del> An ECDHE key exchange using Curve25519 goes as follows.  Each party picks a secret key d uniformly at random and computes the corresponding public key x = Curve25519(d, G).  Parties exchange their public keys and compute a shared secret as x_S = Curve25519(d, x_peer).  ECDHE for Curve448 works similarily, replacing Curve25519 with Curve448.  The derived shared secret is used directly as the premaster secret, which is always exactly 32 bytes when ECDHE with Curve25519 is used and 56 bytes when ECDHE with Curve448 is used. </del> <ins> An ECDHE key exchange using X25519 (curve ecdh_x25519) goes as follows: Each party picks a secret key d uniformly at random and computes the corresponding public key x = X25519(d, G).  Parties exchange their public keys, and compute a shared secret as x_S = X25519(d, x_peer).  If either party obtains all-zeroes x_S, it MUST abort the handshake (as required by definition of X25519 and X448). ECDHE for X448 works similarily, replacing X25519 with X448, and ecdh_x25519 with ecdh_x448.  The derived shared secret is used directly as the premaster secret, which is always exactly 32 bytes when ECDHE with X25519 is used and 56 bytes when ECDHE with X448 is used. </ins> All ECDSA computations MUST be performed according to ANSI X9.62 or its successors.  Data to be signed/verified is hashed, and the result

Discussion:
Replace uses of Curve25519 with X25519 (and similarly with 448-bit one). Also add zero checks as required by CFRG-CURVES. Because of problems with TLS 1.2 key exchange, omitting these checks leads to security issues.
Renamed the curves to be consistent with what got merged into TLS 1.3 spec
Change:
issuance protocol to actually fetch tokens to redeem. In addition to working with different token issuance protocols, this <del> scheme supports both interactive (online challenges) and non- interactive (pre-fetched) token redemption, as well as the ability to scope a token to a specific resource or origin.  Relying parties that request and redeem tokens can choose a specific kind of token, as appropriate for its use case.  For example, non-interactive token redemption that is not scoped to a specific origin can be used as a replacement for CAPTCHAs, as exemplified by the original Privacy Pass work DGSTV18. </del> <ins> scheme supports optionally associating tokens with origin-chosen contexts and specific origin names.  Relying parties that request and redeem tokens can choose a specific kind of token, as appropriate for its use case.  These options allow for different deployment models to prevent double-spending, and allow for both interactive (online challenges) and non-interactive (pre-fetched) tokens. </ins> 1.1.

Discussion:
We should consider renaming to . This value doesn't need to be a nonce, it's just some origin-selected context that it is binding to. We can also rename the in the Token struct to to make it clear what role it has.
Change:
Name: The name of the credential type <del> Recommended: Whether support for this credential is recommended by the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. </del> <ins> Recommended: Same as in </ins> Reference: The document where this credential is defined

Discussion:
Also copies the "Recommended" field by reference, instead of reciting it in each registry. Note that this has a conflict with that will not catch -- "MLSContentTBS" will have to be changed to whatever new name is agreed in that PR.
The of absolutely needs to be unique for every signature happening in the protocol, for security and avoid signature ambiguity. That includes signatures happening in extensions. Should this be referenced in a IANA considerations to ensure there is no conflict in the future? Or at least say something about this somewhere? We have to think how to design things well here to be future-proof: the structure must be used for every signature done with the leaf signature keys, which includes what might happen in extensions but also in future versions of MLS. If future versions of MLS could avoid doing , that would be great!
This seems to come down to whether we expect the signature keys used for MLS authentication to be used outside of MLS (otherwise there's no risk of confusion) and if so, whether this spec has any influence on that usage. If you're using your MLS key to sign Bitcoin transactions, we can't do much to help that. Note that there is not an issue for future version of MLS here. The label is constructed as , so a future version could just increment the part of that. Given all that, I might prefer a recommendation that signature keys not be reused across contexts, rather than trying to accommodate reuse. If we do something here, we should do something analogous to the registry, which are similarly intended for domain separation between different use cases. We should probably consider making an exporter label registry anyway.
I agree, we shouldn't do anything about someone using the MLS signature key in another protocol. About future MLS versions: I agree, but note that there is a length tag before that. It means that we impose to all signature of future MLS versions to start with (including the quic integer) Is it something acceptable or not, I don't now. I just think we should have in mind that the decisions we make now on will have an impact on the design of future MLS versions. About extensions: in the extensions document, there is a signature computed with If two extensions were to use the same label then this could lead to security problems, this is why I think the labels should be in some registry to ensure they are all unique.

One other thing we could do is to separate all extensions signatures from the core MLS signatures, for exemple using the label "MLS 1.0 extension [label from extension]"? Like that a bogus extension can't introduce a security flaw in core MLS that way?
Change:
For any specified "CT" bandwidth value, set this as the limit for the maximum total bitrate for all m= sections, as specified in <del> Section 5.8 of RFC4566.  The implementation can decide how to allocate the available bandwidth between m= sections to simultaneously meet any limits on individual m= sections, as well as this overall session limit. </del> <ins> Section 5.8 of RFC4566.  Within this overall limit, the implementation can dynamically decide how to best allocate the available bandwidth between m= sections, respecting any specific limits that have been specified for individual m= sections. </ins> For any specified "RR" or "RS" bandwidth values, handle as specified in RFC3556, Section 2.

Discussion:
Originally raised by Magnus: o For any specified "CT" bandwidth value, set this as the limit for the maximum total bitrate for all m= sections, as specified in Section 5.8 of [RFC4566]. The implementation can decide how to allocate the available bandwidth between m= sections to simultaneously meet any limits on individual m= sections, as well as this overall session limit. I think this text can be improved to make it clearer that CT doesn't imply a fixed over time divide of the bandwidth between RTP streams. As long as individual media sources streams stay within other requirements such as b=AS/TIAS they can be changed dynamically.
Makes sense.
Change:
Connections between the , Oblvious Relay Resource, and MUST use HTTPS in order to provide unlinkability in the presence of a network <del> observer.  The scheme of the encapsulated request determines what is used between the Oblivious Gateway and Target Resources, though using HTTPS is RECOMMENDED; see server-responsibilities. </del> <ins> observer.  The scheme of the determines what is used between the Oblivious Gateway and Target Resources, though using HTTPS is RECOMMENDED; see server-responsibilities. </ins> To achieve the stated privacy goals, the cannot be operated by the same entity as the . However, colocation of the and simplifies the

Discussion:
We weren't always capitalizing "Encapsulated Request". This does more, in direct opposition to the changes in . If we don't take that (it seems we at an impasse there), then we should at least be consistent.
NAME I resolved conflicts, but please double check the intro paragraph that had Mark's proposed changes.
Change:
resolver.  "Designated" in this context means that the resolvers are operated by the same entity or cooperating entities; for example, the resolvers are accessible on the same IP address, or there is a <del> certificate that claims ownership over both resolvers. </del> <ins> certificate that claims ownership over the IP address for the original designating resolver. </ins> 1.1.

Discussion:
We only require you to check the designated resolver IP so this text is now incorrect.
lgtm
How's this?
lgtm v2
Change:
The "JWK_Thumbprint" step indicates the computation specified in RFC7638, using the SHA-256 digest.  As specified in the individual challenges below, the token for a challenge is a JSON string <del> comprised entirely of characters in the URL-safe Base64 alphabet. </del> <ins> comprised entirely of characters in the URL-safe base64 alphabet. </ins> The "||" operator indicates concatenation of strings. In computations involving key authorizations, such as the digest

Discussion:
Also fix an example date and fix an RFC reference to not be redundant.
Merging based on manual review, since CircleCI for PRs seems to be busted.
Change:
9.5. <ins> This document registers the following entries in the "COSE Header Parameters" registry under the "CBOR Object Signing and Encryption (COSE)" heading.  The value of the 'cwt' header parameter is a CWT RFC8392 or an unprotected CWT Claims Set I-D.ietf-rats-uccs. 9.6. </ins> IANA has added the COSE header parameter 'kid2' to the COSE Header Parameters registry.  The kid2 parameter may point to a COSE key common parameter 'kid' or 'kid2'.  The kid2 parameter can be used to identity a key stored in a "raw" COSE_Key, in a CWT, or in a certificate. <del> 9.6. </del> <ins> 9.7. </ins> IANA has added the COSE key common parameter 'kid2' to the COSE Key Common Parameters registry. <del> 9.7. </del> <ins> 9.8. </ins> IANA has added the well-known URI 'edhoc' to the Well-Known URIs registry.

Discussion:
Discussion today in COSE on how to do RPK by value in EDHOC. Suggestions to send a COSE_Key or a C509. Additional suggestion from Carsten to use CWT. Several issues in the old GitHub on CWTs, that were not transfered to the new GitHub: URL URL URL Discussion to transfer CWT in kid, in Auxilery data, and as COSE header parameter. Transfering CWT is related to issues , , ,
I made a pull request for this URL I think it is essential that EDHOC supports CWT. CWTs are much more flexible than X.509 / C.509. I think both are needed. The need for CWT has been discussed since 2016. I think it was decided clear quite early that transporting CWT is needed but was a discussion on how to transfer them. In Aux Data, in COSE header parameter, or in the kid bstr. For some reason nothing was ever specified. TLS WG is discussing to add support for CWT. URL I think certificates and CWT needs to be included, I am not sure that we need a different format for RPK. Likely CWT or C509 can be used for this purpose.
I think it should be discussed if CWT is good enough for the . My initial understanding is that it is but this needs to be analyzed and discussed. My current thoughts. CWT needs to be supported in EDHOC. Most things in CWT is optional, it is likely an optimized enough format for the oportunistic / TOFU use case of "RPK". CWT is also very flexible. When CWT exist it would be strange to standardize a new format for transfereing a COSEKey unless it is really really needed to save bytes. CWT + Deterministic CBOR could maybe replace the discussion on how to integrity protect COSEKeys. We should at least remove the new subjectname from the COSEKey part in the EDHOC document. CWT and C509 can be used when subject name is needed. Does "Raw" COSE_Keys that are not CWT even need to be supported? Or would CWT / C509 / X.509 be enough
This change has now been done in the master branch, see a1b25ba and commits in its vicinity. Can we close the issue?
This has now been addressed.
Change:
be lesser or equal than IP Protocol of B. If the IP Version and IP Protocol of A and B are both equal, the <del> End IP Address of A MUST be strictly lesser than the Start IP </del> <ins> End IP Address of A MUST be strictly less than the Start IP </ins> Address of B. If an endpoint received a ROUTE_ADVERTISEMENT capsule that does not

Discussion:
Edits collected while reading this draft. cc: NAME NAME
LGTM, thanks for this NAME !
Change:
Indicates that x is optional (and has length of L) <del> Indicates that x is repeated zero or more times (and that each instance is length L) </del> <ins> Indicates that zero or more instances of x are present (and that each instance is length L) </ins> This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte.

Discussion:
Not repetitions, which might be read to mean one or more occurrences. This change will conflict, but the conflict is easy to resolve.
NAME said:
It is zero or more occurrences is correct and will adjust the text accordingly.
Change:
firewalls will often not admit server traffic for which it has not kept state for corresponding packets from the client. <del> A QUIC application has three strategies to deal with this issue: </del> <ins> A QUIC application has three strategies to deal with this issue by adjusting idle periods (noting that idle periods and the network idle timeout is distinct from the connection idle timeout, defined as the minimum of the idle timeout parameter in Section 10.1 of QUIC): </ins> Ignore it, if the application-layer protocol consists only of interactions with no or very short idle periods, or the protocol's

Discussion:
"Idle period", "network idle timeout", and "idle timeout" are distinct; addresses a comment in .
in , NAME said: This probably needs its own discussion...
note that we use the words "idle timeout" two different ways in the applicability document: (1) the network idle timeout, which is the shortest state timeout of a device on a path between the endpoints (2) the endpoint idle timeout transport parameter, which is the point at which a connection will simply silently close. While addressing this question (which I interpret as "we present session resumption as a solution for clients, but what about servers?), we should also clear up the terminology.
Setting a QUIC endpoint idle timeout above 30 sec won't have much effect here because of the prevalence of 30s UDP network idle timeouts on middleboxes. So guidance here should max out at 30s. Given the variety of different ways VM live migration is implemented and the variety of network control planes that can be used to steer traffic in this situation, the guidance should also not be too low... so if there is guidance here I'd say it should be in the 10-30s range. NAME does this seem reasonable?
See also / reference RFC 4787 (for UDP) and RFC 7857 / 2663 (for TCP).
I'd suggest a min of 30 seconds as being sensible for the public internet, and longer may be preferable if the deployment can consistently survive NAT rebinds. We have applications with much longer(ie: 5 minute) timeouts in production, but they don't do hanging GETs and our infrastructure is designed to correctly handle NAT rebinds.
addressed by
Change:
not end with ".local" or if the value contains more than one ".", then process the candidate as defined in RFC8445. <del> Otherwise, use the value and resolve it using Multicast DNS. </del> <ins> Otherwise, resolve the candidate using mDNS. </ins> If it resolves to an IP address, replace the value of the ICE host candidate by the resolved IP address and continue processing of

Discussion:
Or alternatively consistently use mDNS, but mention in the intro that this refers to Multicast DNS {{RFC6762}}
Yeah, I think we should do the latter. That's what 6762 does.