jiebi/CodeConvo huggingface dataset:
Change:
1. <ins> QUIC is a connection-oriented protocol between two endpoints.  Those endpoints exchange UDP datagrams.  These UDP datagrams contain QUIC packets.  QUIC endpoints use QUIC packets to establish a QUIC connection, which is shared protocol state between those endpoints. 2. </ins> In addition to providing secure, multiplexed transport, QUIC QUIC- <del> TRANSPORT includes the ability to negotiate a version.  This allows </del> <ins> TRANSPORT allows for the option to negotiate a version.  This allows </ins> the protocol to change over time in response to new requirements. <del> Many characteristics of the protocol will change between versions. </del> <ins> Many characteristics of the protocol could change between versions. </ins> This document describes the subset of QUIC that is intended to remain stable as new versions are developed and deployed.  All of these

Discussion:
Gorry thought that it might be worth saying what QUIC is first. I agree. Tiny tweaks to the intro to allow for the change. Including a new title.
Issue raised by NAME via :
I like it. I'll see what that looks like. I have read Version-Independent Properties of QUIC (-30) in the WGLC and think this is ready, I found 3 editorial comments that might need consideration after the WGLC: (i) I suggest the introduction for this spec starts abruptly. Is it worth considering one sentence top explain what QUIC is, in case someone read this document first? - One possible solution could be to move the text in section 3 to section 1? (To me, the section 3 text does not need to come after the Section 2 definitions.) (ii) Does this read better with /for/ moved within the sentence? OLD:/At the endpoint, the connection ID is used to identify which QUIC connection the packet is intended for./ NEW:/At the endpoint, the connection ID is used to identify the QUIC connection for which the packet is intended./ (iii) I see the desire to emphasise the “NOT”, but I query if this is correct usage of a RFC2119 keyword in Appendix A?: /The following statements are NOT guaranteed to be true for every QUIC version:/ Best wishes, Gorry
Change:
input share uploaded by the client.  At the end of the computation, each aggregator is in posession of either an "output share" that is ready to be aggregated or an indication that a valid output share <del> could not be recovered. </del> <ins> could not be computed. </ins> To facilitiate this computation, the input shares generated by the client include information used by the aggregators during aggregation <del> in order to validate their recovered output shares.  For example, </del> <ins> in order to validate their corresponding output shares.  For example, </ins> "prio3" includes a distributed zero-knowledge proof of the input's validity BBCGGI19 which the aggregators can jointly verify and reject the report if it cannot be verified.  However, they do not learn

Discussion:
What PPM calls an "output share" is called an "aggregate share" in the VDAF draft. Furthermore, in the VDAF draft, an "output share" is what an aggregator recovers from running the MPC with its peers. This change fixes this ambiguity without changing the PPM protocol itself (modulo changing the info string for HPKE).
Squashed.
Thanks fellas!
Generally looks good. I would change the "agg" in the label if you can as it is confusing.LGTM, modulo typos
Change:
21.7. <ins> QUIC and TLS both contain messages that have legitimate uses in some contexts, but that can be abused to cause a peer to expend processing resources without having any observable impact on the state of the connection. Messages can also be used to change and revert state in small or inconsequential ways, such as by sending small increments to flow control limits. If processing costs are disproportionately large in comparison to bandwidth consumption or effect on state, then this could allow a malicious peer to exhaust processing capacity. While there are legitimate uses for all messages, implementations SHOULD track cost of processing relative to progress and treat excessive quantities of any non-productive packets as indicative of an attack.  Endpoints MAY respond to this condition with a connection error, or by dropping packets. 21.8. </ins> An on-path attacker could manipulate the value of ECN codepoints in the IP header to influence the sender's rate.  RFC3168 discusses manipulations and their effects in more detail.

Discussion:
Issue observes that this text mentions HTTP/2, which isn't necessary. In reviewing it, I noticed that this talks about messages that do nothing, but not really about messages that do little (or that can be reversed to have net zero effect). So I expanded the text a little.
Thanks for improving the section's clarity. As a follow up question, when implementations decide that excessive packets is an attack, is there a recommended actionable (eg. sending reset, dropping the connection, do nothing) or would that be up for implementer's discretion?
Maybe this needs to be stated explicitly, but there is no point in continuing discussion with an attacker. So while it might be considered polite to send a connection error, it is also acceptable to just drop any further incoming packets. I'll add that here.
Under the section Peer Denial of Service of TLS draft, a referenced was made to HTTP/2. URL I was wonder if this is in fact referring to HTTP/3 or HTTP/2. Also curious why the section is labelled
That mention of h2 was a mistake. I've made a few changes after reviewing this. (The thing is a joke.)
Change:
eliciting packet.  This recommendation is in keeping with standard practice for TCP RFC5681. <del> A receiver's delayed acknowledgment timer SHOULD NOT exceed the current RTT estimate or the value it indicates in the "max_ack_delay" transport parameter.  This ensures an acknowledgment is sent at least once per RTT when packets needing acknowledgement are received.  The sender can use the receiver's "max_ack_delay" value in determining timeouts for timer-based retransmission. </del> <ins> An endpoint MUST NOT excessively delay acknowledgements of ack- eliciting packets.  An endpoint commits to a maximum delay using the max_ack_delay transport parameter; see transport-parameter- definitions.  max_ack_delay declares an explicit contract: an endpoint promises to never delay acknowledgments of an ack-eliciting packet by more than the indicated value.  If it does, any excess accrues to the RTT estimate and could result in delayed retransmissions from the peer.  For Initial and Handshake packets, a max_ack_delay of 0 is used.  The sender uses the receiver's "max_ack_delay" value in determining timeouts for timer-based retransmission, as detailed in Section 5.2.1 of QUIC-RECOVERY. </ins> In order to assist loss detection at the sender, an endpoint SHOULD send an ACK frame immediately on receiving an ack-eliciting packet

Discussion:
Also removes obsolete text about acknowledging CRYPTO frames quickly, now that Initial and Handshake packet spaces have a maxackdelay of 0.
Sorry I'm late here but I think it would still be good to mention that congestion control usually is supposed to work on a RTT granularity and if you send less ACKs than one per RTT that can have an impact on cc. I don't think this has to be a normative requirement given you have normative requirements on maxackdelay and a reasonable default value but it would still be good to mention this dependency as cc is done on sender and ACKing on receiver and therefore it might not always that obvious.
The spec gives no reason (that I can see) as to why an ACK frame must be sent at least once per round trip (assuming there are ack-eliciting packets to acknowledge), effectively overwriting the ACK delay logic when the RTT is very small. If the RTT is smaller than the platform's timer granularity, this isn't really even possible. I propose to remove this requirement. If the WG instead feels that we should keep this requirement, then there should be a reasoning for it; and probably an update to the PTO calculation as well.
As I commented on the PR that this came up in, given we have an explicit maxackdelay that's now communicated, removing the 1 ACK per RTT requirement seems wise. TCP has no such recommendation and I'm unaware of any indications or proposals that it should have such a property.
NAME point that the RTT can be smaller than the platform's granularity is a good one. I agree that this text ought to be removed.
This is changing text in a SHOULD statement, so I believe it should be marked as design.
LGTM
Change:
(ClientHello.random).  The initial 64-byte pad clears that prefix along with the server-controlled ServerHello.random. <del> The context string for a server signature is "TLS 1.3, server CertificateVerify" and for a client signature is "TLS 1.3, client CertificateVerify".  It is used to provide separation between signatures made in different contexts, helping against potential cross-protocol attacks. </del> <ins> The context string for a server signature is: "TLS 1.3, server CertificateVerify" The context string for a client signature is: "TLS 1.3, client CertificateVerify" It is used to provide separation between signatures made in different contexts, helping against potential cross-protocol attacks. </ins> For example, if the transcript hash was 32 bytes of 01 (this length would make sense for SHA-256), the content covered by the digital

Discussion:
NAME I did not: 1) add the "Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS " reference because it's already in the [JSS15] reference that's later in the sentence. 2) I also didn't made [AEAD-LIMITS] normative.
Change:
where the signaled candidate is discarded as redundant according to Section 5.1.3 of RFC8445. <del> 5.2. </del> <ins> 6.2. </ins> When sending data to a TURN RFC5766 server, the sending client tells the server the destination IP and port for the data.  This means that

Discussion:
Added new section on latency, as requested by NAME PTAL - will plan to merge at EOD if there are no outstanding comments.
Include experimental results, if we have them
LGTM
Change:
The client initiates a QUIC connection by sending a first flight of QUIC packets with a long header to the server INV.  We'll refer to the version of those packets as the "original version".  The client's <del> first flight includes handshake version information (see hs-vers- info) which will be used to optionally enable compatible version negotation (see compat-vn), and to prevent version downgrade attacks (see downgrade). </del> <ins> first flight includes Version Information (see vers-info) which will be used to optionally enable compatible version negotation (see compat-vn), and to prevent version downgrade attacks (see downgrade). </ins> Upon receiving this first flight, the server verifies whether it knows how to parse first flights from the original version.  If it

Discussion:
This PR simplifies the document's design. The new simplified design was by NAME . It removes the indication of server versions that everyone seemed to think was useless, but apart from that has very similar properties to the previous design. One important difference is that it is now the client's responsibility to detect VN-packet-based downgrade attacks instead of the server's. .
In , NAME points out that the backticks don't render nicely in the TXT version, so let's remove them
In , NAME mentioned that having the client communicate preference ordering between compatible versions isn't absolutely necessary. This issue tracks whether we want to keep this ordering or not.
During the IETF QUIC WG meeting there was (weak-ish) consensus that this useful to keep.
The strongest argument against this was that it doesn't give the server a full ordering, because it doesn't tell the server where the offered version falls in the preference list. There's a possible answer to that, which is that the client should only offer compatible versions which are more preferred than the currently offered version. However, we should explicitly state that the server makes the actual decision and MAY factor client preferences into that. I suspect most won't.
NAME that's incorrect. The offered version is present in the list.
Ah, thanks for correcting me. Then we're spending bytes to repeat the version number, which we don't expect servers will typically use. Not the end of the world either way.
Consensus established. Closing this issue with no action.
Almost there, but I think we need clarity on the clients verification-and-drop requirements.
Change:
cryptographic context and then encrypts using the outer cryptographic context.  The processes is as follows: <ins> When using EKT I-D.ietf-perc-srtp-ekt-diet, the EKT Field comes after the SRTP packet exactly like using EKT with any other SRTP transform. </ins> 5.2. The Media Distributor does not have a notion of outer or inner

Discussion:
You can't think of this as SRTP tunneled inside of SRTP. It's not. It is SRTP done once with a crypto transform called "double" and with a single key. Double has the weird property that if you know half the key, it ends up only decrypting half the the data for you. The endpoints know the full key, the MDD only half the key, and the both the endpoints and the MMD have to do double.
Make sure specs are clear on this
wondering where size ends up
Which size?
That aligns with what you said you preferred. It's certainly easier to explain in words here. But, it will be more challenging for MDDs to explain. Since we are using the same cipher and the ciphertext will have a constant size, we can do in-place authenticated encryption and not destroy the EKT field in the process. So performance will not be affected on the middle box. But, we need to explain this somewhere for the media distributor. Maybe the right place to explain that is when we also show an example of the packet format. I can see that expanding to be processing rules for endpoints and the media distributor.
Change:
Network management is not a one-size-fits-all endeavour: practices considered necessary or even mandatory within enterprise networks with certain compliance requirements, for example, would be <del> impermissible on other networks without those requirements.  This document therefore does not make any specific recommendations as to which practices should or should not be applied; for each practice, it describes what is and is not possible with the QUIC transport protocol as defined. </del> <ins> impermissible on other networks without those requirements.  The presence of a particular practice in this document should therefore not be construed as a recommendation to apply it.  For each practice, this document describes what is and is not possible with the QUIC transport protocol as defined. </ins> This document focuses solely on network management practices that observe traffic on the wire.  Replacement of troubleshooting based on

Discussion:
Addresses OPSDIR comment discussion.
hi NAME -- does this better clarify language about recommendations in the introduction? PTAL, thanks!!
Looks good to me.
I'm not sure if this is actually fully true. We use the terms "recommended" or "recommendation" multiple times in this document and I don't see a reason to remove it. I think these are the things that the quic group recommends, of course if anybody follows those recommendations is another questions.
so I'm not removing the recommendations elsewhere (modulo ), just changing the language here to say "don't think we think it's a good idea for you just because we wrote it in general), which I think is indeed more true than what was here before...
Change:
12.4.1. The basic mathematics for Elliptic Curve Diffie-Hellman can be found <del> in RFC6090.  Two new curves have been defined in I-D.irtf-cfrg- curves. </del> <ins> in RFC6090. </ins> ECDH is parameterized by the following:

Discussion:
The CFRG EC algorithms are currently too far in the future to keep. Remove the ad put in the to be done later document.
Change:
state include the Client's geographic region and whether the Client has a valid application-layer account. <del> Attesters may support different types of attestation procedures.  A type of attestation procedure is also referred as an attestation format. </del> <ins> Attesters may support different types of attestation procedures. </ins> <del> In general, each attestation format has different security </del> <ins> In general, each attestation procedure has different security </ins> properties.  For example, attesting to having a valid account is different from attesting to running on trusted hardware.  In general, <del> minimizing the set of attestation formats helps minimize the amount of information leaked through a token. </del> <ins> minimizing the set of supported attestation procedures helps minimize the amount of information leaked through a token. </ins> <del> Each attestation format also has an impact on the overall system </del> <ins> Each attestation procedure also has an impact on the overall system </ins> privacy.  Requiring a conjunction of attestation types could decrease the overall anonymity set size.  For example, the number of Clients that have solved a CAPTCHA in the past day, that have a valid

Discussion:
From Section 3.2.1: This is a pretty wild equivalence. I stumbled badly on this one. It's very much like saying "in this context a verb is sometimes referred to as a noun". Is the goal here to say that "there is a attestation process by which the Attester determines whether a Client meets the requirements for issuance; if successful, the Attester captures this information using an attestation format" ? That seems to be the case, but that's not what this says.
I think we might just drop the equivalence to avoid confusion, but in the interest of transparency, here's where it came from. Consider the two following types of attestation procedures: Attestation based on , where the client and attester use this mechanism to prove that the client's device is valid. Attestation based on , perhaps where the signature is computed in some client enclave, where the client authenticates its token request with such a ring signature. In (1), attestation is some procedure that takes place between client and attester, whereas in (2) attestation is sort of non-interactive mechanism for producing an attestation format or proof of sorts. Since we don't specify the details of attestation, the text was written in a way to be maximally accommodating to these types of things. In any case, I think it's probably fine to just treat attestation as a procedure_, be it interactive or non-interactive or whatever, and that procedure has certain properties associated with it. I'll propose text.
Change:
A server MAY return "RateLimit" response fields independently of the response status code.  This includes throttled responses. <ins> This document does not mandate any correlation between the "RateLimit" values and the returned status code. </ins> Servers should be careful in returning "RateLimit" fields in redirection responses (eg. 3xx status codes) because a low "RateLimit-Remaining" value could limit the client from issuing

Discussion:
clarifies that status code is independent from the values of RL fields the example reflects the above statement.
Would there be scope to define standards for the 429 response or would that be more relevant to RFC6585. Should RFC6585 be extended to mention this RFC ?
This I-D is independent from the status code of the response, so I'd say there are no normative relations between this doc and RFC6585. This is by design: we just want to standardize response fields without explicitly define a "ratelimit protocol". Instead, we want implementers to be free to implement their throttling strategies.
See. URL
I noticed in the example in You return a 200 response with RateLimit-Remaining: 0 . It is not completely clear in the document that a remaining value of 0 should be returned to the caller as a success when the quota has been used exactly. In you present a case where the cost of a more expensive call deducts two from the remaining pool and results in a 429. I am conflicted as to whether it should be a server decision whether the call is respected or whether the spec should strictly define this behaviour. I lean toward the former but some feel guidance is needed.
we should clarify that this is a server choice. The spec does not mandate any correlation between the RL values and the returned status code . The server can always decide to serve requests even when quota is over. We need to clarify this both in the text and in the example.
That is something that was not clear to me when reading the spec. The assumption being that when is exhausted, a user will be rate limited and an error response (429) will be issued. It would seem as per and that there is no specific intention to require a server implementation to deny further responses, but rather in some cases the expectation would be for the client to gracefully comply and back off. My feeling is though that this use case would be the exception rather than the rule, with most implementations opting to deny further requests. Should we not at least provide guidance that a 429 response should be issued in this scenario ?