jiebi/CodeConvo huggingface dataset:
Code change:
Change Controller: IESG <del> 9.6. </del> <ins> 9.7. </ins> IANA has added the media type 'application/edhoc' to the CoAP Content-Formats registry.

Related discussion:
text: But I also sympathize with not wanting to duplicate what is already defined in another RFC (and possibly getting it wrong, as Carsten points out). Considering that there are quite a few implementers already and besides mine you have only received one other similar comment, maybe this isn't an issue for a meaningful majority. In any case, the draft has made great strides already in terms of accessibility and is in a good state now, so I don't see improvements in this area as an absolute necessity.
The two COSE constructs that are used in EHDOC, and are fairly simple. They don't use the recursive structure or embed . I think it is possible to add some additional clarifications on the structure of the COSE messages in the EHDOC draft without having to copy too much text from RFC 8152. As part of a thesis I built a proof-of-concept implementation of EDHOC in the Rust programming language available at URL The naming of the repository is due to the subject being both EDHOC and OSCORE on embedded devices, but the following refers only to the EDHOC implementation. It's based on draft-selander-ace-cose-ecdhe-14 and as such, sadly, outdated. Since it was just one part of the overall work, I only managed to implement the subset I needed, which is RPK and the signature-signature based scheme (corresponding to what draft-selander-lake-edhoc calls method 0). I also took some other shortcuts, such as not supporting auxiliary data. Fortunately, test vectors were about to be introduced just around the time I was working on it, so I've been able to successfully verify my implementation against them when John shared them with me for some preliminary testing. Since I didn't have any prior experience implementing this kind of software, I would definitely consider it more of an experiment, but it's out there and it works, in case it can be useful to anybody. I'm convinced that EDHOC will be valuable particularly in the context of OSCORE, possibly even beyond that. As for the draft itself, I would like to mention one aspect that I think could be improved from the perspective of an implementer. Part of the promise of EDHOC is that it's simple and lightweight due to reusing COSE.
Code change:
Change Controller: IESG <del> 9.6. </del> <ins> 9.7. </ins> IANA has added the media type 'application/edhoc' to the CoAP Content-Formats registry.

Related discussion:
text: That is certainly the case, but breaks down somewhat when working on a system where no fully featured library for it is available. This was the case for me and I personally found it difficult to quickly figure out which aspects of COSE I needed to implement. The draft does a good job of pointing to the right places in RFC 8152, but I still ended up trying to understand another ~100 page document just to implement the few constructs I actually needed. I know the authors are aware of this and there has been some effort to inline more information directly in the specification, which I greatly appreciate. It would be very nice to have an entirely self-contained document to work with. But I have to again point out my lack of experience in that area, it's entirely possible that this draft is in fact much better than others in this regard and I just don't know it yet. With that I would like to support the adoption and am looking forward to seeing how it develops. Kind regards, Martin
Code change:
Indicates that x is A bits long Indicates that x uses the prefixed integer encoding defined in <del> Section 5.1 of RFC7541, beginning with an A-bit prefix. </del> <ins> prefixed-integers, beginning with an A-bit prefix. </ins> Indicates that x is variable-length and extends to the end of the region.

Related discussion:
text: Use more uniform and more specific language in description of instructions, like "follows" instead of "includes" or implicit mention of a field. Add references to integer and string encodings where missing. Prefer internal references to external ones (also in Section 1.2). Explicitly allow a header block to not have any instructions after the mandatory prefix. Refer to Literal Header Field With Name Reference section in Literal Header Field Without Name Reference instead of verbatim repeating text on 'N' bit. Reshuffle sentences, insert references instead, remove sentences where references suffice.
Mostly good improvements; a few things to fix up further.
Code change:
appearing in cleartext in a ClientHello.  As a result, a passive adversary can link two or more connections together that use the same external PSK on the wire.  Applications should take precautions when <del> using external PSKs if these risks. </del> <ins> using external PSKs to mitigate these risks. </ins> In addition to linkability in the network, external PSKs are intrinsically linkable by PSK receivers.  Specifically, servers can

Related discussion:
text: FIxed up: some nits on recommendations. I think the wording was a bit off on low entropy PSKs, so I lifted from ekrs text from earlier in the draft. some of the stack interface stuff on hints is not valid for TLS1.3 (hints are TLS1.2 and earlier), so removed it. Some prelim text on collisions. For completeness, will take a look at gnutls and wolfssl order too. Note, even with the OpenSSL callback sequence, the application still does not know if there is a collision...
Starter text from NAME
NAME can you please take this?
Ping NAME
Code change:
tree of Application Secrets as well as one symmetric ratchet per group member. <del> Each client maintains their own local copy of (parts of) the Application Key Schedule for each epoch during which they are a group member.  They derive new keys, nonces and secrets as needed while deleting old ones as soon as they have been used. </del> <ins> Each client maintains their own local copy of the Application Key Schedule for each epoch during which they are a group member.  They derive new keys, nonces and secrets as needed while deleting old ones as soon as they have been used. </ins> Application messages MUST be protected with the Authenticated- Encryption with Associated-Data (AEAD) encryption scheme associated <del> with the MLS ciphersuite.  Note that "Authenticated" in this context does not mean messages are known to be sent by a specific client but only from a legitimate member of the group.  To authenticate a message from a particular member, signatures are required.  Handshake messages MUST use asymmetric signatures to strongly authenticate the sender of a message. </del> <ins> with the MLS ciphersuite using the common framing mechanism.  Note that "Authenticated" in this context does not mean messages are known to be sent by a specific client but only from a legitimate member of the group.  To authenticate a message from a particular member, signatures are required.  Handshake messages MUST use asymmetric signatures to strongly authenticate the sender of a message. </ins> 11.1. <del> The Application schedule begins with the Application secrets which are arranged in an "Application Secret Tree" or AS Tree for short; a left balanced binary tree with the same set of nodes and edges as the epoch's ratchet tree.  Each leaf in the AS Tree is associated with the same group member as the corresponding leaf in the ratchet tree. Nodes are also assigned an index according to their position in the array representation of the tree (described in tree-math).  If N is a node index in the AS Tree then left(N) and right(N) denote the children of N (if they exist). </del> <ins> The application key schedule begins with the application secrets which are arranged in an "Application Secret Tree" or AS Tree for short; a left balanced binary tree with the same set of nodes and edges as the epoch's ratchet tree.  Each leaf in the AS Tree is associated with the same group member as the corresponding leaf in the ratchet tree.  Nodes are also assigned an index according to their position in the array representation of the tree (described in tree-math).  If N is a node index in the AS Tree then left(N) and right(N) denote the children of N (if they exist). </ins> Each node in the tree is assigned a secret.  The root's secret is simply the application_secret of that epoch.  (See key-schedule for

Related discussion:
text: Update change log for draft-07 No conflicting PRs so I did break many lines that were too long. Fix a few minor editorial issues after merging the tree-based application key schedule.
Code change:
7.2.1. <del> Packet protection for QUIC version 1 is specified is Section 5 of </del> <ins> Packet protection for QUIC version 1 is specified in Section 5 of </ins> QUIC-TLS.  The general principles of packet protection are not changed for QUIC Multipath.  No changes are needed for setting packet protection keys, initial secrets, header protection, use of 0-RTT

Related discussion:
text: Each line is limited to 72 characters.
I verified that this PR produces the draft that we expect. I did one small change: remove spaces at the end of lines.
There are many isntances in the markdown source where a whole paragraph is entered in a single line of text. This makes the reviewing harder, and messes up the "what changed" view when reviewing PRs.
Just to be on the same page, how should we format the text? I see two possible ways. Hard-constraint the number of characters per line to a given limit (e.g., 80) Make one sentence = one line I have a slight preference for option 2, but I can of course live with the other or a mix of both.
I would prefer something like 72 characters, because the last 8 positions are used for numbering the cards in your deck.
Code change:
"a=rid" lines. Each m= section is also checked to ensure prohibited features are <del> not used.  If this is a local description, the "ice-lite" attribute MUST NOT be specified. </del> <ins> not used. </ins> If the RTP/RTCP multiplexing policy is "require", each m= section MUST contain an "a=rtcp-mux" attribute.  If an "m=" section

Related discussion:
text: Page 62 has a bullet ending "If this is a local description, the 'ice-lite' attribute MUST NOT be specified." This sentence is leftover from before SDP munging was prohibited and should be removed.
Code change:
local description is supplied, and the number of transports currently in use does not match the number of transports needed by the local description, the PeerConnection will create transports as needed and <del> begin gathering candidates for them. </del> <ins> either withdraw an appropriate number of ICE candidates from the candidate pool or begin gathering candidates if sufficient pre- gathered candidates are not available. </ins> If setRemoteDescription was previously called with an offer, and setLocalDescription is called with an answer (provisional or final),

Related discussion:
text: NAME don't love the way the bit about the pool turned out but I don't have better text. Fixed. Consensus here was this is fine. No, this seems fairly clear. URL Done. Done. Do you mean RTP here? If so, I'm feeling OK about this. Done.
Merging and will tweak post-merge
Code change:
definitions) is closed.  A connection enters the draining state when the idle timeout expires. <del> Each endpoint advertises its own idle timeout to its peer.  The idle timeout starts from the last packet received.  In order to ensure that initiating new activity postpones an idle timeout, an endpoint restarts this timer when sending a packet.  An endpoint does not postpone the idle timeout if another packet has been sent containing frames other than ACK or PADDING, and that other packet has not been acknowledged or declared lost.  Packets that contain only ACK or PADDING frames are not acknowledged until an endpoint has other frames to send, so they could prevent the timeout from being refreshed. </del> <ins> Each endpoint advertises its own idle timeout to its peer.  An enpdpoint restarts any timer it maintains when a packet from its peer is received and processed successfully.  The timer is also restarted when sending a packet containing frames other than ACK or PADDING (an ACK-eliciting packet, see QUIC-RECOVERY), but only if no other ACK- eliciting packets have been sent since last receiving a packet. Restarting when sending packets ensures that connections do not prematurely time out when initiating new activity. </ins> The value for an idle timeout can be asymmetric.  The value advertised by an endpoint is only used to determine whether the

Related discussion:
text: I find this pretty hard to read, but assuming I am reading it corectly, it basically says that if you read any packet or write any packet that has a frame other than ACK or padding, then you reset the timer. The text about "other packet has not been acknowledged or lost" doesn't make sense unless you have some very complicated timer scheme, because the packet won't be acknowledge or lost until after it is sent, at which point I have already reset the timer.
Yeah, this is opaque. I think that the logic is something like: when receiving a packet, restart the idle timer when sending an ACK-eliciting packet. if you haven't sent other ACK-eliciting packets since the idle timer was started, restart the idle timer That is, if you send 10 packets, only the first of those restarts the timer. This clearly needs to be reworded.
I'd suggest one change to the second bullet, Martin. "when sending an ACK-eliciting packet. if you haven't sent other ACK-eliciting packets since the idle timer was restarted due to a received packet, restart the idle timer" And yes, that text is not clear.
I like the look of the wording change in ac59e11. Is there something blocking it from being applied?
Nothing. I just neglected to open the pull request. That happens sometimes. Lots of changes in flight...
I think this looks good, but NAME has more familiarity with this code than I do, so I'm adding him as well.
Code change:
A second approach that was considered but not chosen was to decouple the management of the media control objects from session descriptions, instead offering APIs that would control each component <del> directly.  This was rejected based on a feeling that requiring </del> <ins> directly.  This was rejected based on the argument that requiring </ins> exposure of this level of complexity to the application programmer would not be beneficial; it would result in an API where even a simple example would require a significant amount of code to

Related discussion:
text: Section 1.2 second paragraph - "This was rejected based on a feeling". Can you write something that speaks to consensus here? "Based on a feeling" isn't quite right. Maybe "using the argument"?
Sure.
LGTM
Code change:
The entries in the iana-error-table are registered by this document. <del> Additionally, each code of the format "0x1f * N + 0x21" for integer values of N (that is, "0x21", "0x40", ..., through </del> <ins> Additionally, each code of the format "0x1f * N + 0x21" for non- negative integer values of N (that is, "0x21", "0x40", ..., through </ins> "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. 11.2.4.

Related discussion:
text: Clarify reserved values for stream types, settings identifiers, frame types, and error codes. 0x1f N + 0x21 for the value of N = -1 is 0x02. Literal interpretation of the current text includes this as a reserved value. The parenthetical examples given in Section 11.2 make it clear that this was not the intention, rendering this PR editorial. The main motivation of this PR is not that the current text is inconsistent, but that parenthetical examples from 11.2 are necessary to correctly interpret the definitions in sections 6.2.3, 7.2.4.1, 7.2.8, and 8.1. Alternative wordings could be: "0x1f N + 0x21 for N = 0, 1, 2, ..." "0x1f N + 0x02 for positive integer values of N" "0x1f N + 0x02 for N = 1, 2, 3, ..." "0x21, 0x21 + 0x1f, 0x21 + 2 * 0x1f, ..." "a value of at least 0x21 with a remainder of 0x02 modulo 0x1f" "a value of at least 0x21 that is congruent to 0x21 modulo 0x1f" none of which is better than what this PR proposes.
Code change:
ESNI extensions (see grease-extensions), which helps ensure the ecosystem handles the values correctly. <del> 7.2.5. </del> <ins> 7.3.5. </ins> This design is not forward secret because the server's ESNI key is static.  However, the window of exposure is bound by the key lifetime.  It is RECOMMENDED that servers rotate keys frequently. <del> 7.2.6. </del> <ins> 7.3.6. </ins> This design permits servers operating in Split Mode to forward connections directly to backend origin servers, thereby avoiding unnecessary MiTM attacks. <del> 7.2.7. </del> <ins> 7.3.7. </ins> Assuming ESNI records retrieved from DNS are validated, e.g., via DNSSEC or fetched from a trusted Recursive Resolver, spoofing a

Related discussion:
text: Since OCSP is the server name, ESNI should probably enforce OCSP stapling (similar to ) or any other way of encrypted OCSP checks. Ignoring OCSP status checks entirely makes it hard to revoke a certificate, even if it's only valid for a few months.
NAME what behavior do you expect here? Would clients fail hard if server don't send stapled responses? It's good to view ESNI as part of the leaky boat problem. It plugs one hole, but not all of them. Implementations probably should do something about cleartext OCSP if they want all holes plugged.
Thank you for the changes. LGTM.
Code change:
Indicates that x is repeated zero or more times (and that each instance is length E) <ins> This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte. </ins> By convention, individual fields reference a complex field by using the name of the complex field.

Related discussion:
text: Editorial NiTs when reviewing the invariant text. These NiTs address readability issues, and do not intend to change the meaning of the text.
Is there an associated issue?
Thanks Gorry, these are all quite helpful. 1) I understand the acronyms DCID and SCID, but these aren't really expanded on first use in sect 5.1. 2) There's mention of "the high bit", but there doesn't seem to be any statement of bit order saying. Is it worth declaring network byte/bit order earlier in section 4? This also clarifies the placement of fields within a byte, which was basically assumed knowledge otherwise. 3) Personally, I don't think: "The length of the Destination Connection ID is not specified" is a great choice of words. Surely, this needs to be specified somewhere for a protocol instance to use it? This reads better as something like: The length of the Destination Connection ID is not encoded in packets with a short header and is not constrained by this specification. 4) The brackets here seem to point to connection IDs in general, not the DCID "(see Section 5.3)". Is it worth writing that as "Connection IDs are described in Section 5", rather than use brackets? The same is true for versions. 5) In section 5.3: "the wrong endpoint" is taken as the wrong transport endpoint, but some of our IP and subIP colleagues would use the term endpoint for other uses, so one insertion of "transport" would perhaps help? 6) In the appendix A, this: "QUIC forbids acknowledgments of packets" - still has me wondering what is actually intended to be understood, because the list of bullets is not guarenteed ... : /The last packet before a long period of quiescence might be assumed to contain an acknowledgment (it should be assumed that QUIC could allow acknowledgments of packets that only contain ACK frames)/ I'm not sure what to say here I think the combination of not... forbids threw me off the meaning. Changes proposed in
Thanks for changing SCID/DCID to "Source Connection ID" and "Destination Connection ID", that seems like a good change.
Code change:
Environments are designed specifically with claims collection in mind. <del> 4.2. </del> <ins> 4.3. </ins> By definition, the Attester role takes on the duty to create Evidence.  The fact that an Attester role is composed of several

Related discussion:
text: Previously the text was specific to policy for Evidence, but the same applies to policy for appraising Attestation Results, so generalizing the text. This also removes a redundant sentence where older text and newly merged text from this morning said the same thing. And the diffs look larger than they really are, since some text was just moved around to be in a different order. Signed-off-by: Dave Thaler
Code change:
further.  In this case, the immersive content is typically referred to as volumetric media.  One way to represent the volumetric media is to use point clouds, where streaming a single object may easily <del> require a bitrate of 30 Mbps or higher.  Refer to PCC for more details. </del> <ins> require a bitrate of 30 Mbps or higher.  Refer to MPEGI and PCC for more details. </ins> 2.2.

Related discussion:
text: Ali, this PR looks nice. Two meta-issues (which we can talk about whenever). I changed my references in the draft to a more complete format (using ins: can result in odd formatting in the References section). We don't have to do that for all the references in -04, but that would be a good thing to do in an editorial pass. I see that you're making some terminology changes (from "delivery" to "streaming", stuff like that). I agree with the changes you made in this PR, but we may want to make sure that they are made globally, for consistency.
I was not sure about the reference format, normally I just use the casual format: Authors, "Title," Journal/Conference, Date. I saw the missing author names and realized "ins" would do the trick. By no means, I am tied to that format - don't know even know what "ins" stands for here :)
From URL : "as in the author list, ins is an abbreviation for "initials/surname";" I tend to think an editorial pass on references would be better as a separate commit, where they need cleaning. Anything that somehow made it in and breaks the "make" needs fixing, but others maybe later?
I suggest a definition along these lines: Streaming is transmission of a continuous content from a server to a client and its simultaneous consumption by the client. ("simultaneous" is the key here) This has two implications: 1) Server transmission rate (loosely or tightly) matches to client consumption rate. That is, no buffer overrun or underrun is desirable/acceptable. 2) Client consumption rate is also limited by real-time constraints as opposed to just bandwidth availability. That is, client cannot fetch the content not available yet.
+1, this sgtm. But this probably implies a refactor of the intro section and the abstract, to better focus on the relevant use case.
I can take a crack at this.
Ali has text for this, will create a PR for the issue.
Code change:
5.1.3. For media m= sections, JSEP endpoints MUST support both the "UDP/TLS/ <del> RTP/SAVPF" and "TCP/TLS/RTP/SAVPF" profiles and MUST indicate one of </del> <ins> RTP/SAVPF" and "TCP/DTLS/RTP/SAVPF" profiles and MUST indicate one of </ins> these two profiles for each media m= line they produce in an offer. <del> For data m= sections, JSEP endpoints must support both the "UDP/TLS/ SCTP" and "TCP/TLS/SCTP" profiles and MUST indicate one of these two </del> <ins> For data m= sections, JSEP endpoints must support both the "UDP/DTLS/ SCTP" and "TCP/DTLS/SCTP" profiles and MUST indicate one of these two </ins> profiles for each data m= line they produce in an offer.  Because ICE can select either TCP or UDP transport depending on network conditions, both advertisements are consistent with ICE eventually

Related discussion:
text: URL of draft-nandakumar. This is a merge of a previously approved PR
lgtm
LGTM
As per discussion in mmusic, to make it abundantly clear that DTLS is to be used even when running over ICE-TCP, the profile name should be TCP/DTLS/RTP/SAVPF. We'll leave the UDP/TLS/RTP/SAVPF one alone, since that ship has sailed, and it's less ambiguous.
Need Suhas to update URL to reflect the above.
For SCTP, URL has the correct UDP/DTLS/SCTP and TCP/DTLS/SCTP things that we want to refer to.
The action item here is to update this document to use the correct fields as agreed above as if draft-nandakumar was done, and then when that document is fixed we will be good.