jiebi/CodeConvo huggingface dataset:
Change:
entertainment applications as people watched videos or played games. <del> At the IXP-level, it was observed that port utilization increased. This phenomenon could probably be explained by a higher level of uncacheable traffic such as videoconferencing and VPNs from residential users as they stopped commuting and switched to work- at-home. </del> <ins> At the IXP level, it was observed that physical link utilization increased.  This phenomenon could probably be explained by a higher level of uncacheable traffic such as videoconferencing and VPNs from residential users as they stopped commuting and switched to work-at-home. </ins> 4.

Discussion:
LGTM - and my comment is the same length as the change itself, so I'm merging now ...
Change:
to prevent these IP addresses from being exposed to web applications through other means. <del> 5.1. </del> <ins> 6.1. </ins> Statistics related to ICE candidates that are accessible to the web application MUST NOT contain the IP address of a local or remote mDNS

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:
5.3.1. <del> The server ID length MUST be no more than 12 octets.  The server ID length and nonce length MUST sum to exactly 16 octets. </del> <ins> The server ID length MUST be no more than 12 octets.  The nonce and server ID MUST sum to at least 16 octets. </ins> The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption.

Discussion:
the server no longer has discretion to lengthen the CID. Also, the algorithms are more aligned so there has to be less unique text associated with each algorithm.
In any given deployment, the server use length should be consistent. The load balancer doesn't strictly need to know what it is, but obviously not doing this will lead to observable correlations.
As we've generalized the concept of a nonce, we should abolish the concept of "server use" and make it all a nonce. If the servers need to use the same length to prevent linkability, best to make it part of the configuration.
Change:
Endpoint to the Remote Endpoint.  This corresponds to a TCP simultaneous open, for example. <del> The Rendezvous() Action consumes the Preconnection.  Once Rendezvous() has been called, no further properties may be added to the Preconnection, and no subsequent establishment call may be made on the Preconnection. </del> <ins> The Rendezvous() Action returns a Connection object.  Once Rendezvous() has been called, any changes to the Preconnection MUST NOT have any effect on the Connection.  However, the Preconnection can be reused, e.g., for Rendezvous of another Connection. </ins> The RendezvousDone<> Event occurs when a Connection is established with the Remote Endpoint.  For Connection-oriented transports, this

Discussion:
Fixed text in the API draft to allow reusing Preconnections as discussed in . However, changes to the Preconnection MUST NOT have any effect on the Connections or Listeners created beforehand - I think normative language is useful here to really highlight this possible pitfall. I omitted any note on deep copy as that's just a way to implement this.
Great catch, it makes me wonder why we had closed issue ? Thanks for doing this!Thank you - fix achieved with minimal changes ;-)
Change:
_RFC Editor: Please fill in this value with the RFC number for this document_ <del> 6.3. </del> <ins> 7.3. </ins> The following entries are added to the "HTTP/2 Error Code" registry that was established by Section 11.2 of RFC7540.

Discussion:
Add brief section describing Http2Transport's stance on the properties enumerated in the WebTransport Overview. We can move this around later as necessary, but wanted to get the text in to document which optional properties are supported and which are not.
From the : We should enumerate the position that Http2Transport takes on each of these items. Specifically: No stream independenceNo partial reliabilityYes pooling supportNo connection mobility
Change:
(ABORT.UDP(-Lite)) is identical to calling "Close" on this Connection and on all Connections in the same ConnectionGroup. <del> 10.5. </del> <ins> 10.6. </ins> Connectedness: Connected

Discussion:
(More out of curiosity, with no expectation that this would find its way into the text unless you think I've hit a bug): In UDP Multicast Receive, which kind of ICMP notifications can come in there that would constitute a ConnectionError -- given that this transport does not send (and would thus usually not trigger any)?
Section 10.4 for multicast receive mentions ICMP errors. You could have errors on initiate for joining a multicast group, etc, but it likely doesn't make sense to have ICMP errors mentioned here.
Suggest we can close this issue.
LGTMSeems like we do not loose anything by removing this. The change WFM.
Change:
4.2. <del> This key is used to indicate the target port for connection ((SVCB Section 6.2)).  If omitted, the client SHALL use the default port for each transport protocol (853 for DNS over TLS DOT, 443 for DNS over HTTPS). </del> <ins> This key is used to indicate the target port for connection ((Section 6.2 of SVCB)).  If omitted, the client SHALL use the default port for each transport protocol (853 for DNS over TLS DOT, 443 for DNS over HTTPS). </ins> This key is automatically mandatory if present.  (See Section 7 of SVCB for the definition of "automatically mandatory".)

Discussion:
The lack of quoting in some of the examples might make it harder to see what constitutes example and what is punctuation. Highlighting and fonts in the HTML rendering are subtle and not present in text renderings (any more). I've also changed some section references. I'm happy to split that off into a different change or use the form if you prefer that.
Change:
case where state is lost, so this approach is suboptimal. A single static key can be used across all connections to the same <del> endpoint by generating the proof using a second iteration of a preimage-resistant function that takes a static key and the connection ID chosen by the endpoint (see connection-id) as input. An endpoint could use HMAC RFC2104 (for example, HMAC(static_key, connection_id)) or HKDF RFC5869 (for example, using the static key as input keying material, with the connection ID as salt).  The output of this function is truncated to 16 bytes to produce the Stateless Reset Token for that connection. </del> <ins> endpoint by generating the proof using a pseudorandom function that takes a static key and the connection ID chosen by the endpoint (see connection-id) as input.  An endpoint could use HMAC RFC2104 (for example, HMAC(static_key, connection_id)) or HKDF RFC5869 (for example, using the static key as input keying material, with the connection ID as salt).  The output of this function is truncated to 16 bytes to produce the Stateless Reset Token for that connection. </ins> An endpoint that loses state can use the same method to generate a valid Stateless Reset Token.  The connection ID comes from the packet

Discussion:
The second iteration piece is cruft and confusing.
NAME said:
I think that's an oops. I'll cut that. It's just the PRF part we need.
Change:
skip a packet number to eliminate the ack delay. When the PTO timer expires, and there is new or previously sent <del> unacknowledged data, it MUST be sent. </del> <ins> unacknowledged data, it MUST be sent.  A probe packet SHOULD carry new data when possible.  A probe packet MAY carry retransmitted unacknowledged data when new data is unavailable, when flow control does not permit new data to be sent, or to opportunistically reduce loss recovery delay.  Implementations MAY use alternative strategies for determining the content of probe packets, including sending new or retransmitted data based on the application's priorities. </ins> It is possible the sender has no new or previously-sent data to send. As an example, consider the following sequence of events: new

Discussion:
When writing , I found some of the text organization to be odd, so this moves it some.
Change:
dependent on interactions between the congestion controllers in use for TCP-based HTTP traffic and UDP-based HTTP/3 traffic. <del> More broadly, I-D.ietf-quic-manageability discusses manageability of the QUIC transport protocol, focusing on the implications of QUIC's design and wire image on network operations involving QUIC traffic. It discusses what network operators can consider in some detail. </del> 7. "Encrypted Media" has at least three meanings:

Discussion:
From NAME Authors may also want to refer to drafts about the same considerations (i.e., end-to-end crypto hindering operations).
Agree, will reference (was draft-ietf-tsvwg-transport-encrypt) Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols
Change:
3. <ins> The authenticator request is a structured message that can be exported from either party of a TLS connection.  It can be transmitted to the other party of the TLS connection at the application layer.  The application layer protocol used to send the authenticator SHOULD use TLS as its underlying transport. An authenticator request message can be constructed by either the client or the server.  This authenticator uses the CertificateRequest message structure from Section 4.3.2 of TLS13.  This message is not encrypted with a handshake key, which differs from how this message is used in TLS 1.3. This message is used to define the parameters in a request for an authenticator. An opaque string which identifies the certificate request and which will be echoed in the authenticator message.  The certificate_request_context MUST be unique within the scope of this connection (thus preventing replay of authenticators).  The certificate_request_context SHOULD be chosen to be unpredictable to the peer (e.g., by randomly generating it) in order to prevent an attacker who has temporary access to the peer's private key from pre-computing valid authenticators. The extensions that are allowed in this structure include the extensions defined for CertificateRequest messages defined in Section 4.2. of TLS13 and the server_name RFC6066 extension, which is allowed for client-generated authenticator requests. 4. </ins> The authenticator is a structured message that can be exported from either party of a TLS connection.  It can be transmitted to the other party of the TLS connection at the application layer.  The

Discussion:
Add new "authenticator request" message Make Certificate selection more explicit (including extensions) Update API considerations accordingly
I update the draft in response to the comments.
Two small comments: Can you add text explaining why authenticator requests are not encrypted with handshake keys? (Are they encrypted at all?) It might help to include a sequence diagram or two showing intended uses of exported authenticators, e.g., for Mike's draft, and where requests fit into TLS connections.
NAME I'm not sure what purpose encrypting them would serve. The draft does say that "The application layer protocol used to send the authenticator SHOULD use TLS as its underlying transport." In other words, the messages have integrity built-in and any desire for confidentiality is the app's to solve.
NAME I was referring to the following sentence: "This message is not encrypted with a handshake key, which differs from how this message is used in TLS 1.3." Perhaps you could add text explaining why this choice was made?
By the time you use this, handshake keys might be long gone. I think that we could avoid this confusion by stating that this is only the handshake messages and not records that form the authenticator. And maybe add that because there are no records, there is no record protection.
Change:
When issuing Retry or NEW_TOKEN tokens, the server MUST include the client IP address in the authenticated data as specified in token- <del> protection-with-aead.  It MUST include a means of distinguishing service-generated Retry tokens, server-generated Retry tokens (if different), and NEW_TOKEN tokens. </del> <ins> protection-with-aead.  The ODCIL and RSCIL fields are zero for NEW_TOKEN tokens, making them easily distinguishable from Retry tokens. </ins> The server MUST validate all tokens that arrive in Initial packets, as they may have bypassed the Retry service.

Discussion:
and
Thanks Christian, Your comments ended up as an editorial rewrite of the section, with port verification added.
The diagrams indicate they are in the range 0..160. This is incorrect.
SS Tokens can have this, because they could be NEW_TOKEN tokens. But the shared state format is limited to 64.
Fixed by
A few more issues with Retry tokens: For Retry, we're supposed to check the client port. Because this isn't true for NEW_TOKEN, we probably can't put it in the shared-state pseudoheader. Relatedly, we currently just say that the shared-state Retry Service has to be behind any NAT. This isn't enough. For non-shared-state, we're probably fine. For a Retry, the NAT will keep the 4-tuple binding so that on either side there is something to validate. For shared-state: if the service is in front of the NAT, the server can't validate the address. if the service is behind the NAT, it'll "work" but to add any value at all there really has to be a port in there somewhere. We can probably assume that the alternate path that creates the need for shared state won't cause a service-generated token to suddenly appear on the unprotected path.
Fixed by
We should tighten up the rules for Resumption Token processing by the Retry Service. When active, it should reject the packet, but it should send Retry. I believe we can distinguish resumption from Retry because the CID length fields are zero; as any Retry token must have a ODCIDL of at least 8, this would appear to be robust. On a related note, the requirement on servers to encode a way to distinguish the two token types is silly, because of this propery.
Fixed by
Currently the Initial Packet number MAY be encoded in the Retry Token. We must either: Include language that a server MUST NOT reject a token because this information is not present; OR Just make it part of the format. (IMO this would be bad, because then the Retry service would have to decrypt the packet number)
Most changes appear editorial, except for the addition of the port number field. If you add that port, you need to also specify how it should be processed!
Change:
server, can cause a situation in which the server cannot send when the client has no data to send and the anti-amplification limit is reached.  In order to avoid this causing a handshake deadlock, <del> clients SHOULD send a packet upon a handshake timeout, as described in QUIC-RECOVERY.  If the client has no data to retransmit and does not have Handshake keys, it SHOULD send an Initial packet in a UDP datagram of at least 1200 bytes.  If the client has Handshake keys, it SHOULD send a Handshake packet. </del> <ins> clients SHOULD send a packet upon a crypto retransmission timeout, as described in QUIC-RECOVERY.  If the client has no data to retransmit and does not have Handshake keys, it SHOULD send an Initial packet in a UDP datagram of at least 1200 bytes.  If the client has Handshake keys, it SHOULD send a Handshake packet. </ins> A server might wish to validate the client address before starting the cryptographic handshake.  QUIC uses a token in the Initial packet

Discussion:
Although not super-important, the biggest decision in here is that the packet number of the response to a RETRY is 1. Based on interop experience, I believe this is the semi-consensus of implementers.
Should there be normative text mandating that the packet number be increased?
I think we need a new issue on that. The information about this is scattered around issuing CID's, path validation, retransmission of Initial. It would be good with a clear statement of when the packet number starts counting. I also believe that there is somewhere text to the effect that a CID cannot have the same PN twice, but that does not apply to Retry.
Change:
fragments of Application data MAY be sent as they are potentially useful as a traffic analysis countermeasure. <ins> When record protection has not yet been engaged, TLSPlaintext structures are written directly onto the wire.  Once record protection has started, TLSPlaintext records are protected and sent as described in the following section. </ins> 5.2.2. The record protection functions translate a TLSPlaintext structure

Discussion:
LGTM
This was always a hack. We should just remove mention of this as a "cipher suite" and just talk about certain messages being encrypted and others not.
If issue is done, then I think the only cleartext messages left would be the 3 hello messages: ClientHello, ServerHello, & HelloRetryRequest. TLSPlaintext could then just be renamed to TLSHelloRecord, which would make the distinction between cleartext and encrypted records relatively easy.
I agree that this psuedo-cipher-suite should be removed. It is confusing. Some implementations may work in a way where they implement some TLSNULLNULLWITHNULL_... cipher suite, but that's an implementation detail. Other implementations, particularly implementations that don't do renegotiation, likely won't work like that.
Change:
4.2.6. The PUSH_PROMISE frame (type=0x05) is used to carry a promised <del> request header set from server to client, as in HTTP/2. </del> <ins> request header set from server to client on a request stream, as in HTTP/2. </ins> The payload consists of:

Discussion:
All other frame types in section 4 explicitly call out which stream types are allowed. For example DATA: If a DATA frame is received on either control stream, the recipient MUST respond with a connection error (Section 8) of type HTTPWRONGSTREAM.
FWIW this is explained in section 5. But I agree that conistency in the frame descriptions could help.
Change:
Starting a connection up quickly without inducing excess queue is important for latency reduction, for both short and long flows. <del> The sender often needs frequent acknowledgments during this phase; see slow start and hystart. </del> <ins> The sender often needs more frequent acknowledgments during this phase. </ins> Congestion controllers that are purely window based and strictly adherent to packet conservation, such as the one defined in QUIC-

Discussion:
by removing references to slow start, hystart, and paced chirping. Slow start and BBR startup aren't quite the same as NAME mentioned, hystart isn't specified for QUIC, and paced chirping is not an IETF draft to my knowledge.
"Starting a connection up quickly without inducing much queue is important for latency reduction, for both short and long flows. The sender often needs frequent acknowledgments during this phase; see slow start and hystart." There's no description of them in this doc. Slow start is in the recovery draft, but hystart is not, so we'd have to reference a non-QUIC RFC?
Maybe paced chirping too.
An added nit to this: congestion controllers like BBR do not have a slow start / hystart phase exactly, but are still sensitive to ACKs early in the flow during "Startup". With a BBR congestion controller the ACKing interval early in the flow has a measurable effect on the time it takes to find the bottleneck bandwidth. More generally I suspect this is true of pretty much every congestion controller that's trying to find an optimal congestion window. Given that, perhaps we need more general language here about the benefit of ACKs early in a flow, and then referencing slow start and hystart specifically?
BBR has 'Startup', which is quite similar to slow start, so maybe flow startup a better general purpose term? I think we can remove the reference to hystart entirely, since I wouldn't expect decreasing ACK frequency to have a negative impact on it, particularly given QUIC's explicit ack delay.
Change:
Listen: Enables a listener to accept incoming Connections.  The Listener will then create Connection objects as incoming connections are accepted (events).  Listeners by default register <del> with multiple paths, protocols, and local endpoints, unless </del> <ins> with multiple paths, protocols, and Local Endpoints, unless </ins> constrained by Selection Properties and/or the specified Local Endpoint(s).  Connections can be accepted on any of the available paths or endpoints.

Discussion:
NiT
Part of Issue
Merged
The use of “remote” on its own offends me: “Some types of remote might …” could we make this “Remote Endpoint” to ease my reading? or whatever else is intended? Similarly can we change “locals” and “remote” here to something that is defined: “This can expose some or all of the candidate locals to the remote”
Remote Endpoint
Change:
5.1.5. <del> When an endpoint has provided its identity assertion in a previous successful offer/answer exchange, and when the endpoint later in the session sends an offer or answer, the endpoint can either keep the identity assertion value unchanged, modify the value, or revoke the identity assertion.  This section describes the procedures for doing so. </del> <ins> When modifying a session, if the set of fingerprints is unchanged, then the sender MAY send the same 'identity' attribute.  In this case, the established identity SHOULD be applied to existing DTLS connections as well as new connections established using one of those fingerprints.  Note that I-D.ietf-rtcweb-jsep, Section 5.2.1 requires that each media section use the same set of fingerprints for every media section. </ins> <del> If the endpoint wants to maintain the previously provided identity assertion, it MUST include an 'identity' attribute with the previously provided attribute value in the offer or answer. If the endpoint wants to modify its identity assertion within the session, it MUST include an 'identity' attribute value with the new identity assertion in the offer or answer. If the endpoint maintains or modifies its identity assertion within the session, it includes one or more SDP 'fingerprint' attributes. The set of fingerprints MUST be the same as the set to which the identity assertion is bound. If the endpoint wants to revoke its identity assertion from the session, it MUST NOT include an 'identity' attribute in the offer or answer. Specific usages might restrict the modification and/or revoking of the identity assertion within a session.  Endpoints can add, modify, or remove 'fingerprint' attributes when modifying a session.  If a modified session retains the 'identity' attribute, there MUST be at least one 'fingerprint' attribute included. </del> <ins> If the set of fingerprints changes, then the sender MUST either send a new 'identity' attribute or none at all.  Because a change in fingerprints also causes a new DTLS connection to be established, the receiver MUST discard all previously established identities. </ins> 6.

Discussion:
NAME I looked at the deletion issue and I don't think it's worth leaving it in as an exception, because you'd have to DTLS re-handshake anyway.
Change:
existing OSCORE Security Context, it MUST include in its POST request to the token endpoint a req_cnf object.  The req_cnf MUST include a kid field carrying a bstr-wrapped CBOR array object containing the <del> client's identifier (assigned as discussed in as-c) and optionally the context identifier (if assigned as discussed in as-c).  The CBOR array is defined in kid, and follows the notation of RFC8610.  These </del> <ins> client's identifier (assigned as discussed in as-c) and the context identifier (if assigned as discussed in as-c).  The CBOR array is defined in kid, and follows the notation of RFC8610.  These </ins> identifiers, together with other information such as audience, can be used by the AS to determine the shared secret bound to the proof-of- possession token and therefore MUST identify a symmetric key that was

Discussion:
Not much here, though a couple points I'll leave some further comments on, as the proper disposition is not entirely clear.
If you agree NAME I would go ahead and merge this PR (excluding the "update of access rights" change at l.776).
Sorry, I missed this when it came in. Please go ahead.