jiebi/CodeConvo huggingface dataset:
Change:
types.  That is, if a handshake message is split over two or more records, there MUST NOT be any other records between them. <del> Handshake messages MUST NOT span key changes.  Because the </del> <ins> Handshake messages MUST NOT span key changes.  Implementations MUST verify that all messages immediately preceding a key change align with a record boundary; if not, then they MUST terminate the connection with an "unexpected_message" alert.  Because the </ins> ClientHello, EndOfEarlyData, ServerHello, Finished, and KeyUpdate <del> messages can arrive immediately prior to a key change, upon receiving these messages a receiver MUST verify that the end of these messages aligns with a record boundary; if not, then it MUST terminate the connection with an "unexpected_message" alert. </del> <ins> messages can immediately precede a key change, implementations MUST send these messages in alignment with a record boundary. </ins> Implementations MUST NOT send zero-length fragments of Handshake types, even if those fragments contain padding.

Discussion:
…appens rather than on receipt of handshake messages. It is only actually necessary to verify that a handshake message aligns with a key change when changing keys, not when receiving the message, and it can be simpler to implement the check in this way. This change requires senders to align all these messages with a record boundary as before, but only requires recipients to verify the record boundary when the key change actually happens.
Change:
negotiated the extension in a previous connection and clear the QUIC Bit based on that information. <ins> An endpoint cannot clear the QUIC Bit without knowing whether the peer supports the extension.  As stateless reset packets (Section 10.3 of QUIC) are only used after a loss of connection state, endpoints are unlikely to be able to clear the QUIC Bit on stateless reset packets. </ins> 3.2. The purpose of this extension is to allow for the use of the QUIC Bit

Discussion:
It seems like the answer to was already in the draft. It just wasn't precise enough to be useful. I also found the wording of the next section awkward, so I'm bundling my changes.
The editorial improvements seem good but I still don't see an answer about the question of stateless reset. For instance, you mention NEW_TOKEN but not .
Oh, I misread. Good thing I didn't mark this as closing . I'll add that.
Would it be correct to say that packets will never be affected by this extension?
Good question. An Initial with a token from (NEW_TOKEN from) a previous connection can clear the bit if the server originally included the transport parameter. If the server puts this information in the token, processes that token, and decides to send a Retry anyway, it might know that the client previously supported the extension. The question is whether we want to allow that. Allowing that means that the client is now constrained (as the server is) to not offer a token if it changes its attitude toward the extension in the interim. Disallowing it means that Retry doesn't get the benefit of greasing. The other way this might happen is if the Retry is sent after processing the contents of the Initial packet. That's much less likely given the way Retry works, but it is at least theoretically possible. I'm leaning toward forbidding the server from exercising the extension unless it reads the client's opinion from the message it receives. We don't add a bunch of constraints on how clients offer tokens or tickets elsewhere in the stack and it would be bad form to start.
Gah, I misread that as Retry. I keep doing that. As for stateless reset, it seems unlikely that a server would be able to generate a truly stateless reset with the QUIC Bit cleared. Except... A server could condition its use of the QUIC Bit extension on support from the client. That is, it only declares support for the extension if the client does the same. In that case, packets it receives with the QUIC Bit cleared would indicate that the client also supports the extension. In that case, the server would be able to clear the QUIC Bit on its own stateless reset packets. Aside from that, it seems like it would be hard to be confident that the cleared bit would be acceptable to a client.

Right, we might expect that a QUIC server that has a good relationship with e.g. a Load Balancer might be able to share some information about itself and behaviours. But that sounds too hard for the minimal gain it would provide here, so I'm pessimistic anyone would bother just for QUIC bit grease. The new text cuts a good balance on speaking to the consideration and allow people to do what they like.
LGTM thanks
Change:
other, and this can result in QOE for users that is significantly lower than what could have been achieved. <ins> One might wonder why media servers and transport protocols are each blissfully ignorant of what the other is doing, and there are multiple reasons for that, but one reason is that media servers may be implemented to run under a general-purpose operating system which typically has its transport protocols implemented in the operating system kernel, making decisions that the media server never knows about. </ins> In one example, if a media server overestimates the available bandwidth to the media player,

Discussion:
Also add Linda to ACKs and add stream: IETF (this is now an XML2RFCv3 thing)
From NAME
responding to the application-level feedback that indicates a bottleneck link somewhere along the path. We agree that "link" is ambiguous. In this section, we're talking about a bottleneck, so we don't need to to say "link", BUT we will clean up other occurrences of "link" in the document - one is actually a URL. implementing some forms of congestion control that probe for bandwidth. The conclusion says that the QoE is poorer when the two methods don't coordinate. Question 2: Both methods are implemented on the Media server, they should coordinate by nature, aren't they? You might think so, but they don't, for various reasons (transport protocols being implemented by OS vendors, and media servers and players are implemented by completely different people. We say that in 3.2, but we describe media servers as "implementing transport protocols". That should have been "rely on". This might change, with transport protocols being implemented in user space and packaged as libraries that are shipped media servers, but that's the case today.
Change:
The order of AggregateContinueResp.prepare_steps MUST match that of the PrepareStep values in "AggregateContinueReq.prepare_steps".  The helper's response to the leader is an HTTP status code 200 OK whose <del> body is the AggregateContinueResp and media type is "message/dap- </del> <ins> body is the AggregateContinueResp and media type is "application/dap- </ins> aggregate-continue-resp".  The helper then awaits the next message from the leader.

Discussion:
In IANA all media types seem to be of "application" type instead of "message" type, this PR is to align the mismatch in the protocol description and adapt to the media types specified in IANA.
Nice catch!
Change:
5. <del> When associated with UDP proxying request streams, the HTTP Datagram Payload field of HTTP Datagrams (see HTTP-DGRAM) has the format </del> <ins> When HTTP Datagrams (see HTTP-DGRAM) are associated with UDP proxying request streams, the HTTP Datagram Payload field has the format </ins> defined in dgram-format.  Note that when HTTP Datagrams are encoded using QUIC DATAGRAM frames, the Context ID field defined below directly follows the Quarter Stream ID field which is at the start of

Discussion:
I had to read the first sentence multiple time to parse it: When associated with UDP proxying request streams, the HTTP Datagram Payload field of HTTP Datagrams (see [HTTP-DGRAM]) has the format defined in [Figure 6]. I think turning the sentence around would make it slightly easier tor read: The HTTP Datagram Payload field of HTTP Datagrams (see [HTTP-DGRAM]) has the format defined in [Figure 6], when associated with streams of UDP proxying requests.
I think I find it easier to read the other way around
Or split the difference
that works too. I also found the term "UDP proxying request streams" a bit clumsy. but the new sentence works much better. Thanks!
Change:
3.3. <del> The "RateLimit-Remaining" field response field indicates the remaining quota units defined in service-limit associated with the client. </del> <ins> The "RateLimit-Remaining" response field indicates the remaining quota units associated to the expiring-limit. </ins> The field is an Item and its value is a non-negative Integer expressed in service-limit.  This specification does not define

Discussion:
clarify that we return only the values related to the quota policy identified by the expiring-limit
If there are multiple policies in effect, which is reflected in these fields? RateLimit-Limit has advice about this, but these do not.
Ok, we should clearly state that all the three basic fields return the values associated to the expiring-limit.
Change:
A response is sent back as defined in RFC7252, as illustrated in fig- untyped2 (derived from RFC7252, Figure 6). <del> 4. </del> <ins> EDITOR: These are "leftover" paragraphs from the original Overview section.  Keeping until I perform a complete editorial pass of the "roughed in" material. Conceptually, the CoAP over TCP/TLS specification replaces most of CoAP's message layer by a new message adapter on top of TCP or TLS that provides a framing mechanism on top of the byte stream provided by TCP/TLS, conveying the length information about each CoAP message that on datagram transports is provided by the datagram layer below (UDP, DTLS). The message adapter also adds a way to use signaling messages to perform various housekeeping operations on the TCP, see [I-D.bormann- core-signaling]. When CoAP is used over TLS then some of the housekeeping features are already available with the TLS Handshake protocol; less new functionality is then required. Modifications to CoAP beyond the replacement of the message layer (e.g., to introduce further optimizations) are intentionally avoided. 2.1. </ins> The CoAP message format defined in RFC7252, as shown in CoAP-Header, relies on the datagram transport (UDP, or DTLS over UDP) for keeping

Discussion:
This is an extremely rough merge of core-coap-tcp-tls and core-coap-websockets. The main intent was to get all the material into one draft with a potential outline and next perform an overall editorial pass.
With the merge of websockets-07, the scope of coap-tcp-tls is extended to include CoAP over WebSockets. The draft title should reflect that change in scope.
I probably would stay explicit (but then I'm biased -- RFC 3095 :-) CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
WFM.
Neglected to close with
Change:
"a=ice-ufrag" and "a=ice-pwd" lines, as specified in RFC5245, Section 15.4. <del> If the "trickle" ICE option is present in the offer, an "a=ice- options" line, with the "trickle" option, as specified in I- D.ietf-mmusic-trickle-ice, Section 4. </del> An "a=fingerprint" line for each of the endpoint's certificates, as specified in RFC4572, Section 5; the digest algorithm used for the fingerprint MUST match that used in the certificate signature.

Discussion:
This contains the ice-options changes as well - will take another look once that PR is merged.
looks like a straightforward change - lgtm
LGTM
JSEP defines this attribute on media level, while 5245 says it is a session level attribute. I understand that there is development ongoing here (e.g. 5245bis), but given that canTrickleIceCandidates is an API on the PeerConnection it makes more sense IMO to have ice-options:trickle on the session level than media line level. If we want this on media line line level, canTrickleIceCandidates should be a (readonly) Transceiver attribute. To that seems messy though, what would happen if Bundle is negotiated but one media line can do trickle but the other not? While the relation between the application of an Answer and canTrickleIceCandidates is spelled out, the same thing should be done for application of an Offer.
Decision on 1): simplest thing here is to move ice-options to session level, right after "An "a=msid-semantic:WMS" line MUST be added..." 2) yes, this should be put into handling a remote description, not handling an answer.
I can take this.
JSEP requires sending q=msid-semantics:WMS: If I read URL correctly, that is no longer defined, so that requirement should probably go. I'm happy to provide a PR that removes the requirement, the example usage and updates the reference, but I assume that updating the reference involves more work than just this, so I'll refrain from doing so unless I hear it would still be useful.
I think we can just remove this line, and scrub it from the examples. More work is probably needed to fix up the refs regarding a=msid, but I think this part should be easy to handle.
Change:
authenticator. An authenticator request message can be constructed by either the <del> client or the server.  This authenticator request uses the CertificateRequest message structure from Section 4.3.2 of TLS13, even if the TLS connection protocol is TLS 1.2.  The CertificateRequest is used to define the parameters in a request for an authenticator.  This message does not include any TLS framing and is not encrypted with a handshake key. </del> <ins> client or the server.  Server-generated authenticator requests use the CertificateRequest message from Section 4.3.2 of TLS13.  Client- generated authenticator requests use a new message, called the ClientCertificateRequest, which uses the same structure as CertificateRequest.  These messages structures are used even if the TLS connection protocol is TLS 1.2. </ins> <del> The uniqueness requirements of the certificate_request_context apply only to CertificateRequest messages that are used as part of authenticator requests.  There is no impact if the value of a certificate_request_context used in an authenticator request matches the value of a certificate_request_context in the handshake or in a post-handshake message.  The structure is defined to be: </del> <ins> The CertificateRequest and ClientCertificateRequest messages are used to define the parameters in a request for an authenticator.  These messages do not include any TLS framing and are not encrypted with a handshake key. The structures are defined to be: </ins> An opaque string which identifies the certificate request and which will be echoed in the authenticator message.  A

Discussion:
A reference QUIC would also need to be added to the references section If it's an informative draft maybe not a thing, but if it's a normative reference then this draft will sit in the queue until QUIC transport gets published. Maybe that's okay, but just an FYI.
I may be missing some follow-on discussions, but: Ben suggested that we mention that QUIC is also an option, even if informatively, in addition to the “SHOULD use TLS” statement. I think we left my question re: back-fitting this protocol into the IANA TLS registry open. Quoting: YS: 7.1: this is changing TLS 1.3 by allowing this extension in Cert Request! I think it's a really bad idea. Better to hack special support to existing libraries, allowing this specific extension for this special case, than to change the base protocol. Otherwise, this document should UPDATE 8446. NS: This is a good point and one that we struggled a bit with during design. We needed to allow SNI in the CertificateRequest message because it can be client-generated in this context. I'd be ok with creating a different extension for this, but it's rather elegant to re-use it in this context. I'd like to hear some opinions from the working group on this point BK: Or, since extension codepoints are cheap, just use a new codepoint.
Addressed by .
Change:
the shared secret derived using ECDH the concatenation of the ASCII-encoded string "WebPush: info", a <del> zero octet, the X9.62 encoding of the User Agent ECDH public key, and X9.62 encoding of the Application Server ECDH public key; that is </del> <ins> zero octet, and the User Agent ECDH public key and the Application Server ECDH public key, both in the uncompressed point form defined in X9.62; that is </ins> 32 octets (i.e., the output is the length of the underlying SHA-256 HMAC function output)

Discussion:
/cc NAME Not sure about "parameter of that same header" phrasing. Not a fan of duplicating the text about the content coding header either. Suggestions?
Yep, these are both correct. Thanks.
Change:
A random value that uniquely identifies the challenge.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters <del> outside the URL-safe Base64 alphabet and MUST NOT contain any padding characters ("="). </del> <ins> outside the base64url alphabet and MUST NOT contain any padding characters ("="). </ins> A client responds to this challenge by constructing a self-signed certificate which the client MUST provision at the domain name

Discussion:
Also fix an example date and fix an RFC reference to not be redundant.
Merging based on manual review, since CircleCI for PRs seems to be busted.
Change:
inferred by the value of "RateLimit-Reset" at the moment of the reset, or <del> communicated out-of-band (eg. in the documentation). </del> <ins> communicated out-of-band (e.g. in the documentation). </ins> Policies using multiple quota limits MAY be returned using multiple "quota-policy" items, like shown in the following two examples:

Discussion:
Fix typos
I'm really sorry for the poor Camilleri :) Wu Ming's "Q" is really worth reading though URL(novel)
What, no Eco? :)
No warnings
There are six lines that are marked as too long.: It might make sense to break these into two lines: and add text saying "Shown on two lines for clarity" or something.
3 fixed ;)
NAME Can this be closed now?
Looks good - thanks for the literary recommendations; I already followed inspector Montalbano's deeds, but Q looks an interesting addition... if/whenever my son gives me some time to read! :smile:
Change:
10.3. <ins> During the lifetime of a connection there are events that can occur when configured. 10.3.1. </ins> Asynchronous introspection is also possible, via the SoftError Event. This event informs the application about the receipt of an ICMP error message related to the Connection.  This will only happen if the

Discussion:
Btw. does this cover all events? There is an issue where I also ask if we e.g. need an event that sending failed due to lifetime expiry. is there a way to double-check if we considered all needed events? Should we also mention ConnectionErrors here? Maybe we anyway need to say more about error?
These are not all events (just search for the word "event" in the document), and generally they are not all lumped together - e.g. sending related events such as "Sent" appear in the "Sending Data" section - which, in fact, has its own subsection called "Send Events". So, this would be a subsection just related to connection management... but then, you state: "During the lifetime of a connection there are events that can occur when configured." which gives the (wrong) impression that this would be the list of all events that can happen during a connection's lifetime. So, I wouldn't add this subsection heading and not include that statement. Or maybe add the subsection heading (which is ok but doesn't help much - as you see, there are only very few events in there), but remove that statement.
+1 to calling this "connection lifecycle events" or similar (do we refer to a connection lifecycle?)
Changed the heading and fixed the nit. I'm open to have another sentence there if people have proposals. We could even have no text but we usually say something after each heading.
Given the new heading, I'm fine with the sentence as it is - because the context is clear now, it's no longer misleading (i.e., giving the wrong impression that these would be ALL events).
Change:
"[leader]" is the leader's endpoint URL.  The payload is structured as follows: <del> We sometimes refer to this message as the _report_. The message contains the "task_id" of the previous request.  It also includes the time at which the report was generated.  This field is present to ensure that each report is included in at most one batch.  The rest of the message consists of the encrypted input shares, each of which has the following structure: </del> <ins> This message is called the client's _report_. It contains the following fields: "task_id" is the task ID of the task for which the report is intended. "time" is the time at which the report was generated.  This field is used by the aggregators to ensure the report appears in at most one batch.  (See anti-replay.) "jitter" is a random number chosen by the client generating the report.  This and the timestamp field are used by the aggregators to ensure that each report appears at most once in a batch.  (See anti-replay.) "encrypted_input_shares" contains the encrypted input shares of each of the aggregators. Encrypted input shares are structured as follows: </ins> "config_id" is equal to "HpkeConfig.id", where "HpkeConfig" is the aggregator's key config.

Discussion:
For privacy reasons, leaders should not be allowed to replay a given report more than once within the context of a single batch. The current verify+collect model runs in a "streaming mode," wherein the leader sends slices of batch shares to helpers for verification and aggregation. If we changed this to require the leader to send all batch shares in a single verify+collect flow, then replay prevention would be simpler: just scan the list and check for dupes. If we stick with the current model, then the helper must necessarily store some state (on the leader, most likely) representing the shares processed. This state could then be consulted when asked to verify+collect any new share. (We can probably spell out a number of ways to do store this state, but ideally it should not be linear in the number of shares collected so far.) We'd likely also need a way for the leader to request that the helper produce the final aggregate output once the batch is "done" being verified and collected.
One downside to this approach is that it requires the leader to queue up the entire batch of reports before sending the first aggregate request to the helper. This may be OK for some deployments, but it might not be workable for all. I think this is worth pursuing. This is already in the protocol. (See "output share request".)
We could require that the leader feed the helper reports with monotonically increasing timestamps, such that the helper can simply maintain a single timestamp and reject any report older than that. However I'm not sure if that's practical given that clients may submit reports out of order.
One intermediate option would be to maintain a jitter buffer on the leader, so that they keep reports for a few minutes and then feed them out in order. You would still lose some reports, but not too many.
I have a few questions but nothing blocking.
Change:
material and the Attesting Environment with equivalent strength protections. <ins> As illustrated in I-D.birkholz-rats-uccs, an entity that receives unprotected Evidence via a trusted conveyance channel always takes on the responsibility of vouching for the Evidence's authenticity and freshness.  If protected Evidence is generated, the Attester's Attesting Environments take on that responsibility.  In cases where unprotected Evidence is processed by a Verifier, Relying Parties have to trust that the Verifier is capable of handling Evidence in a manner that preserves the Evidence's authenticity and freshness. Generating and conveying unprotected Evidence always creates significant risk and the benefits of that approach have to be carefully weighed against potential drawbacks. </ins> See security-considerations for discussion on security strength. 7.5.

Discussion:
Maybe a sentence to tie unprotected Evidence to the "concept of trust" in the Verifier section of the Trust Model super-rsection might be useful in order to illustrate to the reader why that is covered there? At the moment it talks about "secure channels" and the ties to trust are mainly implied?