jiebi/CodeConvo huggingface dataset:
Change:
We don't need to change the frame type on each draft version, but I figured that it'd be safer.

Discussion:
using an ACK_FREQUENCY frame, shown below: Following the common frame format described in Section 12.4 of QUIC- <del> TRANSPORT, ACK_FREQUENCY frames have a type of 0xAF, and contain the </del> <ins> TRANSPORT, ACK_FREQUENCY frames have a type of 0xaf, and contain the </ins> following fields: A variable-length integer representing the sequence number
Change:
Part of We still need to decide whether to change 'Update Max Ack Delay' to 'Max Ack Delay'.

Discussion:
On the first received ACK_FREQUENCY frame in a connection, an endpoint MUST immediately record all values from the frame.  The sequence number of the frame is recorded as the largest seen sequence <del> number.  The new ACK-eliciting Threshold and Update Max Ack Delay </del> <ins> number.  The new Ack-Eliciting Threshold and Update Max Ack Delay </ins> values MUST be immediately used for delaying acknowledgements; see sending.

acknowledgements as specified in Section 13.2.1 of QUIC-TRANSPORT. On receiving an ACK_FREQUENCY frame and updating its recorded <del> "max_ack_delay" and "ACK-eliciting threshold" values (multiple- </del> <ins> "max_ack_delay" and "Ack-Eliciting Threshold" values (multiple- </ins> frames), the endpoint MUST send an acknowledgement when one of the following conditions are met: Since the last acknowledgement was sent, the number of received ack-eliciting packets is greater than or equal to the recorded <del> "ACK-eliciting threshold". </del> <ins> "Ack-Eliciting Threshold". </ins> Since the last acknowledgement was sent, "max_ack_delay" amount of time has passed.

"Ignore Order" value of "true" (0x01), the endpoint does not make this exception.  That is, the endpoint MUST NOT send an immediate acknowledgement in response to packets received out of order, and <del> instead continues to use the peer's "ACK-eliciting threshold" and </del> <ins> instead continues to use the peer's "Ack-Eliciting Threshold" and </ins> "max_ack_delay" thresholds for sending acknowledgements. 6.2.
Change:
Fixes the remainder of not fixed by
This is good enough. You have a conflict to resolve, but let's merge this.

Discussion:
maximum value it can represent, the endpoint MUST use the largest representable value instead. <del> A variable-length integer representing an update to the peer's "max_ack_delay" transport parameter (Section 18.2 of QUIC- TRANSPORT).  The value of this field is in microseconds.  Any value larger than 16,383,000 microseconds is invalid, as specified for the "max_ack_delay" transport parameter.  Any value smaller than the "min_ack_delay" advertised by this endpoint is invalid. Receipt of an invalid value MUST be treated as a connection error of type PROTOCOL_VIOLATION. </del> <ins> A variable-length integer representing the value to which the endpoint requests the peer update its "max_ack_delay" (Section 18.2 of QUIC-TRANSPORT).  The value of this field is in microseconds, unlike the 'max_ack_delay' transport parameter, which is in milliseconds.  Sending a value smaller than the "min_ack_delay" advertised by the peer is invalid.  Receipt of an invalid value MUST be treated as a connection error of type PROTOCOL_VIOLATION. </ins> An 8-bit field representing a boolean truth value.  This field MUST have the value 0x00 (representing "false") or 0x01

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.

On the first received ACK_FREQUENCY frame in a connection, an endpoint MUST immediately record all values from the frame.  The sequence number of the frame is recorded as the largest seen sequence <del> number.  The new Ack-Eliciting Threshold and Update Max Ack Delay </del> <ins> number.  The new Ack-Eliciting Threshold and Request Max Ack Delay </ins> values MUST be immediately used for delaying acknowledgements; see sending.
Change:
Does it make sense to specify any maximum values for any of the ACK frequency frame fields, such as for Packet Tolerance? Does a value of 4 billion make sense? Can I use a in my implementation to store this locally? Is there any expectation around the sizes of these fields? If there is no explicit max, what if I implicitly apply one? I'm working on implementing this and I'm trying to figure out how small (byte size) I can make the variables I use to store the values on the connection.
Update Max Ack Delay will be limited by the Max Ack Delay limit once lands. That leaves Packet Tolerance, which I agree is reasonable to limit to a value smaller than 2^62-1 locally. We could add a comment like "Implementations that have a lower limit than 2^62-1 on the Packet Tolerance MUST set treat it as though the maximum supported Packet Tolerance value has been received."
Slight tweak: "If an endpoint receives a Packet Tolerance value that is larger than the maximum value it can represent, the endpoint MUST use the largest representable maximum value instead."

Discussion:
acknowledgement.  A value of 1 will result in an acknowledgement being sent for every ack-eliciting packet received.  A value of 0 is invalid.  Receipt of an invalid value MUST be treated as a <del> connection error of type FRAME_ENCODING_ERROR. </del> <ins> connection error of type FRAME_ENCODING_ERROR.  If an endpoint receives an ACK-eliciting threshold value that is larger than the maximum value it can represent, the endpoint MUST use the largest representable value instead. </ins> A variable-length integer representing an update to the peer's "max_ack_delay" transport parameter (Section 18.2 of QUIC-
Change:
by allowing implementations to not add maxackdelay to the PTO calculation if enough ack-eliciting packets are in flight.
NAME Does Jana's longer explanation help or would you like more clarification?
With this extension, an immediate ACK is expected if more than the "Packet Tolerance" ack-eliciting packets are outstanding. Given that, it may be a worthwhile optimization to allow the maxackdelay to not be included in the PTO computation in some cases. If we're not going to allow that, I think we should explain why. URL This split off , but I think the question of whether maxackdelay always needs to be included in PTO should be separate from whether QUIC would benefit from an ACK-pull mechanism of some sort. That being said, if a mechanism did exist, we add details about when ACK-pull allowed maxackdelay to not be included.
This is a clever optimization, I agree it's worth some text.
I'm not sure I understand the motivation for this (I'm also having trouble following the issue). Can we add some more explanation here?one suggestion, but lgtm otherwise.

Discussion:
"max_ack_delay" for PTO computations, endpoints MUST use the maximum of the current value and all those in flight. <ins> When the number of in-flight ack-eliciting packets is larger than the ACK-Eliciting Threshold, an endpoint can expect that the peer will not need to wait for its "max_ack_delay" period before sending an acknowledgement.  In such cases, the endpoint MAY therefore exclude the peer's 'max_ack_delay' from its PTO calculation.  Note that this optimization requires some care in implementation, since it can cause premature PTOs under packet loss when "ignore_order" is enabled. </ins> 8. There are tradeoffs inherent in a sender sending an ACK_FREQUENCY
Change:
merging.
If it doesn't change it, we should say so. If it allows it to be reduced, then we need to understand what the limits are(ie: it can't be lowered to 1us presumably?). Admittedly, the way we're using maxackdelay should be safe to assuming a 0 value, since the SRTT will accrue the excess.

Discussion:
receipt of a min_ack_delay that is greater than the received max_ack_delay as a connection error of type PROTOCOL_VIOLATION.  Note that while the endpoint's max_ack_delay transport parameter is in <del> milliseconds (Section 18.2 in QUIC-TRANSPORT), min_ack_delay is </del> <ins> milliseconds (Section 18.2 of QUIC-TRANSPORT), min_ack_delay is </ins> specified in microseconds. 4.

is invalid. A variable-length integer representing an update to the peer's <del> "max_ack_delay" transport parameter (Section 18.2 in QUIC- </del> <ins> "max_ack_delay" transport parameter (Section 18.2 of QUIC- </ins> TRANSPORT).  The value of this field is in microseconds.  Any <del> value smaller than the min_ack_delay advertised by this endpoint </del> <ins> value smaller than the "min_ack_delay" advertised by this endpoint </ins> is invalid. <del> Receipt of invalid values in an ACK-FREQUENCY frame MUST be treated as a connection error of type PROTOCOL_VIOLATION. </del> <ins> Receipt of an empty ACK-FREQUENCY frame or invalid values in an ACK- FREQUENCY frame MUST be treated as a connection error of type PROTOCOL_VIOLATION. </ins> ACK-FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission. <del> An endpoint MUST NOT send an empty ACK-FREQUENCY frame.  Endpoints MUST treat receipt of an empty ACK-FREQUENCY frame as a connection error of type PROTOCOL_VIOLATION. </del> An endpoint MAY send ACK-FREQUENCY frames multiple times during a connection and with different values. <del> An endpoint will have committed a max_ack_delay value to the peer, </del> <ins> An endpoint will have committed a "max_ack_delay" value to the peer, </ins> 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

7. <del> TBD. </del> <ins> On sending an update to the peer's "max_ack_delay", an endpoint can use this new value in later computations of its Probe Timeout (PTO) period; see Section 5.2.1 of QUIC-RECOVERY.  The endpoint MUST however wait until the ACK-FREQUENCY frame that carries this new value is acknowledged by the peer. Until the frame is acknowledged, the endpoint MUST use the greater of the current "max_ack_delay" and the value that is in flight when computing the PTO period.  Doing so avoids spurious PTOs that can be caused by an update that increases the peer's "max_ack_delay". While it is expected that endpoints will have only one ACK-FREQUENCY frame in flight at any given time, this extension does not prohibit having more than one in flight.  Generally, when using "max_ack_delay" for PTO computations, endpoints MUST use the maximum of the current value and all those in flight. </ins> 8. TBD. <ins> 9. TBD. </ins>
Change:
Fixes issue .
Thanks for the PR!
Section 4 explains what all the fields are mean first and then explains the exception cases. It seems like this was done the opposite way for Ignore order. I propose we change the current text: To:
SGTM, want to send me a PR or should I?

Discussion:
invalid value MUST be treated as a connection error of type PROTOCOL_VIOLATION. <del> An 8-bit field representing a boolean truth value.  This field MUST have the value 0x00 (representing "false") or 0x01 (representing "true").  This field can be set to "true" by an endpoint that does not wish to receive an immediate acknowledgement when the peer observes reordering (reordering). Receipt of any other value MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </del> <ins> An 8-bit field representing a boolean truth value.  This field is set to "true" by an endpoint that does not wish to receive an immediate acknowledgement when the peer observes reordering (reordering).  The value of this field MUST be 0x00 (representing "false") or 0x01 (representing "true").  Receipt of any other value MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </ins> ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission if an ACK_FREQUENCY frame with a larger
Change:
“As discussed in Section 9 however, there are undesirable consequences to congestion control and loss recovery if a receiver uniltaerally reduces the acknowledgment frequency.“ This is a harsh statement. I don’t think it is true for smaller changes. There is much experience of using TCP where stretch ACKs cover more than two packets. This is a matter of scale. For instance: I’m confident that stretched TCP ACKs covering 4 segments (maybe more ... I’d love to say up to IW) would not break TCP CC, so I don’t see why the editors want to suggest it could break QUIC CC! This really does need a less obfuscated explanation.
I'd be happy to reword this to "there can be undesirable consequences ...", but were you looking for a larger change?
Thanks - yes, /can be/ would seem fair, since they are enumerated later.
This seems an improvement, thanks.

Discussion:
number of acknowledgments allows connection throughput to scale much further. <del> As discussed in implementation however, there are undesirable </del> <ins> As discussed in implementation however, there can be undesirable </ins> consequences to congestion control and loss recovery if a receiver uniltaerally reduces the acknowledgment frequency.  A sender's constraints on the acknowledgement frequency need to be taken into
Change:
The draft doesn't mention anything about ACK frequency and connection migration. What should we do, for example, when a client has migrated and now sends a PING to force the server to use a new path? Should it send PING+IMMEDIATE_ACK?
That seems sensible. Mind writing a PR?
There's nothing odd about an immediate ACK! Perhaps the text should start by saying that the spec allows a receiver to do this anyway? However, the current text doesn't explain why the Immediate ACK might be useful. I could see three places that might benefit from an IMMEDIATE_ACK: Two cases relevant to SCTP [RFC7053] are: When the rate of transmission was very low and packets might be lost and not detected (something not uncommon in some SCTP uses); as an alternative to detect connectivity failure and trigger path failover. I'm not sure how important these specific cases are for QUIC, because the discussion at the time in TSVWG appeared to centre around use for signalling traffic? There could also be real opportunity to use this to get more precise timing/congestion information. A set of per-packet ACKs might be useful while a CC is probing to confirm available capacity, etc. Have I missed a killer application for the method - it would be helpful to me to understand /some example for how the WG think this could be used. (aside: I am actually uncertain whether this would really be a good change to TCP, especially with the heterogeniety of TCP middleboxes and senders,... that's another story, but I'd think it might be nice to not rely on draft-gomez-tcpm-ack-pull as a reference. I could suggest RFC7053, where people might recall there was quite some discussion in TSVWG about whether SCTP would benefit from being able to trigger an immediate response.)
We use an immediate ACK to support CC by delayed ACKs.
URL adds two use cases that uses IMMEDIATE_ACK.
These changes both look good to me.

Discussion:
acknowledgments will cause undesirable bursts of data into the network. <ins> 9.4. To avoid additional delays to connection migration confirmation when using this extension, a client can bundle an IMMEDIATE_ACK frame with the first non-probing frame (Section 9.2 of QUIC-TRANSPORT) it sends or it can simply send an IMMEDIATE_ACK frame, which is a non-probing frame. An endpoint's congestion controller and RTT estimator are reset upon confirmation of migration (Section 9.4 of QUIC-TRANSPORT), which can impact the number of acknowledgements received after migration.  An endpoint that has sent an ACK_FREQUENCY frame earlier in the connection SHOULD update and send a new ACK_FREQUENCY frame immediately upon confirmation of connection migration. 9.5. A sender might use timers to detect loss of PMTUD probe packets.  A sender SHOULD bundle an IMMEDIATE_ACK frame with any PTMUD probes to avoid triggering such timers. </ins> 10. TBD.
Change:
Although I understand what minackdelay represents it's not clear to me what an implementation should do with that value. Is the purpose to make sure that stacks sufficiently wait enough time before triggering PTO? There's no guidance on this in the draft. Perhaps there should be.
represents the minimum time that the receiver can delay for. In the common case, this would be the receiver's clock or timer granularity. This is for the receiver to indicate that the sender cannot reduce below this value. So a receiver implementation can simply use its granularity for this value, and a sender must ensure that its is not below the received . Does this help, NAME We can add some text to clarify this.
Thanks. Yes, I think this should be explained in the draft like you said.

Discussion:
A variable-length integer representing the minimum amount of time in microseconds by which the endpoint can delay an <del> acknowledgement. </del> <ins> acknowledgement.  This limit could be based on the receiver's clock or timer granularity. </ins> An endpoint's min_ack_delay MUST NOT be greater than its max_ack_delay.  Endpoints that support this extension MUST treat
Change:
Rate limits can be used to show warnings to the user, e.g. when certificate issuance is limited to 5 certificates per 7 days and you already issued 3. A single client can't count these, because they may be on different servers using different clients.

Discussion:
5.6. Creation of resources can be rate limited to ensure fair usage and <del> prevent abuse.  If rate limits are in place, the server SHOULD send the following three headers fields: Once the rate limit is exceeded, the server responds with an error with the code "rateLimited". </del> <ins> prevent abuse.  Once the rate limit is exceeded, the server MUST respond with an error with the code "rateLimited".  Additionally, the server SHOULD send a "Retry-After" header indicating when the current request may succeed again.  If multiple rate limits are in place, that is the time where all rate limits allow access again for the current request with exactly the same parameters. In addition to the human readable "detail" field of the error response, the server MAY send one or multiple tokens in the "Link" header pointing to documentation about the specific hit rate limits using the "rate-limit" relation. </ins> 5.7.
Change:
(Re-adding the editorial changes that got lumped in )
r+; thanks for pulling these out alone

Discussion:
The following metadata items are defined, all of which are OPTIONAL: <del> A string containing a URI identifying the current terms of service. </del> <ins> A URI identifying the current terms of service. </ins> <del> String containing an HTTP or HTTPS URL locating a website providing more information about the ACME server. </del> <ins> An HTTP or HTTPS URL locating a website providing more information about the ACME server. </ins> <del> If present, MUST be an array of strings.  Each string MUST be a lowercase hostname which the ACME server recognises as referring to itself for the purposes of CAA record validation as defined in RFC6844.  This allows clients to determine the correct issuer domain name to use when configuring CAA record. </del> <ins> Each string MUST be a lowercase hostname which the ACME server recognises as referring to itself for the purposes of CAA record validation as defined in RFC6844.  This allows clients to determine the correct issuer domain name to use when configuring CAA record. </ins> Clients access the directory by sending a GET request to the directory URI.
Change:
As PHB noted in his presentation at IETF 95, the examples in the doc should indicate clearly the start and end of payload of the JWS object, e.g.:
The spec indicates that it’s possible to request certificates of types other than DER; however, there is no indication of what those MIME types are. PEM would be a very useful format; would it be useful to indicate in here what that MIME type is, or at least where to find a list of MIME types that would work here?
The answer is :) But I can agree that it would be good to remind people of this in the spec.
CA certificates are
The documentation seems unclear as to how certificate “up” links are to handle the case of multiple intermediate certificates between root and the issued certificate. Are both certificates part of the payload of the “up” link? Does each “up” link whose payload is not a root certificate (or “last-before-root”) have its own “up” link? Thank you!
It seems pretty clear to me that the right answer is to have one "up" link per parent cert, but allow multiple links per cert. We can add some text to clarify this.

Discussion:
The default format of the certificate is DER (application/pkix-cert). The client may request other formats by including an Accept header in <del> its request. </del> <ins> its request.  For example, the client may use the media type application/x-pem-file to request the certificate in PEM format. </ins> The server provides metadata about the certificate in HTTP headers. <del> In particular, the server MUST include a Link relation header field RFC5988 with relation "up" to provide a certificate under which this certificate was issued, and one with relation "author" to indicate the registration under which this certificate was issued. </del> <ins> In particular, the server send MUST one or more link relation header fields RFC5988 with relation "up", each indicating a single certificate resource for the issuer of this certificate.  The server MAY also include the "up" links from these resources to enable the client to build a full certificate chain. The server MUST also provide a link relation header field with relation "author" to indicate the registration under which this certificate was issued. </ins> If the CA participates in Certificate Transparency (CT) RFC6962, then they may want to provide the client with a Signed Certificate
Change:
As discussed at IETF 95, the server should fail a new-cert request if it cannot fulfill it precisely. It must not modify the request to something it is willing to fulfill.
We need to clarify when an ACME server can ignore attributes in a request that it doesn't like, and when it should ignore them and proceed. For example, if a requested validity date is longer than the policy, should it error back or just ignore that attribute and issue a cert good for as long as it wants? That seems okay. But what about an unsupported request for issuance in the future? Ignoring that seems wrong, and risky.
I think in general ACME should take the approach of refusing to issue a cert if requested parameters (dates, or extensions) are unacceptable. It's cheap for the client to re-request with acceptable parameters, assuming the error message is detailed enough.
Scoping this down to new-certificate requests, since there's not really enough latitude in the other types of request to cause this problem.
Agreed in B.A. to fail, fail, fail, but return information helpful to a human, explicitly not machine-recoverable. It may be possible to give a trivial amount of altitude (e.g. 90 days--will it not be okay if 90-days minus 15 seconds is given?)

Discussion:
subject name, or in an extensionRequest attribute RFC2985 requesting a subjectAltName extension. <del> The values provided in the CSR are only a request, and are not guaranteed.  The server SHOULD return an error if it cannot fulfil the request as specified, but MAY issue a certificate with contents other than those requested, according to its local policy (e.g., removing identifiers for which the client is not authorized). </del> <ins> The server MUST return an error if it cannot fulfil the request as specified, and MUST NOT issue a certificate with contents other than those requested.  If the server requires the request to be modified in a certain way, it should indicate the required changes using an appropriate error code and description. </ins> It is up to the server's local policy to decide which names are acceptable in a certificate, given the authorizations that the server