jiebi/CodeConvo huggingface dataset:
Code change:
Each endpoint advertises its own idle timeout to its peer.  An endpoint restarts any timer it maintains when a packet from its peer is received and processed successfully.  The timer is also restarted <del> when sending a packet containing frames other than ACK or PADDING (an ack-eliciting packet; see QUIC-RECOVERY), but only if no other ack- eliciting packets have been sent since last receiving a packet. Restarting when sending packets ensures that connections do not prematurely time out when initiating new activity. </del> <ins> when sending an ack-eliciting packet (see QUIC-RECOVERY), but only if no other ack-eliciting packets have been sent since last receiving a packet.  Restarting when sending packets ensures that connections do not prematurely time out when initiating new activity. </ins> The value for an idle timeout can be asymmetric.  The value advertised by an endpoint is only used to determine whether the

Related discussion:
text: At the moment, we state that a QUIC packet that contains frames other than ACK and PADDING (), but I wonder if that is true for CONNECTIONCLOSE frame. A CONNECTIONCLOSE frame never elicits an acknowledgment. IIUC, it is not meant to be governed by the congestion controller. Considering the aspects, I think we should add CONNECTION_CLOSE to the list of non-ACK-eliciting frames.
That also ensures the congestion controller never inadvertently blocks sending a CONNECTIONCLOSE, which is consistent with the intent. If we make this change, I believe APPLICATIONCLOSE needs to be on the list as well. Now that we discuss ack-eliciting in transport, I think we'd need to change both transport and recovery and mark this design. So I think this would be a slight improvement, but I an also imagine people claiming that CONNECITON_CLOSE is already special, so there's no need for a change.
APPLICATION_CLOSE is no more. This seems like a fine change.
This seems sensible.
Discussed in Cupertino. Obvious correction.
Seems right to me. Editorial tweaks suggested.
Code change:
migrates away from a local address SHOULD retire all connection IDs used on that address once it no longer plans to use that address. <del> An endpoint can request that its peer retire connection IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To field.  Upon receipt, the peer SHOULD retire the corresponding connection IDs and send the corresponding RETIRE_CONNECTION_ID frames in a timely manner.  Failing to do so can cause packets to be delayed, lost, or cause the original endpoint to send a stateless reset in response to a connection ID it can no longer route </del> <ins> An endpoint can cause its peer to retire connection IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To field. Upon receipt, the peer MUST retire the corresponding connection IDs and send corresponding RETIRE_CONNECTION_ID frames.  Failing to retire the connection IDs within approximately one PTO can cause packets to be delayed, lost, or cause the original endpoint to send a stateless reset in response to a connection ID it can no longer route </ins> correctly. An endpoint MAY discard a connection ID for which retirement has been requested once an interval of no less than 3 PTO has elapsed since an acknowledgement is received for the NEW_CONNECTION_ID frame <del> requesting that retirement.  Subsequent incoming packets using that </del> <ins> requesting that retirement.  Until then, the endpoint SHOULD be prepared to receive packets that contain the connection ID that it has requested be retired.  Subsequent incoming packets using that </ins> connection ID could elicit a response with the corresponding stateless reset token.

Related discussion:
text: NAME the delayed packets are handled by this text: If you've followed the requirement to retire as indicated, then a delayed packet triggering stateless reset can't hurt you.Looks fine to me. I'm also fine with Martin's suggestions as well.The endpoint here has always been going to do whatever it does, regardless of whether we said SHOULD or MUST, so this seems fine. I do like the direction for the other endpoint to wait 3PTO, that would be nice to include.
Code change:
5.1. <del> TODO - Add example with string, data, boolean, and base value </del> 5.1.1. The following shows a temperature reading taken approximately "now"

Related discussion:
text: Fixes URL
This makes some of the examples very long. I preferred the presentation where all attributes of a Record are on a single line, when feasible. Especially for the "multiple data points" examples. Anyway, Michael's comment was about indentation, which I agree should be (and is now) fixed.
See email from Michael Koster "Formatting of JSON examples in SenML"
Code change:
8. <del> We can provide DATAGRAM support in HTTP/2 by defining the CAPSULE frame in HTTP/2. We can provide DATAGRAM support in HTTP/1.x by defining its data stream format to a sequence of length-value capsules. TODO: Refactor this document and add definitions for HTTP/1.x and HTTP/2. 9. </del> Since this feature requires sending an HTTP/3 Settings parameter, it "sticks out".  In other words, probing clients can learn whether a server supports this feature.  Implementations that support this

Related discussion:
text: Had offline conversation with Lucas, conclusion was that this is good enough to merge to allow interop - we'll have plenty of time to figure out details in subsequent issues and PRs.
Code change:
that the load balancer will redirect the next Client Initial packet to a different server in that pool. <del> 6.3. QUIC provides for multiple Server and Client Connection IDs to be used simultaneously by a given connection, which allows seamless connection migration when one of the endpoints changes IP address and/or UDP port.  Section 6.11.5 of QUIC describes how to use this facility to reduce the risk of exposing a link among these addresses to observers on the network.  However, analysis of the lifetimes of six-tuples (source and destination addresses as well as the migrated CID) may expose these links anyway. In practice, a finite set of flows will be undergoing migration within any one time window as seen from any given observation point in the network, and any migration must keep at least one endpoint address constant during the migration.  Because of this, a key insight here is that this finite set of flows represents the anonymity set for any one flow undergoing migration within it.  For endpoints with low volume, this anonymity set will be necessarily small, so there remains a significant risk of linkage exposure through timing-based analysis. The most efficient mitigation for these attacks is operational, by increasing the size of the anonymity set as seen from a passive observer in the Internet, either by using a load balancing architecture that loads more flows onto a single server-side address, by coordinating the timing of migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means. </del> 7. Versioning in QUIC may change the protocol's behavior completely,

Related discussion:
text: Tries to I resisted the urge to reference the QUIC-LB draft, which isn't adopted. The major substantive change is that I removed the prohibition on non-routing information in the CID. I'm happy to discuss this if people have object.
LGTM. will go ahead and land this, then fix up the lint issues.
NAME missed this during the inconsistency, will fix in working copy
(this is done)
BTW, this was meant to address
Moving URL to the ops repo.
see also -- in any case the text that is there now is not great.
NAME can you please review the existing text (orginially provided by NAME and state what else is needed? Please have also a look at issue
This is a bit OBE, but I think there might still be value in discussing how a server implementer should think about connection IDs. Fortunately, NAME has been doing a bunch of work on this in his load balancer draft. I would suggest that we leave this issue open, and either point to the LB draft or use text from it.
fixed this
Write section to provide guidance; maybe in the same section than guidance in port selection in general
Code change:
Ciphersuites are represented with the CipherSuite type.  HPKE public keys are opaque values in a format defined by the underlying Diffie- Hellman protocol (see the Ciphersuites section of the HPKE <del> specification for more information): 6.1.1. This ciphersuite uses the following primitives: </del> <ins> specification for more information). </ins> <del> Hash function: SHA-256 </del> <ins> The signature algorithm specified in the ciphersuite is the mandatory algorithm to be used for the signatutes in MLSPlaintext and the tree signatures.  It can be different from the signature algorithm specified in credential fielf of ClientInitKeys. </ins> <del> AEAD: AES-128-GCM </del> <ins> The ciphersuites are defined in section mls-ciphersuites. </ins> <del> When HPKE is used with this ciphersuite, it uses the following algorithms: KEM: 0x0002 = DHKEM(Curve25519) </del> <ins> 6.1.1. </ins> <del> KDF: 0x0001 = HKDF-SHA256 </del> <ins> Depending on the Diffie-Hellman group of the ciphersuite, different rules apply to private key derivation and public key verification. </ins> <del> AEAD: 0x0001 = AES-GCM-128 </del> <ins> 6.1.1.1. </ins> Given an octet string X, the private key produced by the Derive-Key- <del> Pair operation is SHA-256(X).  (Recall that any 32-octet string is a valid Curve25519 private key.)  The corresponding public key is </del> <ins> Pair operation is SHA-256(X) (Recall that any 32-octet string is a valid X25519 private key).  The corresponding public key is </ins> X25519(SHA-256(X), 9). Implementations SHOULD use the approach specified in RFC7748 to

Related discussion:
text: :smiley: You can also .
Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 0 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by - - Last week, 4 pull requests were created, updated or merged. Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there was 1 commit. :hammerandwrench: by - - Last week there was 1 contributor. :bustin_silhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
This seems to accurately reflect the consensus we had at the last interim, and there's nothing I can't live with otherwise. I will probably file a follow-up to convert the Derive-Key-Pair operations to use HKDF directly, as discussed, avoiding the need for intermediate values or truncation of SHA-512.
Code change:
3.7. <del> JSEP supports simulcast of a MediaStreamTrack, where multiple encodings of the source media can be transmitted within the context of a single m= section.  The current JSEP API is designed to allow applications to send simulcasted media but only to receive a single encoding.  This allows for multi-user scenarios where each sending client sends multiple encodings to a server, which then, for each receiving client, chooses the appropriate encoding to forward. </del> <ins> JSEP supports simulcast transmission of a MediaStreamTrack, where multiple encodings of the source media can be transmitted within the context of a single m= section.  The current JSEP API is designed to allow applications to send simulcasted media but only to receive a single encoding.  This allows for multi-user scenarios where each sending client sends multiple encodings to a server, which then, for each receiving client, chooses the appropriate encoding to forward. </ins> Applications request support for simulcast by configuring multiple encodings on an RTPSender, which, upon generation of an offer or

Related discussion:
text: Originally raised by Magnus: Section 3.7: JSEP supports simulcast of a MediaStreamTrack, where multiple encodings of the source media can be transmitted within the context of a single m= section. I think this should be explcit that it is "simulcast transmission of a MediaStreamTrack".
Code change:
If the "path_secret" value is set in the GroupSecrets object: Identify the lowest common ancestor of the leaf node "my_leaf" <del> and of the node of the member with LeafNodeRef </del> <ins> and of the node of the member with leaf index </ins> "GroupInfo.signer".  Set the private key for this node to the private key derived from the "path_secret".

Related discussion:
text: This seems to be a layer of indirection that doesn't add any value to implementation.
The Credentials section claims there is an epoch id field in key packages. I don't think that actually exists. My apologies if this is a duplicate issue.
Addressed in but may need to be pulled out depending on the fate of that PR
contains all of the Proposals that were previously sent within the same epoch. This seems unnecessary, since all members should have them anyway. The list of in the actual message should be enough for members to parse and validate a message. We should discuss if we can de-duplicate this, since the list of Proposals might be quite long.
The current definition of is as follows; Maybe this issue is obsolete?
Seems it is now obsolete indeed.
I don't have a strong opinion on this question, but this change seems sensible to me. The use of LeafNodeRef requires either (a) a linear scan through the tree, which is time-expensive in large trees, or (b) keeping an index that maps LeafNodeRef values to indices, which is storage-intensive in large trees. IIRC, the change to LeafNodeRef was made in the context of NAME work to make the tree description less tied to the array representation. In general, that is the right thing to do, and it's good that we did it. But we still have leaf indices anyway, for . Since we still have the concept, we might as well use it where it makes sense. And it certainly seems to me like and make sense, since they are internal to the protocol. In case folks are worried about the application-facing API -- MLS stacks can certainly be more intelligent, e.g., exposing or or . But they can do that regardless of this PR.
Code change:
lookup would provide DNS as opposed to DNSSEC responses provided by the Public Authoritative Server(s). <del> 3) Keeping the Homenet Zone and the Public Homenet Zone equal to guarantee coherence between DNS responses.  Using a unique zone is one way to guarantee uniqueness of the responses among servers and places.  Issues generated by different views are discussed in more details in sec-views. 4) Privacy and Integrity of the DNSSEC Homenet Zone are better guaranteed.  When the Zone is signed by the HNA, it makes modification of the DNS data -- for example for flow redirection -- impossible.  As a result, signing the Homenet Zone by the HNA provides better protection for end user privacy. </del> <ins> Privacy and Integrity of the DNSSEC Homenet Zone are better guaranteed.  When the Zone is signed by the HNA, it makes modification of the DNS data -- for example for flow redirection -- impossible.  As a result, signing the Homenet Zone by the HNA provides better protection for end user privacy. </ins> Reasons for signing the zone by the Outsourcing Infrastructure are:

Related discussion:
text: …ument, dealing with issue
handling different views (7.0) .... some would like to have different views, This document deals with the view that the Internet gets from the CPE(s) only.
Code change:
Fulfill the server's requirements for issuance <del> Finalize the application and request issuance </del> <ins> Await issuance and download the issued certificate </ins> The client's application for a certificate describes the desired certificate using a PKCS#10 Certificate Signing Request (CSR) plus a

Related discussion:
text: Based on the acme mailing list discussion[0] on "proactive" vs "on-finalization" issuance it seems there is more support for the proactive approach. Speaking on behalf of Let's Encrypt and the Boulder developers we're willing to compromise and support proactive issuance as the sole issuance method in order to simplify the protocol & implementations. This PR changes the language around certificate issuance to reflect that the server MUST issue the certificate proactively once all the required challenges for an application have been fulfilled. The open issue corresponding to making this decision is removed now that there is one supported option. In an effort to close out open questions around applications this commit also removes the open issue around multiple certificates per application. If there is a demand for automating repeat issuance there should be a new thread started with a concrete proposal. 0: URL
NAME apologies! I missed your comments until today. Both are resolved in URL Thank you for the feedback.
Oh! They were fresh and I misread the dates. Not such a bad turn around after all :-)
NAME Fantastic, thanks. Merging. Hi folks, I wanted to revisit a discussion on the server proactively issuing certificates. Section 4, "Protocol Overview"[0] currently has a paragraph that reads: the the application be to the There is also an "Open Issue" remark related to proactive issuance in Section [1]. I think the specification should decide whether proactive issuance or on-finalization issuance should be used instead of allowing both with no indication to the client which will happen. It's the preference of Let's Encrypt that the specification only support on-finalization issuance. This is cheaper to implement and seems to be the path of least surprise. It also seems to better support large volume issuance when the client may want explicit control over when the certificates for multiple applications are issued. In the earlier "Re: [Acme] Preconditions" thread[2] Andrew Ayer seems to agree that there should be only one issuance method to simplify client behaviours, though he favours proactive issuance instead of on-finalization issuance. While it saves a round-trip message I'm not sure that this alone is convincing enough to choose proactive issuance as the one issuance method. What are the thoughts of other list members? Daniel/cpu [0] URL [1] URL [2] URL
Code change:
access control mechanisms SHOULD be used to protect it such as file system controls, physical security or hardware security modules. <del> 6.2. </del> <ins> 6.3. </ins> Delegated credentials do not provide any additional form of early revocation.  Since it is short lived, the expiry of the delegated

Related discussion:
text: Based on The delegation certificate MAY have the DelegationUsage extension marked critical. This also adds a "strict" flag to the extension that, if set, requires the server to offer a DC. An alternative that was discussed is to add an optional TLS-feature extension (per RFC 7633) that would provide a "must-use-DC" feature, analogous to "must-staple-OCSP". Howver, it's possible for a certificate with such an extension to be used in a handshake without DCs if the client doesn't indicate support for DCs.
Code change:
implementation to communicate control data to the remote endpoint that can be used to parse Messages. <ins> Similarly, when a Message Framer generates a "Stop" event, the framer implementation has the opportunity to write some final data or clear up its local state before the "Closed" event is delivered to the Application.  The framer implementation can indicate that it has finished with this. </ins> At any time if the implementation encounters a fatal error, it can also cause the Connection to fail and provide an error. <ins> Should the framer implementation deem the candidate selected during racing unsuitable it can signal this by failing the Connection prior to marking it as ready.  If there are no other candidates available, the Connection will fail.  Otherwise, the Connection will select a different candidate and the Message Framer will generate a new "Start" event. </ins> Before an implementation marks a Message Framer as ready, it can also dynamically add a protocol or framer above it in the stack.  This allows protocols like STARTTLS, that need to add TLS conditionally,

Related discussion:
text: Just some points about the new text on framers in the API draft: In 10.2 it is specified in which order multiple framers run on incoming and outgoing messages, it is however never specified what the order looks like on Start and Stop events. In 10.6, "MessageFramer.DeliverAndAdvanceReceiveCursor" appears to be missing the "Data" argument that is present in "MessageFramer.Deliver". Also in 10.6, in the second paragraph it says: When it is probably meant to say While the framer implementation is able to notify the Connection that it has finished handling a Start event (by calling MessageFramer.MakeConnectionReady), there is no such way for Stop events.
As notes for the responses to these points: If there are multiple framers, the "lowest" one (the one closest to the transport) would receive start first, and the next would get the start event when the lower one is ready. Similar for stop. Good calls on the missing data argument and the typo re application vs framer. I was thinking to use the failConnection call to complete a stop, potentially with no error?
Code change:
on multiple already existing media types. Applications using the application/multipart-core Content-Format <del> define the internal structure of the application/multipart-core representation. </del> <ins> define the semantics as well as the internal structure of the application/multipart-core representation according to the syntax described by the CDDL in mct-cddl. </ins> For example, one way to structure the sub-types specific to an application/multipart-core container is to always include them at the

Related discussion:
text: …oundaries defined by the CDDL
We should add something like: " within the syntactical boundaries defined by the CDDL in Figure 1."
Code change:
Transport Properties MUST always be specified while security parameters are OPTIONAL. <del> Message Framers (see framing), if required, should be added to the </del> <ins> If Message Framers are used (see framing), they MUST be added to the </ins> Preconnection during pre-establishment. 5.1.

Related discussion:
text: In the API doc sec 5 says. "Message Framers (see Section 10), if required, should be added to the Preconnection during pre-establishment." Should this be SHOULD or even MUST? If SHOULD is correct I think we need to say slightly more about when it makes sense to add a framer later.
I think it should be "can be added..."; not normative, just descriptive of fact.
Can we start with the "If' perhaps... "If messages frames are to be used, they MUST be added to the Preconnection during pre-establishment."?