jiebi/CodeConvo huggingface dataset:
Change:
of codecs sent to a remote party indicates what the local side is willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send. <del> However, not all parameters follow this rule; for example, the SRTP parameters RFC4568 sent to a remote party indicate what the local side will use to encrypt, and thereby what the remote party should expect to receive; the remote party will have to accept these parameters, with no option to choose a different value.  [[OPEN ISSUE: This is not correct because we removed SDES (https://github.com/rtcweb-wg/jsep/issues/10)]] </del> <ins> However, not all parameters follow this rule; for example, the DTLS- SRTP parameters RFC5763 sent to a remote party indicate what certificate the local side will use in DTLS setup, and thereby what the remote party should expect to receive; the remote party will have to accept these parameters, with no option to choose different values. </ins> In addition, various RFCs put different conditions on the format of <del> offers versus answers.  For example, a offer may propose multiple SRTP configurations, but an answer may only contain a single SRTP configuration.  [[OPEN ISSUE: See issue 10 above.]] </del> <ins> offers versus answers.  For example, a offer may propose an arbitrary number of media streams (i.e. m= sections), but an answer must contain the exact same number as the offer. </ins> Lastly, while the exact media parameters are only known only after an offer and an answer have been exchanged, it is possible for the

Discussion:
Also, update IceCandidate section to use consistent “m= line” terminology, and also make it clearer that use of MID, if present, is a MUST.
WFM
The current example in S 3.2 refers to SDES, but that's not in JSEP any more. We need a new example.
Change:
received for a sufficiently long path-idle delay, but SHOULD only release resource for the last available path if no traffic is received for the duration of the idle timeout, as specified in <del> section 10.1 of QUIC-TRANSPORT.  This means if all paths remain idle </del> <ins> Section 10.1 of QUIC-TRANSPORT.  This means if all paths remain idle </ins> for the idle timeout, the connection is implicitly closed. Server implementations need to select the sub-path idle timeout as a

Discussion:
Fix issue
I went ahead and replaced the references to RFC9000 by QUIC-TRANSPORT, and RFC9001 by QUIC-TLS. I have checked that this produced the expected XML V3.
RFC9000 is cited massively in the draft. It would be helpful to indicate to the reader where to look by indicating the section. Some change examples are provided below: and so on.
Side comment -- please see issue about the use of XML2RFC v3 syntax for links. We can do some of that, but not necessarily everywhere. We do expect that readers are familiar with QUIC V1. If we want to say "we are just in line with QUIC V1", then a global reference to RFC 9000 should suffice. If we want to say "please read this text in QUIC V1, we don't want to replicate here", then yes, we should refer to the specific section.
Thanks, Christian. That's the intent.
The draft is using old style references, such as "section 9 of {{RFC9000}}". Version 3 of XML2RFC defines a structure way to do that, such as: , which can be expressed in recent versions of Markdown as . The new style references don't change the text version much, but in the HTML rendering they generate direct references to the target section, which is nice for the readers.
Sorry, that's my fault because of my local build system. Will fix this for the next revision...
With the fixed references, it works now...
Change:
If a server reboots during operation it may need to synchronize state with requesting clients before continuing the interaction. <del> For example, with OSCORE it is possible to reuse a persistently stored security context by synchronizing the Partial IV (sequence number) using the Echo option. </del> <ins> For example, with OSCORE it is possible to reuse a partly persistently stored security context by synchronizing the Partial IV (sequence number) using the Echo option. </ins> When a device joins a multicast/broadcast group the device may need to synchronize state or time with the sender to ensure that

Discussion:
I did quite a lot of changes to the Echo parts as discussed earlier. The Echo parts are now clearer updated in requirements and general processing, and example implementations for Token Option Values. I wrote a reasonably long security consideration chapter and added the missing IANA section. I added updated Token handling which requires some changes to abstract and introduction. Removed some definitions that were not used. I have not touched the Request-Tag parts except for maybe some editorials.
I think you should already have write access to the repository; if you can't just push your changes, I'm afraid you'll have to ask Carsten to add you to the team at URL I'm merging this now to get things on, and am trying to add some fixes today still to upload this evening's state before the cut-off. A suggestion w/rt the pull request branches: could you just add commits rather than appending them (unless you're changing around in the same place)? That'd make it much easier to update one's mental model of the document.
The terms "blockwise request operation" and "blockwise response operation" are used (the former frequently, the latter only once), so I've reverted the line that drops them to their previous state in 382c308f3.
Change:
After the path validation procedure is completed, any pending send operation is resumed to the bound peer address. <del> path-challenge-reqs and path-response-reqs contain the requirements for the initiator and responder roles, broken down per protocol phase. </del> <ins> path-challenge-reqs and path-response-reqs list the requirements for the initiator and responder roles, broken down per protocol phase. </ins> 7.3.

Discussion:
Section 5 title "Off-path packet forwarding" should be "Attack model" instead? Also, is this the right position? ISTM this should go after we discuss the base challenge/response mechanics. There is also a missing premise, I think: "RRC is not designed to counter on-path attackers. These can never be distinguished from, for example, a genuine network device. However, RRC can resist off-path attackers when enhanced path validation ({{enhanced}}) is used."
Change:
encryption for all the domains for which it serves directly or indirectly (via Split mode).  This document defines a publication mechanism using DNS, but other mechanisms are also possible.  In <del> particular, if some of the clients of a hidden server are </del> <ins> particular, if some of the clients of a private server are </ins> applications rather than Web browsers, those applications might have the public key preconfigured.

Discussion:
I decided "hidden" was bad. NAME
+1 to the change. I think that this is the right direction.
Change:
secure CoAP operations.  This document specifies security enhancements to the Constrained Application Protocol (CoAP). <ins> [ Note to RFC editor: If C321 gets published before C280, then the RFC6347 references can be upgraded to draft-ietf-tls-dtls13-43 without the need for further changes; the reference is to 6347 here because that was the stable DTLS reference when the document was last touched by the authors. ] </ins> This document specifies two CoAP options, the Echo option and the Request-Tag option: The Echo option enables a CoAP server to verify the freshness of a request, synchronize state, or force a client to

Discussion:
We've mentioned outdated draft names at times. Details in individual commits, point-to-point updated in-PR too. The DTLS change is not so much an update but a not to the editor that they may update the reference at their discretion when the publication sequence is clear; I don't want to pull another normative dependency into our cluster because we don't normatively need anything from 1.3.
Change:
pto-handshake) for a new path, but the delay SHOULD NOT be considered an RTT sample. <del> Until the server has validated the client's address on the path, the amount of data it can send is limited to three times the amount of data received, as specified in Section 8.1 of QUIC-TRANSPORT.  If no data can be sent, then the PTO alarm MUST NOT be armed until datagrams have been received from the client. Since the server could be blocked until more packets are received from the client, it is the client's responsibility to send packets to unblock the server until it is certain that the server has finished its address validation (see Section 8 of QUIC-TRANSPORT).  That is, the client MUST set the probe timer if the client has not received an acknowledgement for one of its Handshake or 1-RTT packets, and has not received a HANDSHAKE_DONE frame. </del> Prior to handshake completion, when few to none RTT samples have been generated, it is possible that the probe timer expiration is due to an incorrect RTT estimate at the client.  To allow the client to

Discussion:
By not arming the alarm, we avoid the possibility of having the alarm expire, send nothing, and then be immediately re-armed over and over again. We've hit bugs like that a few times in our implementation, which is why I prefer this structure of not setting the alarm if you can't send anything.
From NAME in , this is not a nit: than three times as many bytes as the number of bytes they have received. I think that the intent was that the server limit its sending, including PTO.
Discussed in ZRH. Proposed resolution is "yes".
Repeating what I said earlier: it's not clear to me that not being able to arm the PTO timer when at the limit implies that PTO packets count against the amplification limit. The reason is that you could have already armed the PTO timer at the time you hit the limit. E.g., you might be streaming 0.5RTT and so send Initial, Handshake, arm timer, 0.5RTT.
NAME the PTO should be updated when an ack-eliciting packet is sent, since the right edge moves, so that case should already be handled correctly. I'll write an editorial PR to try to make all this extra clear. Actually, the PTO section already has "A sender computes its PTO timer every time an ack-eliciting packet is sent."
Not sure how to split the difference between the limit applying to the packet that was just sent (causing PTO to be armed) or the packet that arming the PTO timer implies. Personally, I would have put the test at the point that you send a packet, but that's not how this is structured, and you do have "because packets sent on PTO count against the anti-amplification limit", which captures the important concept neatly.
Change:
filter expression: Its only argument is an instance of "ValueType" (possibly taken from <del> a singular query as in the example above).  The result also is an </del> <ins> a singular query, as in the example above).  The result also is an </ins> instance of "ValueType": an unsigned integer or "Nothing". If the argument value is a string, the result is the number of

Discussion:
Any parameter type works with
Indeed. We could make the example more general by not talking about the parameter type there.
Or by adding a bit variety. Done.
How does this work with a parameter?
It doesn't. Example needs to be fixed. Thanks.
Ref: URL Currently is not allowed. The argument is that we've not defined as resulting in a instance (an artifact of not extending the type system to the whole expression), but I don't really see a problem with allowing it. It's pretty intuitive. I can see applications where you'd want an argument to a function to be whether a location in a path is a certain value, e.g. . An function could work this way.
If we extend the use of the type system in this way (any would be of type , possibly after implicit conversion from ), we should also roll out the other types across the spec. Then any would have type and any would have type . This fixes a bug in the current spec which I've only just noticed. The and functions are assumed to be able to take Singular Queries, but as the spec is currently written, these would need converting to using the function.
Thanks. Updating jpt to the new semantics and running it over the spec to find inconsistencies was what I wanted to do over the weekend...
I can next work on implementing this issue on Saturday.
PR attempts to implement this issue using a point solution rather than attempting to roll out the type system across the whole spec.
Approving with several suggestions that I believe will complete the remaining editorial work. (I raised some editorial nits unrelated to this PR in issue URL)
Change:
Note: This is a different construction from that in TLS 1.2, which specified a partially explicit nonce. <del> The plaintext is the concatenation of TLSPlaintext.fragment and TLSPlaintext.type. </del> <ins> The plaintext is the concatenation of TLSPlaintext.fragment, TLSPlaintext.type, and any padding bytes (zeros). </ins> The AEAD output consists of the ciphertext output by the AEAD encryption operation.  The length of the plaintext is greater than

Discussion:
This sentence in general seems redundant, but if it's going to be included it should be correct.
Change:
ECDH functions are used as follows: <del> The public key to put into ECPoint.point structure is the result of applying the ECDH function to the secret key of appropriate length (into scalar input) and the standard public basepoint (into u-coordinate point input). </del> <ins> The public key to put into the KeyShareEntry.key_exchange structure is the result of applying the ECDH function to the secret key of appropriate length (into scalar input) and the standard public basepoint (into u-coordinate point input). </ins> The ECDH shared secret is the result of applying ECDH function to the secret key (into scalar input) and the peer's public key (into

Discussion:
(Let me know if you think this is sufficiently non-trivial that it deserves a mailing list posting. It is a wire format change, but I think a fairly boring one.) Only the outer length prefix is necessary, not the inner one. Named groups can just as easily take a byte string with known length rather than need to parse fields out. This is consistent with the definition of DigitallySigned.signature; the signature is an opaque field which is passed as a byte string into the corresponding signature algorithm. The definition of rsapsssha256 does not define an inner u16 length prefix. It simply takes the opaque byte string and passes it into the rsapsssha256 function. (In fact, this change means KeyShareEntry and DigitallySigned structures exactly parallel.) This also fixes some references to non-existent structures like ECPoint and dh_Yc. (Those seem to be remnants of TLS 1.2.)
Change:
in the context of the evaluation of a filter expression (described later). <del> 1.3.2. </del> <ins> 1.4.2. </ins> Segments can use the

Discussion:
The text will be adjusted in a future PR.
This github bug is slowing me down a bit:
Huh! I'm not seeing that.
I'm only seeing it every second time I try to pull the repo state (issues, PRs) into emacs, which seems to use a graphql API. Annoying. This used to work well...
Thanks!
Change:
sha1_RESERVED(2), sha224_RESERVED(3), sha256(4), sha384(5), sha512(6), (255) } HashAlgorithm; <ins> [[TODO: IANA considerations for new SignatureAlgorithm value]] </ins> Each SignatureAndHashAlgorithm value lists a single hash/signature pair that the client is willing to verify.  The values are indicated in descending order of preference.

Discussion:
This is stated to exist in the definition for "signature", however the value wasn't actually added to the enum. ( URL )
Change:
request streams, even in the presence of HTTP intermediaries.  The Capsule Protocol can be used to exchange HTTP Datagrams, which is necessary when HTTP is running over a transport that does not support <del> the QUIC DATAGRAM frame. </del> <ins> the QUIC DATAGRAM frame.  The Capsule Protocol can also be used to communicate reliable and bidirectional control messages associated with a datagram-based protocol even when HTTP/3 Datagrams are in use. </ins> 3.1.

Discussion:
Editorial suggestions from WGLC review
This protocol is being introduced with one use case, and that case is a generalisation that's capable of incorporating almost anything (datagrams). Is this a case of premature abstraction? While from an implementation standpoint this abstraction might not be expensive, adding a new abstraction to HTTP's core data model isn't something we should do lightly; the road is littered with failed and poorly-integrated attempts.
At the MASQUE Interim in April 2021, the WG reached consensus on strongly associating HTTP Datagrams with requests, and the fact that HTTP Datagrams would work across intermediaries. We also established that there was a need to register context semantics end-to-end. That same day, Ben Schwartz proposed the name capsule for such a system and we've kept it since. In the past year, we've thoroughly discussed capsules among the Working Group, and the possibility of premature optimization was discussed. The Working Group decided that this was a useful abstraction, and CONNECT-IP and WebTransport both started using the abstraction, confirming that it was useful. The final design of the Capsule Protocol came out of the HTTP Datagrams design team, was presented at the February 2022 MASQUE Interim and Working Group consensus was declared by the chairs . Unless you have any new information that would warrant revisiting this consensus, I'd suggest closing this issue with no action.
Closing this based on the comment above since today marks the end of WGLC
LGTM, thanks! Hearing no objections, we’re declaring consensus. Thanks again to the participants of the Design Team for their hard work in preparing these changes, and to everyone else for offering reviews and feedback! Best, Chris and Eric
Change:
Home and building automation use case: Tie in with RD <ins> M2M use case: Move system design paragraph towards the topic of reusability. </ins> Simple registration: Rather than coopting POSTs to /.well-known/ core, a new resource /.well-known/rd is registered.  A historical note in the text documents the change.

Discussion:
See-Also: URL (as per 2020-10-08 interim) Thank you -- I found this document to be a very friendly read. The Terminology section in particular was one of the best in recent memory. Comments: 1: "These CTs arethought to act on behalf of endpoints too constrained, or generally unable, to present that information themselves. " This reads very oddly - "thought to act on" sounds like we've seen some of these in the wild, and only have a vague idea about how they work. Does "These CTs act on behalf of endpoints too constrained, or generally unable, to present that information themselves. " work? 2: "From the system design point of view, the ambition is to design horizontal solutions that  can enable utilization of machines in different applications depending on their current availability and capabilities as well as application requirements, thus avoiding silo like solutions" - this is very buzzwordy, and I have no idea what it is actually trying to say... 3: "  A (re-)starting device may want to find one or more RDs for discovery purposes." Either I don't understand what this sentence is  trying to say, or "for discovery purposes" should be dropped....  4: "As some of the RD addresses obtained by the methods listed here are just (more or less educated) guesses, endpoints MUST make use of any error messages to very strictly rate-limit requests to candidate IP addresses that don't work out. " What happens if device A discovers RD X, and device B discovers RD Y? Surely there has to be some sort of deterministic method so that one doesn't end up in a "split brain" type outcome? Nits: 1: " The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD." While  true, this sentence doesn't actually communicate anything useful to the reader -- I'd suggest removing it from the Abstract (note that this is just a nit). 2: "The RD is primarily a tool to make discovery operations more efficient than querying /.well-known/core on all connected devices, or across boundaries that would be limiting those operations." s/would be limiting those/that would limit those/
Change:
RFC8366bis contains the two needed voucher extensions: est-domain and additional-configuration which are needed when a client is redirected <del> to a local EST Registrar. </del> <ins> to a local EST server. </ins> 6.

Discussion:
what is the "EST Registrar"? It is not defined so far. Wouldn't it be better to use RFC 8995 terminology of "EST server" ? So if the cloud Registrar supplies the Voucher and that redirects to an owner's EST server, we can call that "EST server" or "owner EST server". It's not a Registrar, so not "EST Registrar" or "owner Registrar". The latter term is already used for the server that provides a voucher to the pledge. (Interesting to consider that the owner's EST server could be a Registrar i.e. handing out vouchers in theory, even if the cloud-Registrar-supporting-pledge already got its voucher from the cloud-Registrar. But let's not say such things in the document to avoid complicating it.)
Change:
The remainder of the packet has version-specific semantics. <del> 4.3. </del> <ins> 5.3. </ins> A connection ID is an opaque field of arbitrary length.

Discussion:
Remove the normative reference to -transport in -invariants. This is an editorial change, but I'll pass it to the list. Includes some consistency updates.
Yes, but I think that - at least in principle - each should be as independent of the other as possible. Sure, -transport is a concrete instantiation of -invariants, but you can implement it without -invariants. Similarly, -invariants exists to support -transport, but it describes something bigger than it. So while we might have some pointers, you can read each without the other, which is nice.
introduced a new bespoke packet format. I don't have issues with the format itself, but as I reviewed I was surprised to see it used there without any explanation as to how to decipher it. I think it would be nicer if each document that uses this format either: References the "Notational Conventions" section from draft-ietf-quic-transport Has a "Notational Conventions" section of its own explaining this format
-- URL There is a lot more that the document leans on than the packet format grammar, so any expansion of this might explode. I tend to think that this is adequate.
I agree that the reference is sufficient, except for one aspect: We do want the invariants drafts to be readable without needing to get into the v1 spec, because the target audience is people who need to handle QUIC without regard to versions. I think it's wrong that the reference to QUIC-TRANSPORT is normative instead of informative, and this reference for conventions and definitions is the only reference in the doc that actually needs to be normative. I'm almost be more inclined to move the notation definition across, just as we ultimately did for the definition of VN, and let -transport refer to -invariants for it.
Looks good. Technically, we could reference this draft for the notation, but we don't need to if it makes transport easier to read.