jiebi/CodeConvo huggingface dataset:
Change:
Change end_of_early_data to be a handshake message (*). <ins> Add pre-extract Derive-Secret stages to key schedule (*). </ins> Remove spurious requirement to implement "pre_shared_key". Clarify location of "early_data" from server (it goes in EE, as

Discussion:
benefits: (1) Restoring extract/expand parity, thus cleaning up the theoretical treatment wrt HKDF and future replacements. (2) Futureproofing against someone being able to force the ECDHE value in the second HKDF-Extract to collide with one of the labels. This seems unlikely with current groups, but might be possible with some future algorithm. (Issue due to Trevor Perrin).
This is mostly a cosmetic thing, and I'm not sure if I actually like all of my proposals below: With the current scheme, the key schedule is very simple and neatly encompassed into a box with a shape like this: NewTLS13KeySchedule(hash) => creates a new schedule with base secret = 0 AddEntropy(sched, ikm) => HKDF-Extract ikm into the current base secret DeriveSecret(sched, label) => take the current base secret and handshake transcript and derive a particular secret with the label This breaks the symmetry in a few ways: Incorporating a new IKM requires an extra label for the Derive-Secret operation in the middle. Going from 0 to Early Secret does not involve a Derive-Secret. We use Derive-Secret, Derive-Secret no longer always uses the current state of the handshake transcript (1) could be resolved by just using the same label for both, like "prepare extract" or something. I don't believe this breaks anything? We're just trying to fix the problem where HKDF-Extract and HKDF-Expand can't be used on the same key. (3) is actually kind of odd because Derive-Secret is defined as: Derive-Secret(Secret, Label, Messages) = HKDF-Expand-Label(Secret, Label, Hash(Messages), Hash.Length) So we're actually putting Hash("") into HKDF-Expand-Label, not the empty string. Then again, it feels odd making them ClientHello...ServerHello and ClientHello...Server Finished, respectively. We could use HKDF-Expand-Label directly which still gives us the separation, but it's not as obvious. Adding an extra Derive-Secret just to fix (2) feels a little pointless but would increase symmetry. (Alternatively, the answer could just be "deal with it, your key schedule box should have slightly richer methods on it". Like I said, this is just cosmetic.)

I'm ambivalent on David's gripe. This seems fine to me. One editorial suggestion though. This is now a very tall diagram. You can save a few lines by changing to something like this
About this PR, there is a con: complicating the already complicated key schedule
It does not seem especially complicated compared to, e.g., Kerberos. Or maybe that's just me.
well, you're comparing it to Kerberos :rofl:
NAME I fixed . I think we can live without . We already have this "empty hash" construct for the binder keys, so while it's a bit goofy it's no more goofy than here.
We seem to have reached consensus that the record layer will use the AEAD form only. The stream and CBC forms will be removed.
Fixed.
Change:
2.1.4. <ins> Writing instructions on streams that are limited by flow control can produce deadlocks. A decoder might stop issuing flow control credit on the stream that carries a header block until the necessary updates are received on the encoder stream.  If the granting of flow control credit on the encoder stream (or the connection as a whole) depends on the consumption and release of data on the stream carrying the header block, a deadlock might result. More generally, a stream containing a large instruction can become deadlocked if the decoder withholds flow control credit until the instruction is completely received. To avoid these deadlocks, an encoder SHOULD avoid writing an instruction unless sufficient stream and connection flow control credit is available for the entire instruction. 2.1.5. </ins> The Known Received Count is the total number of dynamic table insertions and duplications acknowledged by the decoder.  The encoder tracks the Known Received Count in order to identify which dynamic

Discussion:
Much belated, this attempts to address the concerns about deadlocking. Basically, this says that you should avoid instructions that don't have flow control credit. It doesn't say how an encoder might learn what limits are, but we've seen a range of tactics being used in implementations and I don't want to get into transport API debates. This doesn't cover the memory exhaustion attack that NAME suggests on the issue; I think that is better covered more generally by the connection-level flow control limits.
I debated adding another paragraph:
Thanks for adding this!
Change:
the SDP is needed, the aforementioned createOffer/createAnswer options or RtpTransceiver APIs MUST be used. <del> Note that the application MAY modify the SDP to reduce the capabilities in the offer it sends to the far side (post- setLocalDescription) or the offer that it installs from the far side (pre-setRemoteDescription), as long as it remains a valid SDP offer and specifies a subset of what was in the original offer.  This is safe because the answer is not permitted to expand capabilities, and therefore will just respond to what is present in the offer. The application SHOULD NOT modify the SDP in the answer it transmits, as the answer contains the negotiated capabilities, and this can cause the two sides to have different ideas about what exactly was negotiated. </del> <ins> After calling setLocalDescription with an offer or answer, the application MAY modify the SDP to reduce its capabilities before sending it to the far side, as long as it follows the rules above that define a valid JSEP offer or answer.  Likewise, an application that has received an offer or answer from a peer MAY modify the received SDP, subject to the same constraints, before calling setRemoteDescription. </ins> As always, the application is solely responsible for what it sends to the other party, and all incoming SDP will be processed by the JSEP

Discussion:
But also clarify that this can be used to modify an offer OR answer, as long as it remains a legal JSEP o/a.
The second paragraph of section 5.4 is confusing. A slight restructuring of the sentences would remove much of the potential confusion, I think. I suggest replacing the first sentence (which is very complex) with this: "After calling setLocalDescription, the application MAY modify the SDP to reduce the capabilities in the offer before sending it to the far side, as long as it remains a valid SDP offer and specifies a subset of what was in the original offer. Likewise, an application that has received an offer from a peer MAY modify the received SDP, subject to those same constraints, before calling setRemoteDescription."
lgtm
Change:
in order are: A text string that identifies the structure that is being encoded. <del> This string is "MAC" for the COSE_Mac struture. </del> <ins> This string is "MAC" for the COSE_Mac structure.  This string is "MAC0" for the COSE_Mac0 structure. </ins> The protected attributes from the COSE_MAC structure.  If there are no protected attributes, a zero length binary string is to be

Discussion:
Everybody but me wants a MAC w/o recipients.
There also needs to be an equivalent no-recipient signature version. Thanks.
That string does not even parse.
Should the kid attribute be a binary value rather than a string value?
No arguments that binary should not be the only type for this, some questions that binary is useful based on Jose experience. Definite arguement that binary is required. Doing two types is probably a bad idea.
Change:
Any, all or none of the below can apply to an application.  Which are relevant depends on its protection objectives. <ins> Security policies are set by configuration of the RD, or by choice of the implementation.  Lookup clients (and, where relevant, endpoints) can only trust an RD to uphold them if it is authenticated, and authorized to serve as an RD according to the application's requirements. </ins> 7.1. Whenever an RD needs to provide trustworthy results to clients doing

Discussion:
…om authorized RDs This makes the paragraph that described that for a particular case largely redundant. The lines about that special case that described special considerations for ACE anticipate a mechanism that is not finished yet, and were removed.
Change:
standardized media-relevant information to the CDNs while they are fetching data.  CTA-5004 was developed exactly for this purpose. <del> 5.7. In contrast to segmented delivery, several applications use unreliable UDP or SCTP with its "partial reliability" extension RFC3758 to deliver Media encapsulated in RTP RFC3550 or raw MPEG Transport Stream ("MPEG-TS")-formatted video MPEG-TS, when the media is being delivered in situations such as broadcast and live streaming, that better tolerate occasional packet loss without retransmission. Under congestion and loss, this approach generally experiences more video artifacts with fewer delay or head-of-line blocking effects. Often one of the key goals is to reduce latency, to better support applications like videoconferencing, or for other live-action video with interactive components, such as some sporting events. The Secure Reliable Transport protocol SRT also uses UDP in an effort to achieve lower latency for streaming media, although it adds reliability at the application layer. Congestion avoidance strategies for deployments using unreliable transport protocols vary widely in practice, ranging from being entirely unresponsive to congestion, to using feedback signaling to change encoder settings (as in RFC5762), to using fewer enhancement layers (as in RFC6190), to using proprietary methods to detect "quality of experience" issues and turn off video in order to allow less bandwidth-intensive media such as audio to be delivered. More details about congestion avoidance strategies used with unreliable transport protocols are included in udp-behavior. </del> 6. Because networking resources are shared between users, a good place

Discussion:
I've edited NAME suggested text a bit, but the proposed structure was WAY more coherent than what I had assembled. Thank you for that!
From NAME Unsure whether this section really belongs to section 5 based on its contents vs. section 5 title. Especially when placed just before section 6, which is about transport protocols.
Hi, NAME I'm actually pretty sure Section 5.7 doesn't below in Section 5. :rofl: I moved the text from Section 5.7 INTO the section on UDP in Section 6, with minimal editing. I need to think about whether I need to do some more editing, but at least it's where it ought to be now.
Change:
from the one used by the server. In addition to the setting above, the server MUST send a <del> SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter indicating the maximum </del> <ins> SETTINGS_WEBTRANSPORT_MAX_SESSIONS parameter indicating the maximum </ins> number of concurrent sessions it is willing to receive.  The default <del> value for the SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter is "0", </del> <ins> value for the SETTINGS_WEBTRANSPORT_MAX_SESSIONS parameter is "0", </ins> meaning that the server is not willing to receive any WebTransport sessions.

Discussion:
Fix up references to setting names
The draft uses both but I presume they refer to the same thing, so lets pick one.
Ah, left over from a previous change, I believe. is the correct form, can update to match.
Yep sgtm
Change:
signaling approaches) or to network controllers (for centralized approaches) <del> Scale to handle a large number of DetNet flows in a domain (which may require per-flow signaling or provisioning) </del> <ins> Scale to handle the number of DetNet flows expected in a domain (which may require per-flow signaling or provisioning) </ins> Provision flow identification information at each of the nodes along the path, and it may differ depending on the location in the

Discussion:
import IP over MPLS scenarios from mpls-dp doc, carify non-DetNet IP
Change:
The CLOSE_DATAGRAM_CONTEXT capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer that it will no longer send or parse received datagrams associated with a given <del> context ID.  Its Capsule Data field consists of: </del> <ins> context ID. </ins> The context ID to close.

Discussion:
The thing that sucks here is that the diagram won't auto expand , so we can't easily ref the section. Manually referring to the section is a maintenance pain. So instead just state the actual type in the text an the diagram. I have a feeling you were linking to the section to avoid the maintenance hassle of updating type codes in multiple place. But I'm quite happy to take that burden because I find it more pleasant to read this way.
Perfectly reasonable
QUIC and HTTP/3 style is to define the general format and then in each instance define the object including all of its fields. This would look like This can later be updated with the actual type value once things settle down
Fine by me.
There's a disparity between the largest flow ID that can be carried in the DATAGRAM frame and the largest that we can express in Datagram-Flow-Id. Draft 00 prevents a flow ID allocation of >= 10^15-1 but doesn't seem to address the case where a DATAGRAM frame contains that value. This is clearly an error, and I'd suggest that it is a connection error; probably or some new codepoint if we really wanted.
I don't think that needs to be an error, we can simply treat this like any other unknown flow ID?
IMO this is clearly a situation that shouldn't happen and indicates the sending endpoint probably has some bug. I'm not sure on what being silent on the matter helps.
This issue is no longer relevant now that we have merged , closing.
Change:
QUIC does not provide a complete version negotiation mechanism but instead only provides a way for the server to indicate that the <del> version the client offered is unacceptable.  This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version.  Optionally, if the original and negotiated version share a compatible first flight format, the negotiation can take place without incurring an extra round trip. </del> <ins> version the client chose is unacceptable.  This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version.  Optionally, if the client's chosen version and the negotiated version share a compatible first flight format, the negotiation can take place without incurring an extra round trip. </ins> 1. The version-invariant properties of QUIC INV define a Version Negotiation packet but do not specify how an endpoint reacts when it receives one.  QUIC version 1 QUIC allows the server to use a Version <del> Negotiation packet to indicate that the version the client offered is </del> <ins> Negotiation packet to indicate that the version the client chose is </ins> unacceptable, but doesn't allow the client to safely make use of that information to create a new connection with a mutually supported version.

Discussion:
Original version was defined as the version a client attempts prior to a VN packet. If there is a VN packet, I think that it is still possible to do a compatible upgrade from the version in the client's second attempt. In that case, "original version" isn't the right term to use when talking about compatible upgrades.
We can sidestep this particular issue by removing the "unless..." clause. That clause isn't helping because the client's chosen version MUST already be present in the compatible versions list. However, this issue raises a good point: it's possible for incompatible VN to happen and then be followed by compatible VN. We should clarify that this is allowed, and clearly define what the "original version" is in that scenario.
Consider the case where the client and server both support v1 and v2 and prefer v2. In the current draft, if the client puts v1 in the long header and the server responds with v2, that's called "compatible version negotiation". OTOH, if the client puts v2 in the long header and the server responds with v2, that's called, well, I'm not quite sure what. I guess not negotiation? I think a better way to think about this is that the client is sending an Initial that is compatible with both versions and so both of these cases are compatible version negotiation.
In the scenario where the client starts with v2 and the server responds with v2, I think of that as just "creating a v2 connection" without compatible version negotiation involved. Let's discuss this with the WG at IETF 113.
Change:
10118-3, ISO-IEC-14888-3, ISO-IEC-15946-1, ISO-IEC-18033-3, IEEE-Std- 1363-2000, IEEE-Std-1363a-2004, NIST-PUB-FIPS-202, NIST-SP800-38C, NIST-SP800-38D, NIST-SP800-38F, NIST-SP800-56A, NIST-SP800-108, bios- <del> log, ima-log, as well as ima and netequip-boot-log exist within the YANG Model. </del> <ins> log, as well as ima and netequip-boot-log exist within the YANG Model. </ins> 2.1.2.1.

Discussion:
NAME I did what I could in the time remaining. Please check and I think there are only two comments left unaddressed.
Change:
bridged networks.  IEEE8021CB defines packet replication and elimination functions for a TSN network. <ins> The implementation of TSN entity (i.e., TSN packet processing functions) MUST be compliant with the relevant IEEE 802.1 standards. </ins> TSN specific functions are executed on the data received by the DetNet Edge Node from the connected CE before forwarded to connected CE(s) or presentation to the DetNet Service Proxy function for

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)
Change:
Claims about the RO as known and declared by the AS. <del> An identifier this client instance instance can use to identify itself when making future requests. </del> <ins> An identifier this client instance can use to identify itself when making future requests. </ins> <del> An identifier this client instance instance can use to identify its current end-user when making future requests. </del> <ins> An identifier this client instance can use to identify its current end-user when making future requests. </ins> An error code indicating that something has gone wrong.

Discussion:
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit fd1d0f88ac7d2a9ad6f43bb6d959a2aa84558f2b https://deploy-preview-179--gnap-core-protocol-editors-URL
One small change needed (marked) but otherwise good!
Change:
RTP RFC3550, which can notice packetloss and repair some limited reordering, <del> SCTP RFC4960, which can use partial reliability RFC3758 to recover </del> <ins> SCTP RFC9260, which can use partial reliability RFC3758 to recover </ins> from some loss, but can abandon recovery to limit head-of-line blocking, and

Discussion:
lgtm
From NAME
Done, except that 4960bis has now popped out as RFC9260. For these next two comments - our responses to reviews from NAME and NAME especially in dropping a lot of the archeology text about TCP, focusing on transport services, and working to make sure we are comparing apples to apples (2022 TCP to 2022 QUIC), have significantly improved the document throughout Section 6. The new discussion of "typically implemented in a kernel, although it doesn't have to be" and "typically implemented in userspace, although it doesn't have to be" is also intended to be more even-handed than the original text. I'm still following up on a couple of things with NAME and NAME but -11 will be significantly better, thanks to the review teams.
Change:
In general we do not consider Denial of Service (DoS) resistance to be the responsibility of the protocol.  However, it should not be <del> possible for anyone to perform a trivial DoS attack from which it is hard to recover. </del> <ins> possible for anyone aside from the DS to perform a trivial DoS attack from which it is hard to recover. </ins> 3.2.2.5.

Discussion:
Remove "join an existing group" from architecture doc, based on UserAdd having been removed from the protocol doc. Remove statement that message delivery cannot be correlated between AS identities and DS delivery channels. This seems generally very difficult to achieve. It may be possible at times, but does not seem to be grounded in discussions that we have had at the working group meetings. Note that federation requires compatible wire encodings. Note that communication with the AS requires TLS or alternative authentication. Note that out-of-band channels may facilitate detection of misbehaviour. Some grammar fixes.
Change:
receiver within the maximum ack delay and are called ack-eliciting packets. <del> Packets that do not increase the largest received packet number for its packet number space by exactly one.  Packets arrive out of order when earlier packets are lost or delayed. </del> 3. All transmissions in QUIC are sent with a packet-level header, which

Discussion:
From recovery to transport.
currently states: NAME notes that nowhere do we define precisely how a receiver might do this detection. Specifically a receiver could implement this as when a newly received packet is smaller than the largest acked, or as when the packet is larger than largest acked plus one. Doing the former would actually not help with loss detection, since the receiver would not ack immediately on a gap. We should add some text codifying the latter.
That section used to be in recovery, where we have a definition already(which is now unused), so I'd suggest we move it over. "Out-of-order Packets: : Packets that do not increase the largest received packet number for its packet number space by exactly one. Packets arrive out of order when earlier packets are lost or delayed."
Isn't this supposed to be "Packets that increase the largest received packet number ... by more than one." in this case?
Thinking about this some more, there are three possible definitions here for out-of-order: a newly received packet is greater than largest received by more than one, a newly received packet is smaller than the largest received, both (1) and (2). (1) is the obvious case where a loss happens and a subsequent packet is received. (2) is the reordering case, where an earlier packet is delivered later, and while it does not indicate loss, it does indicate that a gap was filled. It's useful to signal (2) as well immediately to prevent a sender from unnecessarily retransmitting what it believes to be a missing packet. The definition we want for "out-of-order" is the one that is most useful for determining when to send an immediate ack. The definition in the PR captures both (1) and (2), and is probably the one we want.
NAME : If you believe we ought to change the definition, please re-open, and we can continue this discussion.
Thank you for working on this.