jiebi/CodeConvo huggingface dataset:
Change:
version used).  While this document updates EAP-TLS RFC5216, it remains backwards compatible with it and existing implementations of EAP-TLS.  This document only describes differences compared to <del> RFC5216.  All message flow are specific to TLS 1.3 and do not apply to TLS 1.2. </del> <ins> RFC5216.  All message flow are example message flows specific to TLS 1.3 and do not apply to TLS 1.2. </ins> In addition to the improved security and privacy offered by TLS 1.3, there are other significant benefits of using EAP-TLS with TLS 1.3.

Discussion:
Some of the text describing the figures indicated that TLS 1.3 only has one possible message flow. This pull request change the text to make it is clear that the message flows are examples. Based on discussion on the List initiated by Alan.
Change:
overall label size inside of one hash iteration because "DTLS" is one letter longer than "TLS". <del> 5.11. </del> <ins> 5.10. </ins> Note that Alert messages are not retransmitted at all, even when they occur in the context of a handshake.  However, a DTLS implementation

Discussion:
This makes the handshake the same as TLS 1.3 (modulo the version numbers, which are conveniently different.
As discussed at the meeting. NAME PTAL.
This also LGTM. Let's do a brief consensus call before merging.
Change:
The DCID might not be long enough for the routing algorithm to process. <ins> The config rotation bits config-rotation may not correspond to an active configuration. </ins> The extracted server mapping might not correspond to an active server.

Discussion:
Make it clear that the server has to provide the client with a compliant DCID if the client isn't already using one.
Dear sir, As you know, there is no bit in the cid to mark whether the cid encoded the server info or not. In this case, no matter the server info encoded or not, the load balancer needs to decrypt or decode the cid. Do you think this is a useless try when the packet is the first initial packet? Do you think this is a useful idea to expand the cid format to use the first bit to mark the cid encoded or not? However, in this case, the client need to obey the rule.
In fact, there is a bit. If the first two bits are '11' that means that the server didn't encode its ID and the load balancer should use 4-tuple routing: URL The very first packet usually has a CID chosen by the client, which knows nothing about QUIC-LB. The beginning of Section 4 is mostly about how load balancers should handle these.
OK, I almost have forgot the first two Config Rotation bits can be used to mark the cid server info's validity. However, in this case, I want to know , for the very first packet, will the draft suggest the clients to generate the dcid with the first two bits "11" , if they know the QUIC-LB used. As, if so, the QUIC-LB know all packets' cid information to prevent useless decode/decrypt try for the very first packet.
No, this draft does not assume client cooperation at all. The very beginning of Section 4 explains how to handle client-generated CIDs.
Thanks for your reply. Actually, I understand your works and Section 4. However, my point is that , even this draft does not assume client cooperation at all, this draft can suggest the client to generate a cid with 11 for the very first initial packet. This is useful for QUIC-LB if client obeys the rule, if not , the Section 4 also works well.
In I'm adding CR bits as a reason for noncompliance. It's fine if the client wants to set '11' , but I don't think it's important to do that. At most all we're saving the LB is a very small decrypt operation.

Even thought the decryption has a low consumption, I insist that the cost can be avoided. I admit that the lb can't assume client cooperation at all, however, the draft can suggest the client to obey the rule: " As, it is impossible for the client to know the server information at the beginning of the QUIC conn, so the DCID in the initial can't encode the server info, in this case, the Client should make the first two bits with "11". "
Change:
6.3.2. <del> When a PTO timer expires, the sender MUST send one ack-eliciting packet as a probe, unless there is nothing to send.  A sender MAY send up to two ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single packet loss. </del> <ins> When a PTO timer expires, a sender MUST send at least one ack- eliciting packet as a probe, unless there is no data available to send.  An endpoint MAY send up to two ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single packet loss. It is possible that the sender has no new or previously-sent data to send.  As an example, consider the following sequence of events: new application data is sent in a STREAM frame, deemed lost, then retransmitted in a new packet, and then the original transmission is acknowledged.  In the absence of any new application data, a PTO timer expiration now would find the sender with no new or previously- sent data to send. When there is no data to send, the sender SHOULD send a PING or other ack-eliciting frame in a single packet, re-arming the PTO timer. Alternatively, instead of sending an ack-eliciting packet, the sender MAY mark any packets still in flight as lost.  Doing so avoids sending an additional packet, but increases the risk that loss is declared too aggressively, resulting in an unnecessary rate reduction by the congestion controller. </ins> Consecutive PTO periods increase exponentially, and as a result, connection recovery latency increases exponentially as packets

Discussion:
This PR adds text and pseudo-code to clarify what an endpoint should do when PTO fires and there is no data or other ack-eliciting frames to send.
NAME I've done s/endpoint/sender. Let's deal with this separately. On the SHOULD, thinking about this, yes, I think I agree with you. I'll modify the PR, let's see how that looks.
Ok, modified, take a look
As written now, this swaps a SHOULD and a MAY, so I'm changing it to design.
As discussed with NAME 6.2.2.2 is awkward, because in the first paragraph it says And then the very last paragraph changes that by saying What is super unclear is that the final paragraph apparently means to imply that when there is no new or unACKed data to send, nothing should be send, i.e., it invalidates the SHOULD in the first paragraph. Related to that, the pseudo code still uses , which is also inaccurate, since it's really "at least one (unless you don't have new or unACKed data) but can also send two". Good luck finding a good name for that function :-)
The pseudocode now uses SendOneOrTwoPackets(), but the last paragraph pretty clearly violates the previous MUST, which is very bad. The simplest fix would be to change the MUST to a "SHOULD unless otherwise specified", but I'm increasingly thinking we should stick with the MUST and if you get into a situation you have nothing to send, require sending something ack-eliciting to ensure in-flight packets are removed from flight. Thoughts?
Change:
new key. For example, the following request to the token management endpoint <del> for rotating a token value contains both the old and new keys in the request.  The message is first signed using the old key and the resulting signature is placed in "sig1": </del> <ins> for rotating a token value contains both the new key in the request. The message is first signed using the old key and the resulting signature is placed in "sig1": </ins> The signer then creates a new signature using the new key using the signature value as its input to the signature base.  Since the

Discussion:
To edit notification comments on pull requests, go to your .
The "previous_key" element added in is not necessary in practice because the AS should always be able to look up the current key value based on the access token, and the signature using the previous key proves possession of that key separate from any presentation of the key value or reference.
Makes sense
Change:
any number more (subject to limits inherent to the protocol, such as congestion control and anti-amplification).  For instance, the server's first flight contains Initial packets, Handshake packets, <del> and "0.5-RTT data" in 1-RTT packets with a short header. </del> <ins> and "0.5-RTT data" in 1-RTT packets. </ins> tls-0rtt-handshake shows an example of a connection with a 0-RTT handshake and a single packet of 0-RTT data.  Note that as described

Discussion:
This PR restructures 17.3 to be aligned with 17.2. Note that while the diff seems to show whole paragraphs changed in the section, all I've done is replaced with . Note that I've not replaced all uses of . I've retained it where it is used alongside , for symmetry. This still touches more text than I had hoped, but it makes the structure of Section 17 clearer.
NAME Thanks for the note. I've updated the tls doc, but I've left most uses of as they are. I've retained them for symmetry, since in all the ones I've retained, it appears alongside .
While the transport draft talks a lot about "1-RTT packets", the term is not defined. We also have a sentence that seem to imply that a long-header variant of 1-RTT packets might exist (URL). We refer to the packet less frequently as "short header packets" or "packet with a short header." As a resolution, I think we might want to change the title of section 17.3 from "Short Header Packets" to "1-RTT Packets". Rest of the text can remain the same, as the first sentence of that section says that it is the only type of short header packet that we define.
Update: I think we might want to make corresponding changes to the TLS draft. Re TLS draft, I think we can replace all the occurrences of "short header packet(s)", "packet(s) with (a) short header" in the TLS draft with "1-RTT packet(s)", as well making necessary changes to table 1.This looks good. The actual changes are much smaller than the diff appears, and I think the symmetry with 17.2 helps readability despite the extra layer.
Change:
the ability to associate deadlines with messages, for applications that care about timing; <del> the ability control reliability, which messages to retransmit when there is packet loss, and how best to make use of the data that arrived; </del> <ins> the ability to control reliability, which messages to retransmit when there is packet loss, and how best to make use of the data that arrived; </ins> the ability to automatically assign messages and connections to underlying transport connections to utilize multi-streaming and

Discussion:
This pull requests fixes two minor typos in draft-ietf-taps-URL that I noticed during detailed reading of the draft.
Change:
Abstract <del> During the process of creating a peer-to-peer connection, ICE agents can encounter situations where they have no candidate pairs to check, and, as a result, conclude that ICE processing has failed.  However, because additional candidate pairs can be discovered during ICE processing, declaring failure at this point may be premature.  This document discusses when these situations can occur and proposes a way to avoid premature failure. </del> <ins> During the process of establishing peer-to-peer connectivity, ICE agents can encounter situations where they have no candidate pairs to check, and, as a result, conclude that ICE processing has failed. However, because additional candidate pairs can be discovered during ICE processing, declaring failure at this point may be premature. This document discusses when these situations can occur and proposes a way to avoid premature failure. </ins> 1.

Discussion:
LGTM with the tweak I added
Where: Abstract What: s/peer-to-peer connection/connectivity Why: We talk about establishing connectivity elsewhere
peer-to-peer seems important to retain here, not sure I agree with this change
Then we could at least use "peer-to-peer connectivity", because that seems to be used once in the Introduction of 8445.
I can get behind that.
Something happened. I forked the ICE WG repo, but when I created the PR it ended up in my private repo.
You used the wrong repo for the base repo. I fixed it in URL
I think I understand why that happened, ice-wg still thinks cdh4u is upstream, need to think about how to fix that.
Shouldn't it be possible to create a pull request to a fork? I guess my repo isn't needed anymore, so in worse case we can just remove it.
Fixed in
Looks good.
Change:
(*) indicates changes to the wire protocol. <ins> draft-03 Remove protocol version from the Credential structure. (*) </ins> draft-02 Change public key type. (*)

Discussion:
As discussed in URL and subsequent.
I have responded to the two comments. No idea why CI is busted.
looks like the CI segfaulted :) I'll manually test locally and merge
Please add yourself to acknowledgements as well. remove change in line 192 as well "Each delegated credential is bound to a specific version of TLS and signature". somehow i cant comment on changes that you haven't made. Dear TLS WG, While we were implementing delegated credentials we came up with the following two problems. I thank David Benjamin for communicating the first to me. The first is that a delegated credential is pinned to a particular version of TLS. Unfortunately this means that the rollout of a new version of TLS (which libraries consider that they can do on their own) makes an existing set of delegated credentials unusable, and the signer of delegated credentials needs to accept a new version of TLS as valid before the extension can be used with a new version. This is similar to the issues prompting draft-wood-tls-external-psk-importer-00 where PSKs depend on negotiated parameters, and thus are difficult to use in practice. The second is that the DelegatedCredential indicates the algorithm that was used to sign it. Someone who is a bit careless when implementing might take that literally with the result that they verify a DelegatedCredential with RSA algorithm and the certificate is really an ECDSA certificate. I'll submit a PR with text for security considerations/rewording the verification steps. Sincerely, Watson
Change:
RTT samples for the network path are recorded in latest_rtt; see latest-rtt.  On the first RTT sample after initialization, the estimator is reset using that sample.  This ensures that the <del> estimator retains no history of past samples. </del> <ins> estimator retains no history of past samples.  Packets sent on other paths do not contribute RTT samples to the current path, as described in Section 9.4 of QUIC-TRANSPORT. </ins> On the first RTT sample after initialization, smoothed_rtt and rttvar are set as follows:

Discussion:
From the transport draft's connection migration section.
Section 9.4 in Transport(URL) does a nice job of explaining the RTT and congestion control implications of migration, but given one might reasonably expect some or all of that text to exist in recovery, I think it makes sense to reference it more. In particular, "Packets sent on the old path MUST NOT contribute to congestion control or RTT estimation for the new path." is a useful sentence.
Change:
The resolution of a blank leaf node is the empty list The resolution of a blank intermediate node is the result of <del> concatinating the resolution of its left child with the resolution </del> <ins> concatenating the resolution of its left child with the resolution </ins> of its right child, in that order For example, consider the following tree, where the "_" character

Discussion:
This PR corrects three minor typos.
Thank you Pascal !
Here's the Weekly Digest for : - - Last week 18 issues were created. Of these, 3 issues have been closed and 15 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :speaker: , by It received 5 comments. - - Last week, 10 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 7 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 4 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 4 contributors. :bustinsilhouette: :bustinsilhouette: :bustinsilhouette: :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 .
Change:
streams are critical, and does not provide an interface to exceptional handling of any stream.  There are special streams in QUIC that are used for control on the QUIC connection, however, these <del> streams are not exposed to the apllication. </del> <ins> streams are not exposed to the application. </ins> Mapping of application data to streams is application-specific and described for HTTP/s in QUIC-HTTP.  In general data that can be

Discussion:
Tried to make '4. Use of Streams' a little more readable around exposing max allowed/used/open stream info to applications. (Not a native speaker but my best-effort after reading the draft.)
Change:
and derived secrets for the new epoch. Use the "confirmation_key" for the new epoch to compute the <del> confirmation MAC for this message, as described below, and verify that it is the same as the "confirmation" field in the </del> <ins> confirmation tag for this message, as described below, and verify that it is the same as the "confirmation_tag" field in the </ins> MLSPlaintext object. If the above checks are successful, consider the updated GroupContext object as the current state of the group. <del> The confirmation value confirms that the members of the group have arrived at the same state of the group: HMAC RFC2104 uses the Hash algorithm for the ciphersuite in use. </del> <ins> The confirmation tag value confirms that the members of the group have arrived at the same state of the group: </ins> 10.2.1.

Discussion:
This PR gets rid of the explicit HMAC reference and uses KDF.Extract instead (which internally uses HMAC). Also is renamed to .
I don't love the extra , but I can live with it.
Change:
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. <del> WHIP client: WebRTC Media encoder or producer that acts as client on the WHIP protocol and encodes and delivers the media to a remote media server. </del> <ins> WHIP client: WebRTC media encoder or producer that acts as a client of the WHIP protocol by encoding and delivering the media to a remote media server. </ins> WHIP endpoint: Ingest server receiving the initial WHIP request. WHIP endpoint URL: URL of the WHIP endpoint that will create the <del> WHIP resource </del> <ins> WHIP resource. </ins> <del> Media Server: WebRTC media server that establishes the media session with the WHIP client and receives the media produced by it. </del> <ins> Media Server: WebRTC media server or consumer that establishes the media session with the WHIP client and receives the media produced by it. </ins> WHIP resource: Allocated resource by the WHIP endpoint for an <del> ongoing ingest session that the WHIP client can send request for </del> <ins> ongoing ingest session that the WHIP client can send requests for </ins> altering the session (ICE operations or termination, for example). WHIP resource URL: URL allocated to a specific media session by <del> the WHIP endpoint which can be used to perform operations such </del> <ins> the WHIP endpoint which can be used to perform operations such as </ins> terminating the session or ICE restarts. 3. The WebRTC-HTTP ingest protocol (WHIP) uses an HTTP POST request to perform a single shot SDP offer/answer so an ICE/DTLS session can be <del> established between the encoder/media producer and the broadcasting ingestion endpoint. </del> <ins> established between the encoder/media producer (WHIP client) and the broadcasting ingestion endpoint (media server). </ins> Once the ICE/DTLS session is set up, the media will flow <del> unidirectionally from the encoder/media producer to the broadcasting ingestion endpoint.  In order to reduce complexity, no SDP renegotiation is supported, so no tracks or streams can be added or removed once the initial SDP O/A over HTTP is completed. </del> <ins> unidirectionally from the encoder/media producer (WHIP client) to the broadcasting ingestion endpoint (media server).  In order to reduce complexity, no SDP renegotiation is supported, so no tracks or streams can be added or removed once the initial SDP offer/answer over HTTP is completed. </ins> 4.

Discussion:
I gave the spec a good read through and would like to propose some minor language edits as my first contribution. Most of these are straight forward such as: WebRTC not webrtc URI not uri signaling not signalling offer/answer not O/A some grammatical changes There is one somewhat significant correction here in that the header on the example WHIP endpoint reply pointed at the RFC for the extension. I believe this is incorrect and the intent is that this points at a WHIP resource. I have updated the example as such.
Change:
edge observed in the upstream direction and that observed in the downstream direction, and vice versa. <ins> Raw RTT samples generated using these techniques can be processed in various ways to generate useful network performance metrics.  A simple linear smoothing or moving minimum filter can be applied to the stream of RTT samples to get a more stable estimate of application-experienced RTT.  RTT samples measured from the spin bit can also be used to generate RTT distribution information, including minimum RTT (which approximates network RTT over longer time windows) and RTT variance (which approximates jitter as seen by the application). </ins> 4. In this section, we review specific network management and

Discussion:
URL must be postprocessed to become metrics.
Waiting for more reviews, e.g. from NAME before we can merge.
The text describes an example for measuring the average RTT. I like that, but I think we should call out a little that the mean RTT is only one metric. When looking at management info, I'm often interested in min/max and variance... So: “A simple linear smoothing... to get a more stable estimate”. Quite so for a table average RTT. I’d prefer it if we could say something about RTT variance at this point. To me it is important that RTT measurements are clear, and we should never assume in a Spec that RTT is something specific, but more generally an estimate that needs to consider the variance.
Change:
Description: Identifies the server in an OSCORE context Reference: [[this specification]] <del> Name: kdf </del> <ins> Name: hkdf </ins> Label: TBD3 (value between 1 and 255) Value Type: bstr Value Registry: COSE Algorithms registry

Discussion:
restructuring for readability adding a section for protocol overview adding examples for each message adding details about updating clients rights (request new token with only scope different) where before there were ref to the framework, explicitly state all the normative text add mechanism during OSCORE Setup for making sure the context is not reused on the server if token is re-posted after it has been lost/removed (nonces) added section about access rights verification between OSCORE layer and CoAP (handling of the resource) layer