jiebi/CodeConvo huggingface dataset:
Change:
defining a common terminology as well as how each metric should be computed for consistent reporting. <del> 4.4.2. </del> <ins> 4.5.2. </ins> Many assumes that the CDNs have a holistic view into the health and performance of the streaming clients.  However, this is not the case.

Discussion:
This is in existing text, but I'd put a paragraph break after "Some receive-side ABR algorithms such as {{ELASTIC}} are designed to try to avoid this effect." and before "Another way to mitigate this effect is by the help of two simultaneous TCP connections, as explained in {{MMSys11}} for Microsoft Smooth Streaming. In some cases, the system-level TCP slow-start restart can also be disabled, for example as described in {{OReilly-HPBN}}."
Works for me. Updated...
The editors are 2:1 in favor of dropping ECN. Spencer is graciously in the rough. We should be talking more broadly about what happens when you lose any packets, If ECN belongs in the draft, it belongs somewhere else. "Coming improvements in transport behaviors" more broadly - we're talking about BBR and about end-to-end transport encryption now. Maybe we should talk about things like edge computing, etc ... but NAME will talk to the working group about this before we start a major refactor.
The point of these sections (4.3.1 Idle Time Between Segments and 4.3.2 Head of Line Blocking) was to explain how and why your bandwidth measurements can go wrong when you're trying to do ABR things with your bandwidth measurements. By name this seems like perhaps a better fit in the 4.4 Measurement Collection section, there might be a reason to merge some of the discussion there or reorganize the 2 sections together.
We maybe should also add a section along these lines on the wide variability in bitrates as things move, both for wi-fi and LTE and 5g. (or paths in general, with those as examples?)
Note also: "Refactor" here means provide a coherent story for why your ABR measurements can go wrong and what you can do about it.
Change:
MessagContext on the messages received (see msg-ctx for further details). <del> "LocalSpecifier.WithSingleSourceMulticastGroupIPv4(GroupAddress, SourceAddress) LocalSpecifier.WithSingleSourceMulticastGroupIPv6(GroupAddress, SourceAddress) LocalSpecifier.WithAnySourceMulticastGroupIPv4(GroupAddress) LocalSpecifier.WithAnySourceMulticastGroupIPv6(GroupAddress) LocalSpecifier.WithPort(PortNumber) LocalSpecifier.WithTTL(TTL) " </del> Calling Rendezvous() on a Preconnection with an any-source multicast group address as the Remote Endpoint will join the multicast group, and also indicates that the resulting connection can be used to send

Discussion:
Review the use of and markdown in the API document, and make it consistent.
A fantastic PR! The best ever!
Change:
In GNAP, the client instance secures its requests to the AS and RS by presenting an access token, presenting proof of a key that it <del> possesses, or both an access token and key proof together. </del> <ins> possesses (aka, a "key proof"), or both an access token and key proof together. </ins> When an access token is used with a key proof, this is a bound token request.  This type of request is used for calls to the RS

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 3ba5ef509380bf20fa220808c57fd1ced5797c5d Inspect the deploy log: Browse the preview:
This term is specific to the protocol, so should probably be defined
Background of picking a new term: The intended goal for the term as currently used is to generically talk about all the different methods of presenting proof of key possession by a client instance. Current methods include signature-based schemes that work on the HTTP message and a TLS-based scheme that relies on the key being the same between layers. These can all be optionally bound to an access token as well, and each "proof method" needs to have a way to include the access token in its coverage.
Renamed the issue for clarity. Please undo if I got it wrong.
Change:
over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. <del> This document updates RFCs 5705 and 6066 and obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations. </del> <ins> This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes RFCs 5077, 5246, 6961, and 8446.  This document also specifies new requirements for TLS 1.2 implementations. </ins> 1.

Discussion:
The paragraph "This document supersedes and obsoletes previous" in the introduction also needs to be updated...
Change:
The next byte contains the length in bytes of the Destination Connection ID (see connection-id) field that follows it.  This length is encoded as an 8-bit unsigned integer.  The Destination Connection <del> ID field follows the DCID Len field and is between 0 and 255 bytes in length. </del> <ins> ID field follows the DCID Length field and is between 0 and 255 bytes in length. </ins> The next byte contains the length in bytes of the Source Connection ID field that follows it.  This length is encoded as a 8-bit unsigned <del> integer.  The Source Connection ID field follows the SCID Len field and is between 0 and 255 bytes in length. </del> <ins> integer.  The Source Connection ID field follows the SCID Length field and is between 0 and 255 bytes in length. </ins> The remainder of the packet contains version-specific content. <del> 4.2. </del> <ins> 5.2. </ins> Short headers take the form described in fig-short.

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.
Change:
This document uses terms and notational conventions from QUIC- TRANSPORT. <del> 3. QUIC is a connection-oriented protocol between two endpoints.  Those endpoints exchange UDP datagrams.  These UDP datagrams contain QUIC packets.  QUIC endpoints use QUIC packets to establish a QUIC connection, which is shared protocol state between those endpoints. </del> 4. Packet diagrams in this document use a format defined in QUIC-

Discussion:
Gorry thought that it might be worth saying what QUIC is first. I agree. Tiny tweaks to the intro to allow for the change. Including a new title.
Issue raised by NAME via :
I like it. I'll see what that looks like. I have read Version-Independent Properties of QUIC (-30) in the WGLC and think this is ready, I found 3 editorial comments that might need consideration after the WGLC: (i) I suggest the introduction for this spec starts abruptly. Is it worth considering one sentence top explain what QUIC is, in case someone read this document first? - One possible solution could be to move the text in section 3 to section 1? (To me, the section 3 text does not need to come after the Section 2 definitions.) (ii) Does this read better with /for/ moved within the sentence? OLD:/At the endpoint, the connection ID is used to identify which QUIC connection the packet is intended for./ NEW:/At the endpoint, the connection ID is used to identify the QUIC connection for which the packet is intended./ (iii) I see the desire to emphasise the “NOT”, but I query if this is correct usage of a RFC2119 keyword in Appendix A?: /The following statements are NOT guaranteed to be true for every QUIC version:/ Best wishes, Gorry
Change:
in table-ecdh-es-table. This document defines these algorithms to be used with the curves <del> P-256, P-384, P-521, X25519 and X448.  Implementations MUST verify that the key type and curve are correct, different curves are restricted to different key types.  Implementations MUST verify that the curve and algorithm are appropriate for the entities involved. </del> <ins> P-256, P-384, P-521.  Implementations MUST verify that the key type and curve are correct, different curves are restricted to different key types.  Implementations MUST verify that the curve and algorithm are appropriate for the entities involved. </ins> 12.5.

Discussion:
The CFRG EC algorithms are currently too far in the future to keep. Remove the ad put in the to be done later document.
Change:
appropriate table when we defined what a 'kty' is so they have had a chance to find out what 'OKP' is.  If we did this we would need to do it for all of the different values that show up here. <del> [CREF3] GS: Include a birthday attack note on tag size? </del>

Discussion:
Started a birthday attack consideration, but it is not valid as far as I can tell so remove it.
Change:
To form a set and a graph, we define an equivalence relation: URIs are only equal to URIs and if they are identical byte-wise.  A blank node is only equal to itself.  A literal is equal to a different <del> literal if its value is equal to another literal's value in the CBOR generic data model, and have the same set of properties. </del> <ins> literal if its value is equal to the other literal's value in the CBOR generic data model. </ins> Triples are equivalent to each other if their subject, predicate and object are pair-wise equivalent.

Discussion:
With direction on its way into a tag (discussion pending -- will it be a dedicated one or inside 38), the only use case we had for properties on literals is gone. I think the whole model is better if we remove them -- anything that can be expressed with properties can also be expressed with tags, but the latter are well defined and understood whereas the former are not. (What does it mean if two properties are on a literal and both are defined but their interaction is not? Tags are clearer there). PR is incomplete, needs a few more alterations.
Change:
result of having their request terminated abruptly, though clients can always discard responses at their discretion for other reasons. If the server sends a partial or complete response but does not abort <del> reading, clients SHOULD continue sending the body of the request and close the stream normally. </del> <ins> reading the request, clients SHOULD continue sending the body of the request and close the stream normally. </ins> 4.1.1.

Discussion:
client stream should be clearly written as client initiated stream the word which pair of send response is receive request, so its better to be does not abort recieving request here for clearify.
First one is good. The second one is intended to align with Section 2.4 of the transport draft, where "abort reading" is a defined operation on a stream; maybe "does not abort reading the request"?
NAME > "does not abort reading the request" SGTM too
Change:
3.1.2. <del> The pledge MUST use an Implicit Trust Anchor database (see EST) to authenticate the cloud registrar service.  The Pledge can be done with pre-loaded trust-anchors that are used to validate the TLS connection.  This can be using a public Web PKI trust anchors using RFC6125 DNS-ID mechanisms, a pinned certification authority, or even a pinned raw public key.  This is a local implementation decision. </del> <ins> The pledge MUST use an Implicit Trust Anchor database (see EST RFC7030) to authenticate the cloud registrar service.  The Pledge can be done with pre-loaded trust-anchors that are used to validate the TLS connection.  This can be using a public Web PKI trust anchors using RFC6125 DNS-ID mechanisms, a pinned certification authority, or even a pinned raw public key.  This is a local implementation decision. </ins> The pledge MUST NOT establish a provisional TLS connection (see BRSKI section 5.1) with the cloud registrar.

Discussion:
[EST] and [RFC7030] are duplicates.
s/are/is/ That sentence is really hard to decode. Please rewrite using more words! Please define VAR. Please define EST. Hard to parse. Maybe you mean "does not discover a local domain registrar or an owner registrar"?
Change:
entries in the "Software ID Link Ownership Values" registry. rel (index 40): An integer or textual value that (integer label <del> with text escape, see data-def, for the "Software ID Link Link </del> <ins> with text escape, see data-def, for the "Software Tag Link </ins> Relationship Values" registry indexed-link-ownership) identifies the relationship between this CoSWID and the target resource identified by the "href" item.  If an integer value is used it

Discussion:
Removed IANA registrations for swid and swidpath and updated text to note these are not technically URIs but just expressions using URI syntax.
Change:
Hop-by-Hop (HBH): Communications between an endpoint and a Media Distribution Device or between Media Distribution Devices. <del> Endpoint: An RTP flow terminating entity that has possession of E2E media encryption keys and terminates E2E encryption.  This may </del> <ins> Trusted Endpoint: An RTP flow terminating entity that has possession of E2E media encryption keys and terminates E2E encryption.  This may </ins> include embedded user conferencing equipment or browsers on computers, media gateways, MCUs, media recording device and more that are in the trusted domain for a given deployment.

Discussion:
Other than revisiting section 3.1.1 and 5.3 after changes to other drafts are complete, these changes either directly, or in-spirit, address all of the feedback/comments.
Just a couple of comments inline.
Change:
The second-to-most significant bit of the first byte in every QUIC packet is defined as having a fixed value in QUIC version 1 QUIC. <del> The purpose of having a fixed value is to allow intermediaries and endpoints to efficiently distinguish between QUIC and other protocols; see DEMUX for a description of a scheme that QUIC can integrate with as a result.  As this bit effectively identifies a packet as QUIC, it is sometimes referred to as the "QUIC Bit". </del> <ins> The purpose of having a fixed value is to allow QUIC to be efficiently distinguished from other protocols; see DEMUX for a description of a system that might use this property.  As this bit can identify a packet as QUIC, it is sometimes referred to as the "QUIC Bit". </ins> Where endpoints and the intermediaries that support them do not depend on the QUIC Bit having a fixed value, sending the same value

Discussion:
This is also fewer words :)
URL there is no definition of what an intermediary stands for here to understand the statement. I think rather defining the "intermediary" we can rephrase to inform the original intention of the fixed bit in QUIC packet i.e. coexistence with protocols in RFC7983. The statement here also gives an impression that any node in the network should be able to efficiently distinguish QUIC packets where in our OPS draft we are saying this is not reliable with a notion of "don't use it". so rephrasing should also help from this point of view. I would propose something like this - The purpose of having a fixed value is to allow coexistance with other protocols in ] . As this bit can be used to identify a packet as QUIC, it is sometimes referred to as the "QUIC Bit".
Change:
5.2. <del> A particular instance of a ratchet tree is based on the following cryptographic primitives, defined by the ciphersuite in use: </del> <ins> A particular instance of a ratchet tree is defined by the same parameters that define an instance of HPKE, namely: </ins> <del> An HPKE ciphersuite, which specifies a Key Encapsulation Mechanism (KEM), an AEAD encryption scheme, and a hash function </del> <ins> A Key Encapsulation Mechanism (KEM), including a "DeriveKeyPair" function that creates a key pair for the KEM from a symmetric secret </ins> <del> A Derive-Key-Pair function that produces an asymmetric key pair for the specified KEM from a symmetric secret </del> <ins> A Key Derivation Function (KDF), including "Extract" and "Expand" functions An AEAD encryption scheme </ins> Each node in a ratchet tree contains up to five values:

Discussion:
In , we changed from using HKDF to using the KDF from HPKE, which I thought removed the need for the ciphersuite to specify a hash function. As a result, ciphersuites no longer needed to specify a hash. However, the transcript computations still have a raw invocation, not a KDF invocation. So we need to either: Change the transcript hash computations to use the KDF, or Clarify that ciphersuites still specify a hash function (as before)
What about the call in the and the "hashes" for ?
Our HPKE dependency provides a perfectly usable KDF. We should just use that instead of nailing a dependency to HKDF. This will mainly be a matter of changing and calls to the corresponding calls on the HPKE KDF.
I can't wait to see the implementations.
Thanks for the enthusiasm, but I don't think this is a spec issue :)
Change:
The structure fields are defined as follows: "token_type" is a 2-octet integer, in network byte order.  This <del> value must match the value in the challenge (challenge). </del> <ins> value must match the value in the challenge (challenge).  This value determines the structure and semantics of the rest of the structure. </ins> "nonce" is a 32-octet message containing a client-generated random nonce.

Discussion:
The token_type field in and determines the remainder of each of these structures. This isn't explicitly stated anywhere, but I think it's an implicit assumption we've all been making.
Change:
4. <ins> 4.1. With typical ICE, endpoints on the same network will usually be able to establish a direct connection between their local IP addresses. When using the mDNS technique, a direct connection is still possible, but only if at least one side can properly resolve the provided mDNS candidates.  This may not be possible in all scenarios. First, some networks may entirely disable mDNS.  Second, mDNS queries have limited scope.  On large networks, this may mean that an mDNS name cannot be resolved if the remote endpoint is too many segments away. When mDNS fails, ICE will attempt to fall back to either NAT hairpin, if supported, or TURN relay, if not.  As noted in IPHandling, this may result in increased media latency and reduced connectivity/ increased cost (depending on whether the application chooses to use TURN). The exact impact of this technique is being researched experimentally and will be provided before publication of this document. 4.2. As noted in {#principle}, ICE agents using the mDNS technique are responsible for registering and resolving mDNS names as part of the ICE process.  These steps may delay establishment of a direct peer- to-peer connection, compared to when raw local IP addresses are used. Given that these mDNS registrations and queries are typically occurring on a local network, any associated delays should be small. Also, as noted in {#gathering}, pre-registration can be employed to eliminate gathering delays entirely. 4.3. Note that backward compatibility does not present a significant issue for the mDNS technique.  When an endpoint that supports mDNS communicates with an endpoint that does not, the legacy endpoint will still provide its local IP addresses, and accordingly a direct connection can still be attempted, even though the legacy endpoint cannot resolve the mDNS names provided by the new endpoint.  In the event the legacy endpoint attempts to resolve mDNS names using Unicast DNS, this may cause ICE to take somewhat longer to fully complete, but should not have any effect on connectivity or connection setup time. 5. </ins> In this example, mDNS candidates are exchanged between peers and resolved to obtain the corresponding IP addresses.

Discussion:
Added new section on latency, as requested by NAME PTAL - will plan to merge at EOD if there are no outstanding comments.
Include experimental results, if we have them
LGTM
Change:
the TCP handshake is complete, or it can wait for the TLS handshake to complete as well.  The benefit of declaring completion when the TCP handshake finishes, and thus stopping the race for other branches <del> of the tree, is that there will be less burden on the network from other connection attempts.  On the other hand, by waiting until the TLS handshake is complete, an implementation avoids the scenario in which a TCP handshake completes quickly, but TLS negotiation is either very slow or fails altogether in particular network conditions or to a particular endpoint.  To avoid the issue of TLS possibly failing, the implementation should not generate a Ready event for the Connection until TLS is established. </del> <ins> of the tree, is reduced burden on the network and remote endpoints from further connection attempts that are likely to be abandoned.  On the other hand, by waiting until the TLS handshake is complete, an implementation avoids the scenario in which a TCP handshake completes quickly, but TLS negotiation is either very slow or fails altogether in particular network conditions or to a particular endpoint.  To avoid the issue of TLS possibly failing, the implementation should not generate a Ready event for the Connection until TLS is established. </ins> If all of the leaf nodes fail to connect during racing, i.e. none of the configurations that satisfy all requirements given in the

Discussion:
These are mostly wording changes for clarification. Feel free to cherry pick.
Can't find any problems here - this looks good.
This LGTM, many thanks!
Change:
We assume that all transport connections are secured via some transport layer security mechanism such as TLS I-D.ietf-tls-tls13. However, as noted above, the security of MLS will generally survive <del> compromise of the transport layer. </del> <ins> compromise of the transport layer, so long as identities provided by the AS are authenticated at a minimum. </ins> 3.2.2.

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.