jiebi/CodeConvo huggingface dataset:
Change:
6.3.2. The configuration agent generates and distributes a "token key", a <del> "token IV", a key sequence, and a list of QUIC versions the service supports.  It must also inform the service if a NAT lies between the service and the servers. </del> <ins> "token IV", a key sequence, and the information described in common- requirements. </ins> 6.3.3.

Discussion:
Hopefully this will close the gap between what we want Retry Services to do and reality.
It would help the anti-DDoS properties if the Retry Service could receive explicit instructions about which QUIC versions the server might support. This provides a way to deploy new versions without having to upgrade the retry service software or hardware.
Change:
Indicates that x is A bits long Indicates that x can be any length from A to B; A can be omitted <del> to indicate a minimum of zero bits and B can be omitted to </del> <ins> to indicate a minimum of zero bits, and B can be omitted to </ins> indicate no set upper limit; values in this format always end on a byte boundary <del> Indicates that x, with a length described by L, has a fixed value of C </del> <ins> Indicates that x has a fixed value of C; the length of x is described by L, which can use any of the length forms above </ins> <del> Indicates that x is repeated zero or more times (and that each instance is length L) </del> <ins> Indicates that x is repeated zero or more times and that each instance has a length of L </ins> This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte.

Discussion:
For those drafts that are in AUTH48.
This PR makes me happy.9000! Very cool!
Change:
Indicates that x is A bits long Indicates that x can be any length from A to B; A can be omitted <del> to indicate a minimum of zero bits and B can be omitted to </del> <ins> to indicate a minimum of zero bits, and B can be omitted to </ins> indicate no set upper limit; values in this format always end on a byte boundary <del> Indicates that x, with a length described by L, has a fixed value of C </del> <ins> Indicates that x has a fixed value of C; the length of x is described by L, which can use any of the length forms above </ins> <del> Indicates that x is repeated zero or more times (and that each instance is length L) </del> <ins> Indicates that x is repeated zero or more times and that each instance has a length of L </ins> This document uses network byte order (that is, big endian) values. Fields are placed starting from the high-order bits of each byte.

Discussion:
These were not the same, even for the same items, so I fixed that. Checked with: Which shows the three items that are only present in -transport (-invariants doesn't use these).
Change:
Tree hash: The root hash of the above ratchet tree <del> Confirmed transcript hash: 0 </del> <ins> Confirmed transcript hash: the zero-length octet string </ins> <del> Interim transcript hash: 0 </del> <ins> Interim transcript hash: the zero-length octet string </ins> Init secret: a fresh random value of size "KDF.Nh"

Discussion:
While reviewing , I noticed that in one place, we define the initial to be the all-zero vector, and in another, we define it to be the empty octet string. In keeping with the idea of starting chained hashes with the empty octet string, this PR normalizes on the empty octet string for the transcript hashes as well.
Change:
send the same non-zero value in its SETTINGS frame.  If it specifies any other value, or omits SETTINGS_QPACK_MAX_TABLE_CAPACITY from SETTINGS, the encoder must treat this as a connection error of type <del> "HTTP_QPACK_DECODER_STREAM_ERROR". </del> <ins> QPACK_DECODER_STREAM_ERROR. </ins> For HTTP/3 servers and HTTP/3 clients when 0-RTT is not attempted or is rejected, the maximum table capacity is 0 until the encoder

Discussion:
I noticed that the QPACK error codes still started with the HTTPQPACK prefix, while the HTTP document has shifted to H3 as the prefix. I shortened the QPACK prefix to simply "QPACK", though "H3QPACK" could work, too. Along the way, I noticed that backticks were sometimes, but not always, used when referring to the error code names. We haven't been in the HTTP document, so I reconciled them to not. Again, this could go the opposite way. I also noticed that the settings are "SETTINGSQPACK" except in the IANA registration where they're simply "QPACK". I didn't touch those, but am open to feedback on whether that's worth trimming/reconciling.
NAME I don't need your approval, but I kind of do need NAME
Well, you did ask :)
NAME could you review and potentially merge?
Do it. You don't need my approval to do something that is so self-evidently a good idea.QPACK_ prefix WFM
Change:
values, which might be used to link connection attempts; see validate-future. <ins> Clients MUST NOT send NEW_TOKEN frames.  Servers MUST treat receipt of a NEW_TOKEN frame as a connection error of type PROTOCOL_VIOLATION. </ins> 19.8. STREAM frames implicitly create a stream and carry stream data.  The

Discussion:
This doesn't add rationale. It doesn't have to. The rationale isn't high-minded, it's just motivated by a desire to complete this protocol.
Should the server just ignore it, or is is a protocol violation?
I vote for protocol violation.
The spec says nothing...
Yeah, there's no need to vote, this is just an omission. A protocol violation (or similar) is what we should mandate.
Playing devils' advocate: what about p2p apps? The token says, you can call me back from that address, I will accept it. The client is not saying anything untrue.
I'll bite. Yes, a P2P app that used mutual authentication in a way that would allow a former server to associate a token with an attempt to connect to a peer that was previously a client, might be able to use NEW_TOKEN. That's a little outside our remit. I'm going to take this as an editorial change on the understanding that a design issue could be opened to allow the asymmetry. Anyone who is serious about that should also consider the fact that NewSessionTicket in TLS is potentially symmetrical by the same logic. Which suggests that 0-RTT isn't out of the question either.
On p2p there is the potential problem of relating a token to previously stored settings and observables from a previous session. This isn't well defined if the client specifies a new token. So perhaps it is better for each peer to "waste" a single 1-RTT connection the first time in a given direction.
Change:
DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS <del> draft-ietf-detnet-tsn-vpn-over-mpls-00 </del> <ins> draft-ietf-detnet-tsn-vpn-over-mpls-01 </ins> Abstract This document specifies the Deterministic Networking data plane when <del> TSN networks interconnected over an MPLS Packet Switched Networks. </del> <ins> TSN networks are interconnected over a DetNet MPLS Network. </ins> 1. <del> [Editor's note: Introduction to be made specific to TSN over DetNet scenario.  Do we intend to cover both TSN over DetNet IP and TSN over DetNet MPLS?  Or this document is limited to MPLS scenarios?]. </del> <ins> The Time-Sensitive Networking Task Group (TSN TG) within IEEE 802.1 Working Group deals with deterministic services through IEEE 802 networks.  Deterministic Networking (DetNet) defined by IETF is a service that can be offered by a L3 network to DetNet flows.  General background and concepts of DetNet can be found in I-D.ietf-detnet- architecture. </ins> <del> 2. </del> <ins> This document specifies the use of a DetNet MPLS network to interconnect TSN nodes/network segments.  DetNet MPLS data plane is defined in I-D.ietf-detnet-mpls. </ins> <del> [Editor's note: text to be review what is really needed here.]. </del> <ins> 2. </ins> 2.1. <del> This document uses the terminology established in the DetNet architecture I-D.ietf-detnet-architecture, and the reader is assumed to be familiar with that document and its terminology. The following terminology is introduced in this document: A Detnet "forwarding" label that identifies the LSP used to forward a DetNet flow across an MPLS PSN, e.g., a hop-by-hop label used between label switching routers (LSR). A DetNet "service" label that is used between DetNet nodes that implement also the DetNet service sub-layer functions.  An S-Label is also used to identify a DetNet flow at DetNet service sub- layer. A DetNet Control Word (d-CW) is used for sequencing and identifying duplicate packets of a DetNet flow at the DetNet service sub-layer. </del> <ins> This document uses the terminology and concepts established in the DetNet architecture I-D.ietf-detnet-architecture and I-D.ietf-detnet- data-plane-framework, and I-D.ietf-detnet-mpls.  The reader is assumed to be familiar with these documents and their terminology. </ins> 2.2.

Discussion:
Major clean up and simplification as data plane drafts can be referred for MPLS related details. TSN over DetNet MPLS follows the concept of RFC3985. Description focus on Edge Nodes procedures and functions. Text covers the Edge Nodes components: (1) TSN functions (in NSP block); (2) DetNet Service Proxy; and (3) DetNet sub-layers.
Approving from teelcon review
Change:
update mechanism in DTLS 1.2 makes this extension unsuitable for mobility scenarios where correlation must be considered.  Deployments that use DTLS in multi-homing environments and are concerned about <del> this aspects SHOULD refuse to use CIDs in DTLS 1.2 and switch to DTLS 1.3 where a CID update mechanism is provided and sequence number </del> <ins> these aspects SHOULD refuse to use CIDs in DTLS 1.2 and switch to DTLS 1.3 where a CID update mechanism is provided and sequence number </ins> encryption is available. The specification introduces record padding for the CID-enhanced

Discussion:
Tom Petch's review: URL
URL Some editorial quirks s.2 lacks the boiler plate of RFC8174 s.3 I found this unclear until I had understood it all (or perhaps I do not understand it) "URL again, alternately, to use a zero-length CID)." This suggests that a zero length CID is valid in Application Data which later text seems to contradict; otherwise I cannot see what this is saying. " If DTLS peers have negotiated the use of a CIDs using the ClientHello and the ServerHello messages " arguably sending a zero CID and receiving a zero CID is a successful Hello negotiation perhaps " If DTLS peers have negotiated the use of a non-zero CID in at least one direction, using the ClientHello and the ServerHello messages" "The DTLS peers determine whether incoming and outgoing messages need.." seems not to cater for unidirectional CIDs; perhaps "The DTLS peers determine whether incoming or outgoing, or both, messages need.. " s.4 /always recieve CIDs/always receive CIDs/ s.5.1 "the with Encrypt-then-MAC processing described in [RFC7366]." I do not understand why 'with' is needed s.5.2 ditto s.8 /this aspects SHOULD refuse/these aspects SHOULD refuse/ s.10 I would find this clearer as three sections for the three IANA actions new column for ExtensionType new value for ExtensionType new value for ContentType " IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in [RFC5246],.." well no; whatever you think of RFC8447 the name has changed " IANA is requested to allocate an entry to the existing "TLS ExtensionType Values" registry, defined in [RFC5246],.." or, if you are picky (which I am not), IANA is requested to allocate an entry to the existing "TLS "ExtensionType Values" registry, defined in [RFC5246], and renamed by RFC8447 An extra column is added but I cannot see what value should be placed in that column for existing entries. "The tls12_cid ContentType is only applicable to DTLS 1.2." Good information but I struggle to see what IANA will do with it; I see nowhere for it to go. Tom Petch >
Change:
RETIRE_CONNECTION_ID frame (frame-retire-connection-id). An endpoint that receives packets that it cannot process sends a <del> packet in the following layout: </del> <ins> packet in the following layout (see notation): </ins> This design ensures that a stateless reset packet is - to the extent possible - indistinguishable from a regular packet with a short

Discussion:
Fixed Bits (2) = 1, Unpredictable Bits (38..), Stateless Reset Token (128), } When I first met this my reaction was that I was sure it sends a lot more bits on the wire than this, but so far I have not see a packet definition nor a pointer to a packet definition. Please could you clarify what is happening?
This seems like a nit. I guess the only thing being that this is the first time the notation introduced in Section 1.3 is used. And now it is Section 10.3. I'll add a cross reference.
Change:
In link-format serialization, it is expressed between angular brackets, and sometimes called the "href". <del> If there is an anchor attribute present and the link is serialized in RFC6690 link format, this document will require that the link is an absolute reference to avoid the ambiguities outlined in resolution- rules. Otherwise, it can be serialized as a relative URI, and gets resolved against the document's URI. </del> Other target attributes (eg. resource type (rt), interface (if), cor content-type (ct)).  These provide additional information about the target URI.

Discussion:
This responds to a comment from Jim on the use of the term "Origin" in RFC6690 which I had previously missed. Given that the old 6690-style documents are thus a lot less powerful, the text goes from "Submitted documents should be the same in both interpretations, and the RD can use either" to "Submitted documents should be the same, and the RD interprets them 8288 style". A paragraph was added that defines precisely what it means to interpret it 8288 style. Several outdated references to where resolution happens have been removed. The "8288 style interpretation" is called Modernized Link Format; I'd be happy of any better names, but am convinced we need to name it somehow to avoid vaguely describing the same thing again and again.
Change:
QUIC supports connection migration by the client.  If a lower-layer address changes, a QUIC endpoint can still associate packets with an <del> existing connection using the Destination Connection ID field (see </del> <ins> existing connection using the Destination connection ID field (see </ins> also connid) in the QUIC header, unless a zero-length value is used. This supports cases where address information changes, such as NAT rebinding, intentional change of the local interface, or based on an

Discussion:
We've not been capitalizing this in the main spec; so nor should this document. I've fixed those cases that I've touched in my upcoming PR, but it's going to need more work to clean up properly.
Yep, will do that after we merged the PRs. Thanks!
Change:
which specifies the maximum amount of time by which the endpoint will delay sending acknowledgments.  When the endpoint receives an ACK_FREQUENCY frame, it MUST update this maximum time to the value <del> proposed by the peer in the Update Max Ack Delay field. </del> <ins> proposed by the peer in the Request Max Ack Delay field. </ins> 5.

Discussion:
Fixes the remainder of not fixed by
This is good enough. You have a conflict to resolve, but let's merge this.
Change:
server_key_exchange_RESERVED(12), certificate_request(13), server_hello_done_RESERVED(14), certificate_verify(15), client_key_exchange_RESERVED(16), server_configuration(17), <del> finished(20), (255) } HandshakeType; </del> <ins> finished(20), key_update(24), (255) } HandshakeType; </ins> The TLS Handshake Protocol messages are presented below in the order they MUST be sent; sending handshake messages in an unexpected order

Discussion:
Is good.
The counter has a size of (2^64-1).The records are max (2^14 + 2048). So, my bold calculation would come to (2^64-1) / (2^14 + 2048) / 2^40 = 910.22 TiB of data. In Big Data, video streaming and other mass data cases 910TB data can be a limitation. I would like to propose the counter to go to 2^128-1, which would result in a connection that can reach (2^128-1) / (2^14 + 2048) / 2^80 = 1.52 * 10^10 YiB. If byte preservation is an issue, I'm willing to accept 2^96-1 as the counter max, resulting in (2^96-1) / (2^14 + 2048) / 2^80 = 3.55 YiB as maximum connection.
On a 40Gibit line this will take less time than one might expect: URL (let's say 2.5-3 days with overhead).
Why do you divide by (2^14 + 2048)? Shouldn't it be a multiplication with the minimum record size?
I don't see much support for this. Please take it to the list if you want to pursue it.
Consensus at interim: No protocol action needed. Add calculations to security considerations.
Also, consensus is that the math above is wrong.
NAME would you be willing to contribute a PR with a paragraph or two of guidance on the limits for AES-GCM and ChaCha20
Yes. What happened to the Key Update message? I can't find it in the text, and that would be a logical place to mention the limitations as well as in the security considerations section.
URL If you want to just send a PR against that branch that would be fine. Or really, whatever form you want and I can manually merge.
If we ditch renegotiation (), then we will need a way to rekey sessions to extend their lifetime. Nico suggests that sending ChangeCipherSpec and then using an increasing counter to extract new keys (i.e., add a counter to the key expansion PRF input), which would seem to be sufficient.

We have asked David McGrew about the theoretical limits on AES-GCM, we can find the same info for ChaCha+Poly1305. When we have that info, we will make an assessment as to how urgent this is. That will determine how soon we define this mechanism. NAME noted that you don't even have to negotiate to enable rekeying: if you send the rekey message and rekey, your connection will either be rekeyed, or killed by the peer.
Change:
The "RateLimit-Remaining" response field indicates the remaining "quota-units" defined in service-limit associated to the client. <del> The field value is </del> <ins> The field is an Integer Structured Field and its value is </ins> This field MUST NOT occur multiple times and can be sent in a trailer section.

Discussion:
uses structured fields based on NAME preliminary work: thanks!!!referencing the RFC distinguishing sf-item and sf-integer, since sf-integer do not support parameters whereas sf-item does retaining the intermediate syntaxes (quota-policy, quota-units, service-limit, ...)
LGTM, waiting on ack from NAME before merging.
NAME thanks for reviewing! Can we merge?
It's your draft :)
I take it for a YES :D
Since parameters are always allowed in Limit we could define a "registry" and add them subsequently as soon as implementers needs them. They can be used to specify: max throughputs request distribution other policies All data in parameters is informative.
I assume there must be previous art in keeping a registry like this that we can mimic, but I can't think of a good example off the top of my head that wouldn't be using a separate registry or document to manage that. What's your thinking about where to keep this registry?
NAME registries are usually maintained by IANA: we can check with NAME if that's possible...
We can pretty easily define a registry. You include a section in the RFC. See URL You define a table that is the registry, and meanings of the columns, and perhaps populate it with the initial entries. The WG decides some rules, like "X-" is left for experimentation. There must be something written (it can be an internet draft or something else on the net), whether a set of "experts" need to review for comliance and clarity, and so on.
If you'd like, I can make a PR that provides the initial text for this next week.
Yes, that would be great NAME
Can you give me an initial set of fields (even if it's just one or two), and an example, and a pointer to which section in the current draft? thanks.
Hi NAME Thanks for your support! To make best use of your time, I'd wait for to be merged (waiting for mnot's review) so you can PR directly vs . WRT the parameter registry: currently the initial set is just : See: URL Do you have a proposal for the registration policy?
Thanks, I'll wait. I think it should be expert review.

That means that there should be a document describing the parameter, and that the experts can be directed to verify that the documentation is clear and unambiguous, and that there is no significant overlap with the parameters already defined. The other choices are "specification required" and "first-come first-served."
NAME we just merged structured fields in RateLimit Headers!
Thanks for the ping, I saw :) I'll propose a PR soon.
URL I think it needs to be tweaked, since it's just defined as a "quota" registry in that PR. Should it be a ratelimit fields registry?
Change:
understands, and it MUST generate a fresh ServerHello random value, rather than forwarding the endpoint's value. <del> In this scenario, the intermediary is a pair of TLS endpoints for purposes of protocol requirements and security analysis. </del> <ins> Note that TLS's protocol requirements and security analysis only apply to the two connections separately.  Safely deploying a TLS terminator requires additional security considerations which are beyond the scope of this document. </ins> <del> An intermediary which forwards ClientHello parameters it does not </del> <ins> An middlebox which forwards ClientHello parameters it does not </ins> understand MUST NOT process any messages beyond that ClientHello. It MUST forward all subsequent traffic unmodified.  Otherwise, it may fail to interoperate with newer clients and servers. Forwarded ClientHellos may contain advertisements for features not <del> supported by the intermediary, so the response may include future TLS additions the intermediary does not recognize.  These additions MAY change any message beyond the ClientHello arbitrarily.  In particular, the values sent in the ServerHello might change, the ServerHello format might change, and the TLSCiphertext format might change. </del> <ins> supported by the middlebox, so the response may include future TLS additions the middlebox does not recognize.  These additions MAY change any message beyond the ClientHello arbitrarily.  In particular, the values sent in the ServerHello might change, the ServerHello format might change, and the TLSCiphertext format might change. </ins> The design of TLS 1.3 was constrained by widely-deployed non- <del> compliant TLS intermediaries (see middlebox), however it does not relax the invariants.  Those intermediaries continue to be non- compliant. </del> <ins> compliant TLS middleboxes (see middlebox), however it does not relax the invariants.  Those middleboxes continue to be non-compliant. </ins> 10.

Discussion:
There are many sorts of TLS middleboxes (CDN, decrypting proxy, local antivirus, actual attack, etc), with acceptabilities ranging from reasonable to extremely questionable to a terrible idea. (Categorization is left as an exercise to the reader.) They also have very different security considerations. Fundamentally, TLS secures a connection between two endpoints. As such, we have something to say about the endpoint-to-endpoint connections that make up such a system, but we shouldn't imply this section is sufficient, merely necessary. Adjust the text accordingly. I wrote "intermediary" in the original PR, predictively based on PR . Since the spec seems to have settled on "middlebox", align the terminology. (I don't really care what is used, just that it is consistent.)
Ah yeah. Fixed. I used "implementations" for this one because there is an "(also known as ossification)" parenthetical and, in the general case, endpoints can cause ossification too. Even here, I dunno, maybe a sufficiently confused endpoint will do something silly there. :-)
Should the legacysessionid description, which also mentions intermediaries, also be tweaked?Thanks!