jiebi/CodeConvo huggingface dataset:
Change:
notified of the status of its data transfer. Event Handling (events) defines categories of notifications that <del> an application can receive during the lifetime of transport objects.  Events also provide opportunities for the application to interact with the underlying transport by querying state or updating maintenance options. </del> <ins> an application can receive during the lifetime of a Connection. Events also provide opportunities for the application to interact with the underlying transport by querying state or updating maintenance options. </ins> Termination (termination) focuses on the methods by which data transmission is stopped, and connection state is torn down.

Discussion:
Responding to review and tighter wording for the Arch draft: Undefined "transport object"
URL Where is this transport object defined?
Change:
IPv4 and IPv6 addresses MUST expose a different mDNS name for each address. <del> Any server-reflexive candidates generated from an mDNS local candidate MUST have their raddr field set to 0.0.0.0 and their rport field set to 0. </del> <ins> Note that any server-reflexive candidates generated from an mDNS host candidate will have IP addresses as their transport addresses, rather than mDNS hostnames.  Because their transport addresses are different (i.e., not hostnames), they MUST NOT be considered redundant with their host counterparts, per the guidance in RFC8445, Section 5.1.3. To avoid accidental leakage, these candidates MUST have their raddr field set to 0.0.0.0 and their rport field set to 0. </ins> Any candidates exposed to the web application via local descriptions MUST be identical to those provided during candidate gathering (i.e.,

Discussion:
RFC 8445 sayeth in S 5.1.3: We should add a note to make it clear that mDNS candidates have distinct transport addresses from their equivalent IPs, and so a srflx candidate created from a public mDNS candidate MUST NOT be discarded as redundant.
Change:
specific usage for each media type is outlined in Sections 4 and 5. <ins> If this m= section is for media with configurable durations of media per packet, e.g., audio, an "a=maxptime" line, indicating the maximum amount of media, specified in milliseconds, that can be encapsulated in each packet, as specified in RFC4566, Section 6.  This value is set to the smallest of the maximum duration values across all the codecs included in the m= section. If this m= section is for video media, and there are known limitations on the size of images which can be decoded, an "a=imageattr" line, as specified in sec.imageattr. </ins> For each supported RTP header extension, an "a=extmap" line, as specified in RFC5285, Section 5.  The list of header extensions that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-

Discussion:
It's a transport attribute, so it should come at the end, like other transport attribs
just checking ... this is just a style thing right? the code would accept SDP with these in any order ?
Of course. This is just how we order things in Section 5.
For createoffer, createanswer ordering of attribs
So SDP has no requirement on the ordering of the a= lines. I don't see how a parser, even a JSEP one can expect to get the a= lines in any specific order. I fear that even a "it is recommended to generate them in this order" will be misinterpreted. I think this is one of SDPs warts that you will have to live with.
Right, there isn't any need to mandate an order, I just think that in the text for generating an offer, the places that talk about adding a=rtpmap should be adjacent. This should be a fairly trivial editorial change.
Change:
encoded in network byte order.  The CID Length field contains the length of the Connection ID field. <del> The maximum number of connection IDs from the peer that an endpoint is willing to store.  This value includes the connection ID received during the handshake, that received in the preferred_address transport parameter, and those received in NEW_CONNECTION_ID frames.  Unless a zero-length connection ID is being used, the value of the active_connection_id_limit parameter MUST be no less than 2.  If this transport parameter is absent, a default of 2 is assumed.  When a zero-length connection ID is being used, the active_connection_id_limit parameter MUST NOT be sent. </del> <ins> The active connection ID limit is an integer value specifying the maximum number of connection IDs from the peer that an endpoint is willing to store.  This value includes the connection ID received during the handshake, that received in the preferred_address transport parameter, and those received in NEW_CONNECTION_ID frames.  Unless a zero-length connection ID is being used, the value of the active_connection_id_limit parameter MUST be no less than 2.  If this transport parameter is absent, a default of 2 is assumed.  When a zero-length connection ID is being used, the active_connection_id_limit parameter MUST NOT be sent. </ins> If present, transport parameters that set initial flow control limits (initial_max_stream_data_bidi_local,

Discussion:
Unlike the other transport parameter definitions, there is no type specified for the parameter. I will assume that the type is an integer (like the other numeric-like transport parameters) and submit a PR to adjust the wording so that it is in line with the other transport parameter descriptions, if that's ok? Thanks for all the great work that you are all doing on getting QUIC specified!
Good catch! Looks like all the other values have a type either implicitly or explicitly stated. is indeed intended to be an integer, a PR to that effect would be great.
Thanks NAME
Change:
external public key In other words, to join a group via an External Commit, a new member <del> needs a GroupInfo with an "ExternalPub" extension present in its </del> <ins> needs a GroupInfo with an "external_pub" extension present in its </ins> "extensions" field. Thus, a member of the group can enable new clients to join by making

Discussion:
For consistency with references to other extensions (and with the IANA registry), refer to the extension as "external_pub".
Change:
leader's, the second share should be for the first helper, and so on). <del> Encrypted input shares are structured as follows: "aggregator_config_id" is equal to "HpkeConfig.id", where "HpkeConfig" is the key config of the aggregator receiving the input share. "enc" is the HPKE encapsulated key, used by the aggregator to decrypt its input share. "payload" is the encrypted input share. </del> To generate the report, the client begins by sharding its measurement into a sequence of input shares as specified by the VDAF in use.  To encrypt an input share, the client first generates an HPKE I-D.irtf- cfrg-hpke context for the aggregator by running <del> where "pk" is the aggregator's public key, "task_id" is "Report.task_id" and "server_role" is a byte whose value is "0x01" if the aggregator is the leader and "0x00" if the aggregator is the helper. "enc" is the HPKE encapsulated key and "context" is the HPKE context used by the client for encryption.  The payload is encrypted as </del> <ins> where "pk" is the aggregator's public key and "server_role" is the Role of the intended recipient ("0x02" for the leader and "0x03" for the helper).  In general, the info string for computing the HPKE context is suffixed by two bytes, the first of which identifies the role of the sender and the second of which identifies the role of the intended recipient. "enc" is the HPKE encapsulated key and "context" is the HPKE context used by the client for encryption.  The payload is encrypted as </ins> where "input_share" is the aggregator's input share and "nonce" and <del> "extensions" are the corresponding fields of "Report". </del> <ins> "extensions" are the corresponding fields of "Report".  Clients MUST NOT use the same "enc" for multiple reports. </ins> The leader responds to well-formed requests to "[leader]/upload" with status 200 and an empty body.  Malformed requests are handled as

Discussion:
When constructing HPKE contexts, we now include both sender and recipient roles, and the application label also includes the PPM version. I used here because we recently submitted draft-01 of and so the next submitted draft, which would include this change, will be . I also backported the definition of struct HpkeCiphertext from the interop PR because it makes everything tidier and should be non-controversial we can get a head-start on bringing those changes into main.
Fixed, thank you! I also rewrote the relevant paragraph to acknowledge that there's two encrypted input shares and that the leader should examine the HPKE config ID of the one intended for itself. Further, I recall NAME pointing out to me that should this draft get adopted by the WG, we'll reset to something like , so is the more appropriate application label.
There's one more instance of that needs to be changed to . Otherwise, LGTM.
Change:
this requires implementations to track which messages appear in which records.  Once all the messages in a flight have been acknowledged, the implementation MUST cancel all retransmissions of that flight. <del> As noted above, the receipt of any packet responding to a given </del> <ins> As noted above, the receipt of any record responding to a given </ins> flight MUST be taken as an implicit acknowledgement for the entire flight.

Discussion:
NAME
I think that the older versions of the spec were good at using the term "datagram" to refer to the thing that holds DTLS records. This version now uses "packet" in a good number of places. Sometimes I think that it means "record", other times "datagram". I'm sure that this is just the influence of QUIC and it can be fixed easily.
Actually 6357 uses "packet" all over the place. I'll do an audit, but I'm not going to ones that mean IP packet.
Change:
to be sent. To avoid sending multiple acknowledgements in rapid succession, an <del> endpoint MAY process all packets in a batch before determining whether a threshold has been met and an acknowledgement is to be sent in response. </del> <ins> endpoint can process all packets in a batch before determining whether to send an ACK frame in response, as stated in Section 13.2.2 of QUIC-TRANSPORT. </ins> 8.

Discussion:
Also moves text about batch processing of packets into an existing section.
Section 7 "Sending Acknowledgments" says: I'm not sure what this means... like sending the same ACK twice in the same QUIC packet? Or generally sending two different ACK frames in the same QUIC packet? Does that really make sense in any case? Can't you always just send the more recent ACK or create one combined ACK frame with all information?
Change:
A client SHOULD NOT reuse a token in different connections.  Reusing a token allows connections to be linked by entities on the network <del> path (see migration-linkability).  A client MUST NOT reuse a token if </del> <ins> path; see migration-linkability.  A client MUST NOT reuse a token if </ins> it believes that its point of network attachment has changed since the token was last used; that is, if there is a change in its local IP address or network interface.  A client needs to start the <del> connection process over if it migrates prior to completing the handshake. </del> <ins> connection process over if there is any change in its local address prior to completing the handshake. Clients might receive multiple tokens on a single connection.  Aside from preventing linkability, any token can be used in any connection attempt.  Servers can send additional tokens to either enable address validation for multiple connection attempts or to replace older tokens that might become invalid.  For a client, this ambiguity means that sending the most recent unused token is most likely to be effective.  Though saving and using older tokens has no negative consequences, clients can regard older tokens as being less likely be useful to the server for address validation. </ins> When a server receives an Initial packet with an address validation token, it MUST attempt to validate the token, unless it has already

Discussion:
This addresses some questions about use of multiple tokens, as well as cleaning up the text adjacent in minor ways.
The spec doesn't define what is a client is supposed to do when it receives multiple NEWTOKEN frames. There seem to be multiple reasonable ways to handle this situation: A client could always use the oldest token first. This would allow the client to establish multiple connections at the same time. A client could replace any old tokens when receiving a new token. This has the advantage that the most recently issued token will (presumably) have the longest life time. Furthermore, if the server encodes connection statistics (RTT, cwnd, etc.) into the ticket, using the newest ticket would provide it with the most recent data. From the Slack discussion, a better way might be a combination of these two: When establishing a new connection, use the most recently obtained token first. When establishing another connection to the same server (before receiving a new NEWTOKEN), use an older token. Client might then want to remember n tokens per endpoint, if they expect to establish n new connections simultaneously (or a few more than n, depending on the network conditions, to account for failed connection establishments).
Your suggestion SGTM.
This is fine, and it merely reflects reality: older tokens are less likely to be useful. But there is no harm in attempting to use any token, provided that it hasn't been used before.
Do we need text about that? NAME do you want me to prepare a PR?
I think that an editorial PR would be great. This is advice that doesn't change interoperability.
Some suggestions, but looks good.
Change:
7.1. <del> The "supported_versions" extension contains a list of MLS versions that are supported by the client.  The "supported_ciphersuites" extension contains a list of MLS ciphersuites that are supported by the client. </del> <ins> The "capabilities" extension indicates what protocol versions, ciphersuites, and protocol extensions are supported by a client. </ins> <del> These extensions MUST be always present in a KeyPackage. </del> <ins> This extension MUST be always present in a KeyPackage.  Extensions that appear in the "extensions" field of a KeyPackage MUST be included in the "extensions" field of the "capabilities" extension. </ins> 7.2.

Discussion:
This PR makes a few minor fixes to extensions: Coalesces and into a single extension Adds a list of supported extensions in parallel with the versions and ciphersuites Adds a missing value to the IANA table for the extension
Change:
When DetNet is used, there is an underlying assumption that the applicaton(s) require clock synchronization such as the Precision <del> Time Protocol (PTP) [IEEE1588].  The relay nodes may or may not utilize clock synchronization in order to provide zero congestion loss and controlled latency delivery.  In either case, there are a few possible approaches of how synchronization protocol packets are </del> <ins> Time Protocol (PTP) IEEE1588.  The relay nodes may or may not utilize clock synchronization in order to provide zero congestion loss and controlled latency delivery.  In either case, there are a few possible approaches of how synchronization protocol packets are </ins> forwarded and handled by the network: PTP packets can be sent either as DetNet flows or as high-priority

Discussion:
Put the text that was taken out of the payload ident section back in. Fixed some compile warnings Two were figs too large One was use of [IEEE1588] instead of Rest were apparently unused references Requesting pull so we are in sync on this.
Looks OK to me. Merging all these chnanes.
Change:
The DER-encoded X.509 end-entity certificate used to sign the DelegatedCredential. <del> The ProtocolVersion in which the delegated credential is to be used, where ProtocolVersion is as defined in the TLS 1.3 standard. The SignatureScheme of Credential.public_key, the signature scheme used by the server to sign the handshake. </del> <ins> DelegatedCredential.cred. </ins> DelegatedCredential.scheme. <del> DelegatedCredential.cred. </del> The signature effectively binds the credential to the parameters of the handshake in which it is used.  In particular, it ensures that credentials are only used with the certificate, protocol, and

Discussion:
Based on There is currently no binding of the credential to the signature scheme used to sign the handshake. The field of the encodes the DC public key type; but there's not a one-to-one correspondence between X.509's and TLS . Hence, the TLS terminator could use a signature scheme to sign the handshake other than the scheme intended by the delegator. To prevent this, this PR adds the SignatureScheme that the TLS terminator selects in the "signature_algorithms" extension to scope of the delegation signature. In addition, it makes this and the protocol version explicit parameters of the Credential structure. This is intended to make debugging easier.
Change:
with the expected ones.  This includes a "RateLimit-Reset" moment too far in the future or a "service-limit" too high. <ins> A client receiving "RateLimit" fields MUST NOT assume that subsequent responses contain the same "RateLimit" fields, or any "RateLimit" fields at all. </ins> Malformed "RateLimit" fields MAY be ignored. A client SHOULD NOT exceed the "quota-units" expressed in "RateLimit-

Discussion:
servers are not forced to always return ratelimit fields clients must not assume the presence of ratelimit fields performance hints for providers
Waiting for NAME then :)
NAME PTAL :)
Looks great to me. The intent is nice and clear.
The spec to define header inter-dependencies and returning policies [x] Limit -> Reset [x] Limit, Remaining, Reset Do I have to always return all headers? No Do I have to expose all headers or I can only expose a subset? Limit,Reset are REQUIRED, Remaining is OPTIONAL Do we need to add some considerations on client implementation? Already present.
clarifies that clients MUST NOT assume a server always returns fields
Comment by Erik. In https://ietf-wg-URL You state ‘A server MAY use one or more "RateLimit" response fields defined in this document to communicate its quota policies.’ but it does not clearly define how they would be used in isolation or how a client should respond to a limited set of headers (other than discussed earlier above) My feeling is RateLimit-Limit can be optional and RateLimit-Remaining and RateLimit-Reset can be used as a pair. RateLimit-Reset would only have value in isolation if sent with a 429 response code, on other responses it would be meaningless.
It could also make sense to return Reset with other status codes such as and , so I think we don't really want to mandate a specific relation other than, at most, saying that unsuccessful requests (for a broad definition of those, possibly including and at a minimum) with this field are expected to be unsuccessful until that time elapses.
After a couple of years of adoption, my experience is the following: implementations use all 3 fields. Though theoretically one could just return and , I never found an implementation doing this :heavycheckmark: implementations don't know Remaining, and just return Limit and Reset with a fixed window (eg. 1 second). We can then recommend the following: Limit, Reset: MUST Remaining: SHOULD Since https://ietf-wg-URL I now think that we shouldn't mess with status codes. NAME if this sounds reasonable to you, I can provide a PR
Yes, it sounds good, thank you!
Looks good!
Change:
Practical considerations, such as packetization, scheduling delays, and computational efficiency, can cause a sender to deviate from this rate over time periods that are much shorter than a round-trip time. <del> Sending multiple packets into the network without any delay between them creates a packet burst that might cause short-term congestion and losses.  Implementations MUST either use pacing or limit such bursts to the initial congestion window; see initial-cwnd. </del> One possible implementation strategy for pacing uses a leaky bucket algorithm, where the capacity of the "bucket" is limited to the

Discussion:
I prefer to have MUSTs towards the top of sections when possible so they're not missed. This is a follow-on from
I'm not a fan of this change -- I think there's value in having that text below where we talk about how bursts can occur. That said, I don't feel strongly about it, so I'm not going to fight for it.
Change:
the client, e.g., a proposal, a commit, or a ratchet tree of the group the client is joining, it is RECOMMENDED that the client verifies that the current time is within the range of <del> the "lifetime" field. </del> <ins> the "lifetime" field.  (This check is not mandatory because the LeafNode might have expired in the time between when the message was sent and when it was received.) </ins> Verify that the extensions in the LeafNode are supported by checking that the ID for each extension in the "extensions" field

Discussion:
URL
:+1: Thank you very much for all of the explicitly worked examples. What is the reason for MUST vs RECOMMENDED difference in the two different circumstances when validating the `lifetime` field? Consider adding a platitude about communicating nodes SHOULD use some method of time synchronization... "top of these basic mechanism" -> "top of these basic mechanisms" (or maybe "top of this basic mechanism") "in an PrivateContentTBE structure" -> "in a PrivateContentTBE structure"
Change:
in CertificateVerify, regardless of whether SHA-1 appears in "signature_algorithms". <del> Note: when used with non-certificate-based handshakes (e.g., PSK), </del> <ins> Note: When used with non-certificate-based handshakes (e.g., PSK), </ins> the client's signature does not cover the server's certificate directly, although it does cover the server's Finished message, which transitively includes the server's certificate when the PSK derives

Discussion:
One more minor fix I just noticed when diffing the latest draft. Just capitalization fixes to match the other notes.
Change:
query, since the status of the challenge will not change until that time. <del> Clients can explicitly request a retry by resending their response to a challenge in a new POST request (with a new nonce, etc.).  This </del> <ins> Clients can explicitly request a retry by re-sending their response to a challenge in a new POST request (with a new nonce, etc.).  This </ins> allows clients to request a retry when the state has changed (e.g., after firewall rules have been updated).  Servers SHOULD retry a request immediately on receiving such a POST request.  In order to

Discussion:
Thanks NAME - diff looks fine to me.Looks fine to mepurely editorial, good for me.