jiebi/CodeConvo huggingface dataset:
Change:
6. <del> The simultaneous usage of several sending paths introduces new algorithms (packet scheduling, path management) whose specifications are out of scope of this document.  Nevertheless, these algorithms are actually present in any multipath-enabled transport protocol like Multipath TCP, CMT-SCTP and Multipath DCCP.  A companion draft I- D.bonaventure-iccrg-schedulers provides several general-purpose packet schedulers depending on the application goals.  A similar document can be created to discuss path management considerations. </del> <ins> The transmission of QUIC packets on a regular QUIC connection is regulated by the arrival of data from the application and the congestion control scheme.  QUIC packets can only be sent when the congestion window of at least one path is open. Multipath QUIC implementations also need to include a packet scheduler that decides, among the paths whose congestion window is open, the path over which the next QUIC packet will be sent.  Many factors can influence the definition of these algorithms and their previse definition is outside the scope of this document.  Various packet schedulers have been proposed and implemented, notably for Multipath TCP.  A companion draft I-D.bonaventure-iccrg-schedulers provides several general-purpose packet schedulers depending on the application goals. </ins> 7.

Discussion:
Some more text for the scheduling section to clarify it.
A suggestion to resolve Mirja's point, also agree on the proposed change in line 248.
Change:
disabled for a connection.  Implementations MUST allow administrators of clients and servers to disable the spin bit either globally or on a per-connection basis.  Even when the spin bit is not disabled by <del> the administrator, implementations MUST disable the spin bit for a given connection with a certain likelihood.  The random selection process SHOULD be designed such that on average the spin bit is disabled for at least one eighth of network paths.  The selection process performed at the beginning of the connection SHOULD be applied for all paths used by the connection. </del> <ins> the administrator, endpoints MUST disable their use of the spin bit for a random selection of at least one in every 16 network paths, or for one in every 16 connection IDs.  As each endpoint disables the spin bit independently, this ensures that the spin bit signal is disabled on approximately one in eight network paths. </ins> When the spin bit is disabled, endpoints MAY set the spin bit to any value, and MUST ignore any incoming value.  It is RECOMMENDED that

Discussion:
This builds on to address the linkability issues that it added. It recommends 1/16 of network paths are disabled randomly as suggested by NAME It also allows the determination to be made per connection ID rather than per-path (which is more granular, but I expect it will have a nearly identical effect). The net effect is that 1/8 paths will not spin as originally intended.
The draft says: Given that each endpoint needs to decide for itself whether it is enabling spin bit, it is not exactly clear whether each endpoint SHOULD disable spin bit on at least 1/8 (=12.5%) of connections, or it can assume that the other endpoint is also making a random decision to disable and disable only on 1-sqrt(7/8) (=6.5%) of connections.
as the author of this passage, I intended the latter (assume the other side is disabling as well, so 1-sqrt(7/8)), but the "at least" is in there since just disabling 1/8 is probably what people will do, and the result (about 1/4) is "at least 1/8".
NAME could you review ?
One suggestionLooks good technically. It may be slightly confusing, though, that the last sentence only talks about paths, while a sentence before talks about "paths or connection IDs". In any case, the behavior ensures a sufficient amount of traffic without the spin bit to prevent ossification of the bit.
Change:
The client MUST NOT assume that all its "service-limit" will be restored after the moment referenced by "RateLimit-Reset".  The server MAY arbitrarily alter the "RateLimit-Reset" value between <del> subsequent requests eg. in case of resource saturation or to </del> <ins> subsequent requests e.g. in case of resource saturation or to </ins> implement sliding window policies. 4.

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:
In those situations, the registrant needs to be careful to authenticate the RD as well.  The registrant needs to know in advance which AS, audience and scope values indicate an RD it may trust for <del> this purpose, and can not rely on the RD to provide AS address and </del> <ins> this purpose, and cannot rely on the RD to provide AS address and </ins> token details.  (In contrast, in the other scenarios it may try to register, and follow the pointers the RD gives it as to which credentials it needs to provide in order to perform its

Discussion:
Will merge before the interim to have a discussion on the big stuff with the small stuff out of the way.
Change:
The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node, introducing delay and degrading media quality.  This transcoding step <del> is always present in traditionnal streaming to support e.g.  ABR, and </del> <ins> is always present in traditional streaming to support e.g.  ABR, and </ins> comes at no cost.  However webrtc implements client-side ABR, also called Network-Aware Encoding by e.g.  Huavision, by means of simulcast and SVC codecs, which otherwise alleviate the need for

Discussion:
Authtentication, bearear, proposse, detailled, endpoings, adption, traditionnal.
Thank you very much!
Change:
SignatureScheme is as defined in RFC8446.  This is expected to be the same as CertificateVerify.algorithm sent by the server. <del> The version of TLS in which the credential will be used, where the type ProtocolVersion is as defined in RFC8446.  This is expected to match the protocol version that is negotiated by the client and server. </del> The credential's public key, a DER-encoded X690 SubjectPublicKeyInfo as defined in RFC5280.

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:
IMPORTANT NOTE: The security properties for 0-RTT data are weaker than those for other kinds of TLS data.  Specifically: <del> This data is not forward secret, because it is encrypted solely with the PSK. </del> <ins> The early data is encrypted solely under keys derived using the offered PSK as the static secret.  Hence, this data is not forward secret, because it is encrypted solely with the PSK. </ins> There are no guarantees of non-replay between connections.  Unless the server takes special measures outside those provided by TLS,

Discussion:
I am proposing that a client can also use the Zero-RTT with PSK-based authentication without having to rely on a previously obtained ticket.
Surely there would need to be additional security considerations for this behavior?!
This seems reasonable and was my intent, at least. Can you fix the build problem.
Could you please add linebreaks to wrap to about 80 character or so lines? Our line length is often rather inconsistent, but we do generally try to keep lines shorter than in the current changeset.
This LGTM. I'll let it sit for a little but in case anyone wants to weigh in (NAME NAME NAME
That's the sort of additional considerations that I was expecting to see, yes. I think that you got the list basically right, though there are a few things here that could be clearer.
Change:
4.4. In CoAP over TCP, Empty messages (Code 0.00) can always be sent and <del> MUST be ignored by the recipient (see also sec-ping).  This provides a basic keep-alive function that can refresh NAT bindings.  In contrast, Ping and Pong messages are a bidirectional exchange. </del> <ins> MUST be ignored by the recipient.  This provides a basic keep-alive function that can refresh NAT bindings.  In contrast, Ping and Pong messages are a bidirectional exchange. </ins> Upon receipt of a Ping message, a single Pong message is returned with the identical token.  As with all Signaling messages, the

Discussion:
There needs to be guidance about the intersection of WebSocket Ping-Pong and Signaling Ping-Pong.
Since Signaling Ping-Pong is a superset of WebSockets Ping-Pong and to use a consistent mechanism across reliable transports, I will add guidance that Signaling Ping-Pong is preferred over WebSockets Ping-Pong.
Change:
HTTP can make use of already-deployed caching infrastructure. <ins> Various HTTP versions have been used for media delivery.  HTTP/1.0, HTTP/1.1 and HTTP/2 are carried over TCP, and TCP's transport behavior is described in tcp-behavior.  HTTP/3 is carried over QUIC, and QUIC's transport behavior is described in quic-behavior. </ins> Unreliable media delivery using RTP and other UDP-based protocols is also discussed in ultralow, udp-behavior, and hop-by-hop-encrypt, but it is difficult to give general guidance for these applications.  For

Discussion:
From NAME " reliable media using HTTP over TCP," should MOQ be cited here ? or HTTP/3 over QUIC ?
NAME - Thanks for catching this. The relevant point here is that HTTP is carried over reliable transport protocols. The behavior of specific transport protocols is described in subsections of Section 6. I've clarified that in Section 2.
Change:
If the client supports simulcast and wants to enable it for publishing, it MUST negotiate the support in the SDP offer according to the procedures in RFC8853 section 5.3.  A server accepting a <del> simulcast offer MUST create an answer accoding to the procedures </del> <ins> simulcast offer MUST create an answer according to the procedures </ins> RFC8853 section 5.3.2. 4.7.

Discussion:
If you find them useful, here are some spelling fixes. The ' PATH ' spelling is confusing, I think it should be ' PATCH ' Also the draft URL points to and older draft. I have been very inspired by WHIP, thank you for giving it to the community.
Change:
respective content format. The collection is encoded as a CBOR RFC7049 array with an even number <del> of elements.  The second, fourth, sixth, etc. element is a byte string containing a representation, or the value "null" if an optional part is indicated as not given.  The first, third, fifth, etc. element is an unsigned integer specifying the content format ID of the representation following it. </del> <ins> of elements.  Counting from zero, the odd-numbered elements are a byte string containing a representation, or the value "null" if an optional part is indicated as not given.  The (even-numbered) element preceding each of these is an unsigned integer specifying the content format ID of the representation following it. </ins> For example, a collection containing two representations, one with content format ID 42 and one with content format ID 0, looks like

Discussion:
Address Benjamin Kaduk's outstanding DISCUSS.
No: with that, the sender sends along all formats and the recipient chooses based on its capabilities or preferences. Appropriate for single-shot mail, not at all appropriate for a request/response situation (at least not for the response part). URL Grüße, Carsten
Ah sorry, hadn't read properly (it's sender, not receiver).
LGTM
Change:
Empty non-terminals (ENT) F <ins> FORMERR </ins> Fast flux DNS Forward lookup Forwarder

Discussion:
I have added your text (approximately) and merged the pull request.
During the discussion that led to RFC 7719, there was a request to split out error names in their own terms to make them easier to find in the document. Now with the index in place, this seems like a good idea.
Oooh, yes, I think that this would be great. [Sorry for the non-substantive / bikeshed comment]
Entered in the doc as URL
I think this is ok, but I'd like a tiny edit before the list starts: "The names as of this writing are described below, but the official list is in the IANA registry." Or something like this. I just don't want to suggest we're arguing with the authoritative registry.
Change:
same type which are both numbers or both strings and which satisfy the comparison: <del> numbers in the I-JSON RFC7493 range of exact values MUST compare using the normal mathematical ordering; one or both numbers outside that range MAY compare using an implementation </del> <ins> numbers expected to interoperate as per RFC7493 MUST compare using the normal mathematical ordering; numbers not expected to interoperate as per I-JSON MAY compare using an implementation </ins> specific ordering the empty string compares less than any non-empty string

Discussion:
Fix some nits pointed out by NAME Improve definition of children Unicode Scalar Values are integers Typo fix Ordering of non-integer numbers
Change:
secchan discusses security considerations for Secure Channels, in which UCCS might be used.  This document provides the CBOR tag definition for UCCS and a discussion on security consideration for <del> the use of UCCS in Remote Attestation Procedures (RATS).  Uses of UCCS outside the scope of RATS are not covered by this document.  The UCCS specification - and the use of the UCCS CBOR tag, correspondingly - is not intended for use in a scope where a scope- specific security consideration discussion has not been conducted, vetted and approved for that use. </del> <ins> the use of UCCS in RATS.  Uses of UCCS outside the scope of RATS are not covered by this document.  The UCCS specification - and the use of the UCCS CBOR tag, correspondingly - is not intended for use in a scope where a scope-specific security consideration discussion has not been conducted, vetted and approved for that use. </ins> 6.1.

Discussion:
Archived-At:
straight forward. :ship: it! A few comments/questions for WGLC: The secure channel definition in section 1.1 may benefit from stating that mutual authentication is not required. This is hinted at by stating "the same qualities" as CWT conveyance are required but, given the NIST definition requires mutual auth, additionally saying mutual auth is not required would be clearer.In section 3.1.2, perhaps change the end of the last sentence to "using a Detached-Submodule-Digest or Detached-EAT-Bundle" since the Detached-Submodule-Digest is what conveys the hash and can be used independent of a Detached-EAT-Bundle.In Table 1 in Section 4, should the Data Item be Claims-Set instead of map? The registry is inconsistent. Some definitions are general with only map or array listed, others identify a specific type, e.g., the COSE types.There is a TODO in Appendix A and a note to insert definitions from 9052.The CDDL should include the tag definition that is the focus of this draft, something like: UCCS = .TBD601(Claims-Set) Independent of this draft, many current specs that use CDDL (including this one) repeat definitions that appear elsewhere. Perhaps it is close to time to discontinue this practice, publish an I-D or two that provide CDDL definitions for specs that predate CDDL (like RFC5911 and 5912 did for ASN.1), and then have future specs only define new things. On 1/11/23, 1:27 PM, "RATS on behalf of Henk Birkholz" on behalf of EMAIL > wrote: Dear RATS WG, this I-D should now be ready for WGLC. Viele Grüße, Henk RATS mailing list EMAIL URL
Change:
MLS adopts the Internet threat model RFC3552 and therefore assumes that the attacker has complete control of the network.  It is <del> intended to provide the security services described in in the face of </del> <ins> intended to provide the security services described in the face of </ins> such attackers.  In addition, these guarantees are intended to degrade gracefully in the presence of compromise of the transport security links as well as of both clients and elements of the

Discussion:
There were some odd formulations in section 3.1.3. I hope I addressed those issues without changing the intended meaning.
Change:
acknowledged, an endpoint SHOULD declare an earlier packet lost if it was sent a threshold amount of time in the past.  To avoid declaring packets as lost too early, this time threshold MUST be set to at <del> least kGranularity.  The time threshold is: </del> <ins> least the local timer granularity, as indicated by the kGranularity constant.  The time threshold is: </ins> If packets sent prior to the largest acknowledged packet cannot yet be declared lost, then a timer SHOULD be set for the remaining time.

Discussion:
Adds more text about what the constant kGranularity represents where it's first used and changes a SHOULD to a RECOMMENDED. Inspired by
This seems reasonable.
Change:
acknowledged, an endpoint SHOULD declare an earlier packet lost if it was sent a threshold amount of time in the past.  To avoid declaring packets as lost too early, this time threshold MUST be set to at <del> least kGranularity.  The time threshold is: </del> <ins> least the local timer granularity, as indicated by the kGranularity constant.  The time threshold is: </ins> If packets sent prior to the largest acknowledged packet cannot yet be declared lost, then a timer SHOULD be set for the remaining time.

Discussion:
As pointed out in , I think that we should assume same amount of RTT variance when there is no RTT sample and when there is one sample, because variance is unknown in both cases. This PR makes that change while keeping the initial PTO being the same (i.e. 1 second), and slightly simplifies the timeout logic.
NAME Thank you for the review. Would you ming checking if the updated text has what you have suggested?
NAME NAME Thank you for the suggestions. I've applied them.
For each connection, the loss detection timeout is defined as 2 InitialRTT. I wonder if this should be 3 InitialRTT instead, because, once you have one RTT sample, PTO is calculated as 3 * InitialRTT. I do not think we have a reason to believe that the variance of RTT (which applies as a multiplier here) increases when we obtain the first sample? PS. The other benefit of making these two consistent is that we can get rid of in SetLossDetectionTimer. It would be possible to always rely on PTO calculation.
I wasn't sure if this would be design or not, but now that the PR is complete, I believe it's editorial, as NAME PR changes the pseudocode, but proscribes exactly the same behavior as the existing text.
To be precise, there is one thing that does change, and that is the initial timeout when a connection is resumed on the same path. At the moment, the only variable we recommend to remember is SRTT, and when resuming a connection on the same path, use 2 SRTT as the initial timeout. The proposed change increases that to 3 SRTT. I think this is better than status-quo, assuming that we agree that RTTVAR should be 2 * sample when there is only one known sample.
Thanks for pointing that out, I noticed that the first time around and then forgot. I'll let NAME make the call about whether he thinks this is design then.
LGTM - thanks, NAME Can you resolve the merge conflict?
Change:
which can allow for better stream prioritization. The sending part of a bidirectional stream initiated by a peer (type <del> 0 for a server, type 1 for a client) enters the "Ready" state then immediately transitions to the "Send" state if the receiving part enters the "Recv" state (stream-recv-states). </del> <ins> 0 for a server, type 1 for a client) starts in the "Ready" state when the receiving part is created. </ins> In the "Send" state, an endpoint transmits - and retransmits as necessary - stream data in STREAM frames.  The endpoint respects the

Discussion:
The description here was a little over enthusiastic: it only enters the "Send" state when something is sent.
From -transport section 3.1: The event causing transition Ready->Send is the host initially having data to send on the stream, which is not the case when the receiving part has just been created in its initial Recv state. I think the send stream should stay in Ready until it has data. This also aligns better with similar text in 3.2. I suggest: p.s. see also , but which is more about being explicit about frames that cause stream creation... rather than this issue, which is about the state the new sending part starts in.
This issue can be closed -- see NAME commit above.
That commit hasn't been merged, and is sitting in a branch that doesn't appear to have an associated PR.
Oh -- sorry about that. I should have checked.
Wow, that sat there for ages. I made a PR.
Change:
A list of extensions that the client can take into consideration when generating a Client Hello message.  The format is defined in <del> I-D.ietf-tls-tls13; Section 4.2.  The purpose of the field is to provide room for additional features in the future; this document does not define any extension. </del> <ins> RFC8446; Section 4.2.  The purpose of the field is to provide room for additional features in the future; this document does not define any extension. </ins> The semantics of this structure are simple: any of the listed keys may be used to encrypt the SNI for the associated domain name.  The

Discussion:
Replace "It only affects connection routing, server certificate selection, and client certificate verification." with "It may affect connection routing, server certificate selection, and client certificate verification."
URL It is relative to "This design has no impact on application layer protocol negotiation.", so "only" is more explicit.
This was fixed in and I forgot to close.