jiebi/CodeConvo huggingface dataset:
Change:
round trip.  During recovery, the congestion window remains unchanged irrespective of new losses or increases in the ECN-CE counter. <del> 6.5. </del> <ins> 6.6. </ins> During the handshake, some packet protection keys might not be available when a packet arrives.  In particular, Handshake and 0-RTT

Discussion:
Clarifies a few points and moves the initial window recommendation from the pseudocode to the text. I could take this a bit farther, but I'd like suggestions on what's currently missing in this PR.
LGTM
It starts like this: The next sections below roughly describe the behavior of different phases of congestion control. More concrete pseudo-code is only given in the Appendix later on but it's not linked from the original section. On first reading, I missed the Appendix and felt the text lacking for concrete enough explanations to implement the feature. The question is what to describe where and what the authoritative definitions should be. If you know the NewReno RFC by heart you can probably make the right inferences to figure out how everything should work in comparison but is that how it should be? An alternative (more convenient for the reader / skimmer) approach could be to mention NewReno only in passing and then provide a complete and self-contained description of the algorithms in the congestion control section directly, maybe even inlining the pseudo-code. If that is deemed to verbose and would bore readers that know enough about those algorithms already, it would be good to provide some guidance how to read the algorithm and what the assumptions are in the introductory paragraph about congestion control.
The intent is that the text is complete without reading the referenced RFCs or pseudocode, so I think this section needs more text and possibly some inlined pseudo-code.
Hi NAME I wrote which fixes some obvious errors I found, but I think more could be done. Can you take a look and tell me what other points you'd like added or moved up from the pseudocode?
Looks good! Thanks!
Change:
attacks were practical.  This document updates RFC5246 in such a way that MD5 and SHA-1 MUST NOT be used for digital signatures.  However, this document does not deprecate SHA-1 in HMAC for record protection. <del> Note that the CABF has also deprecated use of SHA-1 CABF. </del> <ins> Note that the CABF has also deprecated use of SHA-1 for use in certificate signatures CABF. </ins> 1.1.

Discussion:
We might say that the CABF action was deprecation for use in certificate signatures (not that CABF is likely to be concerned about other uses of SHA1, of course). I don't see much harm in adding "illegal_parameter" to the list of allowed alerts here, as Hubert proposed.  It's otherwise the natural thing to do if an algorithm is received in CertificateVerify that was not advertised in the signature algorithms extension. Sean's proposal at https://mailarchive.ietf.org/arch/msg/tls/rSbXvNPhmr27z0HOBzwv6x0j1mI/ (which makes "illegal_parameter" the only alert) seems like it ought to work.
Change:
Ordered: when this is false, this disables the requirement of in- order-delivery for protocols that support configurable ordering. <ins> When the protocol stack does not support configurable ordering, this property may be ignored. </ins> Safely Replayable: when this is true, this means that the Message can be used by mechanisms that might transfer it multiple times -

Discussion:
Section 5.1.2: "the implementation should hold off on processing Messages until the batch is complete" assumes that there is indeed a context-switch penalty. Batch semantics are only for hints to the implementation/protocol stack, and this advice only applies when that hint allows the stack to reduce context switch penalty. Correct? (If so, this should be noted explicitly)
Actually 5.1.3. This reads odd to me, I'd expected myself more like: "When this is used, the implementation can defer the processing Messages until the batch is complete." (eliminating "off on", also from this sentence?)
Agreed, I think your text reads better NAME should it be "... defer the processing of Messages ..." though? I think it also solves the question from NAME as it is now expressed as an opportunity for the implementation.
I believe these are all editorial. First, this list needs some front matter: "protocols should implement each of the following Message Properties on send as follows" or similar. "Ordered" should state that protocols that do not support configurable ordering may ignore the property. "Final" should note that it is not mandatory to close the connection after a Final message. "Corruption Protection Length" should note that it can be ignored basically everywhere but UDP-Lite. One open question: is it an error to send a Message after a Final message, and does the protocol implementation need to handle this itself?
... "Corruption Protection Length" should note that it can be ignored basically everywhere but UDP-Lite. ... In protocols such as UDP-Lite, various tunnels would, DCCP allows, etc.
I think it should be an error to send a Message after a Final message and the implementation of the transport services system should handle it. If it is not an error, then it will fail sometimes and sometimes not depending on if the connection is closed or not, that seems less useful to me.
Change:
The term Origin is to be interpreted as described in Section 7 of RFC6454. <del> The "delay-seconds" rule is defined in Section 10.2.3 of SEMANTICS. </del> <ins> This specification uses Structured Fields SF to specify syntax. The terms sf-list, sf-item, sf-string, sf-token, sf-integer, bare- item and key refer to the structured types defined therein. </ins> 2.

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:
the captive portal web application, and (c) legacy devices must continue to be supported. <ins> If User Equipment supports the Captive Portal API, it MUST validate API server TLS certificate (see RFC2818).  An Enforcement device SHOULD allow access to any services that User Equipment could need to contact to perform certificate validation, such as OCSP responders, CRLs, and NTP servers; see Section 4.1 of I-D.ietf-capport-api for more information.  If certificate validation fails, User Equipment MUST NOT proceed with any of the behavior described above. </ins> 2.2. Here we discuss candidate mechanisms for provisioning the User

Discussion:
I'll merge this later today when I go over it and submit the new draft then.
NAME Done.
Thanks! IESG here we come.
The CAPPORT API document explains some requirements on deployments to allow certificate validation of servers, specifically in Section 4.1.1. Server Authentication. Last call comments noted that the architecture should have notes that such provisions are needed.
This appears to be the last PR active on the respository. Can we have an updated version of the draft please?Thanks!
Change:
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 <del> send.  An endpoint MAY send up to two ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single packet loss. </del> <ins> send.  An endpoint MAY send up to two full-sized datagrams containing ack-eliciting packets, to avoid an expensive consecutive PTO expiration due to a single lost datagram. </ins> 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

Discussion:
Now that the PTO retransmits Initial and Handshake data, it's possible and likely desirable to bundle multiple QUIC packets in a single datagram. This change makes it clear that is allowed.
nits, but lgtm
Change:
If an endpoint has cause to expect that IP packets with an ECT codepoint might be dropped by a faulty network element, the endpoint could set an ECT codepoint for only the first ten outgoing packets on <del> a path, or for a period of three RTTs.  If all packets marked with non-zero ECN codepoints are subsequently lost, it can disable marking on the assumption that the marking causes in loss. </del> <ins> a path, or for a period of three PTOs (see Section 6.2 of QUIC- RECOVERY).  If all packets marked with non-zero ECN codepoints are subsequently lost, it can disable marking on the assumption that the marking causes in loss. </ins> An endpoint thus attempts to use ECN and validates this for each new connection, when switching to a server's preferred address, and on

Discussion:
I tried to just make a note here saying "if you don't send many packets, you won't send many packets", but then decided that 3PTO is probably more sensible. As it is, 3 RTT is the value that the PTO is initialized to (validation almost always happens on a new path). And the loss of a single packet just doesn't cut it. Even 3 packets (the first packet, plus two on PTO, assuming two are sent on PTO) is not that strong, but at least it isn't insanely tight.
URL and URL describe ECN validation and they say : dropped by a faulty network element, an endpoint could set the ECT(0) codepoint for only the first ten outgoing packets on a path, or for a period of three RTTs, whichever occurs first. Initial PTO timeout is also 3RTT. If client does not get ACK for its first flight Initial, after 3RTT later, it resends Initial without ECT set because client is now in "UNKNOWN" state. If the first client Initial is really lost, ECN validation fails. It seems to me that it would be better to lengthen timeout or ensure enough packets are sent not limited by the timeout?
It seems like this particular problem was introduced by reducing the initial RTT from 500ms to 333ms (in ).
We use 3*PTO everywhere else, so suggesting it here makes sense to me.
Change:
3. QUIC version 2 endpoints MUST implement the QUIC version 1 <del> specification as described in QUIC, QUIC-TLS, and RFC9002.  However, the following differences apply in version 2. </del> <ins> specification as described in QUIC, QUIC-TLS, and QUIC-LOSSRECOVERY. However, the following differences apply in version 2. </ins> 3.1. The Version field of long headers is 0x709a50c4. <ins> This version number will not change in subsequent versions of this draft, unless there is a behavior change that breaks compatibility. </ins> 3.2. All version 2 long header packet types are different.  The Type field

Discussion:
, ,
It would be nice to have the references use a consistent format (e.g. all having a name instead of the RFC number for some)
OK, I've only left document number references where the subject is indicated beforehand, e.g. Alt-Svc {{?RFC7838}}
fixed by
Draft currently states: This repeats the QUIC VN document, should we remove it?
Yes, good catch.
fixed by
The draft currently says: Could we add a note to be removed by the RFC editor that clarifies whether or not we're going to change the version number before publication or not?
fixed by
The abstract currently contains: I'm pretty sure the second one won't be included, but there's no note saying so. I don't know if the first one is meant to stay. Can we add a note to make this explicit? Markdown can do it for you for the second one.
Actually the second note can be removed entirely because it repeats the paragraph that's autogenerated.
Thanks!
Change:
the aggregator ("0x02" for the leader and "0x03" for the helper). The "OpenBase()" function is as specified in HPKE for the ciphersuite indicated by the HPKE configuration.  If the leader supports multiple <del> HPKE configurations, it can use trial decryption with each configuration.  If decryption fails, the aggregator marks the report share as invalid with the error "hpke_decrypt_error".  Otherwise, the aggregator outputs the resulting PlaintextInputShare "plaintext_input_share". </del> <ins> HPKE configurations with non-distinct configuration identifiers, it can use trial decryption with each configuration.  If decryption fails, the aggregator marks the report share as invalid with the error "hpke_decrypt_error".  Otherwise, the aggregator outputs the resulting PlaintextInputShare "plaintext_input_share". </ins> 4.4.1.4.

Discussion:
The server only supplies one config, so what happens if the server would support X22519 and P-256? We can fix this by having the server supply multiple configs.
This is probably a good idea. We could just change the payload of the response to to a sequence of messages rather than one.
As mentioned in URL, it might be useful to allow the client to advertise which algorithms it supports. This would increase the likelihood of successfully negotiating an a HPKE suite that both parties support.
NAME should we try to tackle this in DAP-03?
I'm game. One minor editorial nit.
Change:
Errors that result in the connection being unusable, such as an obvious violation of protocol semantics or corruption of state that affects an entire connection, MUST be signaled using a <del> CONNECTION_CLOSE frame (frame-connection-close).  An endpoint MAY close the connection in this manner even if the error only affects a single stream. </del> <ins> CONNECTION_CLOSE frame (frame-connection-close). </ins> Application-specific protocol errors are signaled using the CONNECTION_CLOSE frame with a frame type of 0x1d.  Errors that are

Discussion:
The spec says: First of all, I have no idea what a "corruption of state" is supposed to be. More importantly, the second sentence seems to suggest that if an error only affects a single stream, it might not be required to send a connection-level error. I'm thinking of a stream-level flow control violation.
The challenge here is that the transport doesn't define how streams can be used by application layer protocols, but seems to want to strongly encourage how an application uses error codes. An example of "corruption of state" is something like a QPACK error that renders the HTTP/3 connection unusable because the QPACK state cannot be assured. In contrast, an application might treat receiving a header with an uppercase field name as a stream error that otherwise would not affect the rest of the H3 connection.
Anything remain to be done here?
It seems like NAME is interpreting this sentence as only applying to application protocol errors. If that's the intention, we should make that clear:
It's not exclusive to the application. Another example of corrupt state at the transport layer is CRYPTOBUFFEREXCEEDED -- you had to drop some bytes, so now your TLS handshake state is corrupted. As to the second piece, I think you're reading that backward. A stream error MAY always be promoted to a connection error if the implementation decides it's severe enough; it doesn't say anything about deciding to downplay errors if they're localized. If an error is defined to be a connection error, it's a connection error. If it's defined to be a stream error, however, you're always allowed to decide it's the last straw and walk away.
QUIC transport does not have stream-level errors, though applications can. As such, the last sentence references a circumstance that does not exist in the transport draft. So the best solution seems to be to remove the last sentence.
NAME : to your two points: "corruption of state that affects an entire connection" is clear that if the connection state is affected then it should result in a connection error agree that the second sentence seems unnecessary entirely, since stream-level errors are always treated as connection errors within the transport.
Change:
2.4. <ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. </ins> The following terms are used across the documents specifying the WebRTC suite, in the specific meanings given here.  Not all terms are used in this document.  Other terms are used in their commonly used

Discussion:
ID-nits turned up that the 2119 language section was missing. I added it as a new section, but could also see it being in the existing section 2.
I think I prefer it in section 2.4, with the rest of terminology.
Change:
A server operates both the Oblivious Gateway Resource and the Target Resource <ins> Connections between the client, Oblvious Relay Resource, and Oblivious Gateway Resource MUST use HTTPS in order to provide unlinkability in the presence of a network observer.  The scheme of the encapsulated request detemrines what is used between the Oblivious Gateway and Target Resources, though using HTTPS is RECOMMENDED; see server-responsibilities. </ins> To achieve the stated privacy goals, the Oblivious Relay Resource cannot be operated by the same entity as the Oblivious Gateway Resource.  However, colocation of the Oblivious Gateway Resource and

Discussion:
The text noted in was correct, but we didn't have a single place where we outlined this as a direct requirement. The day where HTTP presupposes TLS has come for some, but not all of us. Until then, we can be more careful.
The document uses the term TLS connection(s) in four places: My understanding is that oHTTP is not restricted to versions of HTTP that use TLS. The obvious one being QUIC (arguably TLS-like) but presumably some future protocol that satisfies the security properties of HTTPS could be used and oHTTP wouldn't really care. Now, perhaps I'm mistaken and oHTTP does mandate TLS. If so, perhaps I'm overlooking it. URL states many requirements but not the use of HTTPS. That seems implicit via URL However, that seems in conflict with URL, which says In summary, there seems to be some opportunity to tighten up the consistency of expectations about the connections underpinning oHTTP interations.
Change:
A server conveys a preferred address by including the preferred_address transport parameter in the TLS handshake. <del> Once the handshake is finished, the client SHOULD initiate path validation (see migrate-validate) of the server's preferred address using the connection ID provided in the preferred_address transport parameter. </del> <ins> Servers MAY communicate a preferred address of each address family (IPv4 and IPv6) to allow clients to pick the one most suited to their network attachment. Once the handshake is finished, the client SHOULD select one of the two server's preferred addresses and initiate path validation (see migrate-validate) of that address using the connection ID provided in the preferred_address transport parameter. </ins> If path validation succeeds, the client SHOULD immediately begin sending all future packets to the new server address using the new

Discussion:
This change allows servers to send a preferred address of each address family. The previous definition of preferred_address only allowed sending one address family, and this had the disadvantage of picking the non-deterministic address family used by the Initial if the client is performing Happy Eyeballs. Clients may now use the best address family based on their network attachment.
NAME I went with this approach to minimize changes from the current design. Having a list that allows different ports and future versions of IP are fine by me, but there seemed to be more pushback when that was proposed in . As long as we have a way of communicating one IPv4 address and one IPv6 address I'm happy.
We could allow multiple PreferredAddress TPs and avoid the zero-length address problem.
NAME Thank you for the clarification. I think I'm fine with that. NAME The PreferredAddress structure includes Connection ID and Stateless Reset Token. I think we should avoid requiring the server to send them twice when it is constrained by the 3-packet rule.
I've simplified the wire-format using NAME suggestion with separate port numbers
NAME I think migration and preferred address are separate parts of the protocol. The goal of this PR is to improve preferred address. It allows the client to pick the address family it transfers to right after the handshake. If the server only provides you with a preferred address family you don't have access to, you can simply ignore it - and that's not new from this PR. I've slightly tweaked the text to clarify how clients respond to preferred_address. Does this address your concerns?
I'm good with this PR. NAME -- can you see if your concern is addressed?
NAME is there anything left for me to do so this can get merged in?
You could wait until I had time to check it, that's all.
After reading my text, I am not entirely happy with it, but I lack a better suggestion.Still LG
Change:
but MAY be held constant for successive connections to the same server in the same session. <del> Set the "config_id" field to a randomly-generated string of "Nh" bytes, where "Nh" is the output length of the "Extract" function of the KDF associated with the chosen cipher suite.  (The KDF API is specified in I-D.irtf-cfrg-hpke.) </del> <ins> Set the "config_id" field to a randomly-generated 8-byte string. </ins> Set the "enc" field to a randomly-generated valid encapsulated public key output by the HPKE KEM.

Discussion:
This doesn't bind anything, so no sense wasting bytes. (Note: this is orthogonal to , but it makes more sense with that PR.)
I guess this makes the text in a little odd because "Compare ClientECH.config_id against identifiers of known ECHConfigs and select the one that matches, if any, as a candidate.", is a little less clear. If we want to do this, it maybe should say "and select any that match", even though there'll really just be one match.
(Rebased and made the text talk about multiple potential matches.)
This matches the acceptance signal length, and we've already accepted that probability of collision.
I agree this is fine.