jiebi/TextFlow huggingface dataset:
Original text:
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>  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>  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>  values MUST be immediately used for delaying acknowledgements; see sending.

Reviewer comments:
Fixes the remainder of not fixed by
This is good enough. You have a conflict to resolve, but let's merge this.

Revised text:
maximum value it can represent, the endpoint MUST use the largest representable value instead.  <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  <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  <ins> number.  The new Ack-Eliciting Threshold and Request Max Ack Delay </ins> values MUST be immediately used for delaying acknowledgements; see sending.
Original text:
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>  A variable-length integer representing an update to the peer's "max_ack_delay" transport parameter (Section 18.2 of QUIC-

Reviewer comments:
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."

Revised text:
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  <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-
Original text:
"max_ack_delay" for PTO computations, endpoints MUST use the maximum of the current value and all those in flight.  8. There are tradeoffs inherent in a sender sending an ACK_FREQUENCY

Reviewer comments:
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.

Revised text:
"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
Original text:
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>  ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission if an ACK_FREQUENCY frame with a larger

Reviewer comments:
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?

Revised text:
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 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
Original text:
number of acknowledgments allows connection throughput to scale much further. <del> As discussed in implementation however, there are undesirable </del>  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

Reviewer comments:
“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.

Revised text:
number of acknowledgments allows connection throughput to scale much further.  <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
Original text:
acknowledgments will cause undesirable bursts of data into the network.  10. TBD.

Reviewer comments:
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.

Revised text:
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.
Original text:
A variable-length integer representing the minimum amount of time in microseconds by which the endpoint can delay an <del> acknowledgement. </del>  An endpoint's min_ack_delay MUST NOT be greater than its max_ack_delay.  Endpoints that support this extension MUST treat

Reviewer comments:
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.

Revised text:
A variable-length integer representing the minimum amount of time in microseconds by which the endpoint can delay an  <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
Original text:
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>  5.7.

Reviewer comments:
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.

Revised text:
5.6. Creation of resources can be rate limited to ensure fair usage and  <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.
Original text:
The following metadata items are defined, all of which are OPTIONAL: <del> A string containing a URI identifying the current terms of service. </del>  <del> String containing an HTTP or HTTPS URL locating a website providing more information about the ACME server. </del>  <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>  Clients access the directory by sending a GET request to the directory URI.

Reviewer comments:
(Re-adding the editorial changes that got lumped in )
r+; thanks for pulling these out alone

Revised text:
The following metadata items are defined, all of which are OPTIONAL:  <ins> A URI identifying the current terms of service. </ins>  <ins> An HTTP or HTTPS URL locating a website providing more information about the ACME server. </ins>  <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.
Original text:
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>  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>  If the CA participates in Certificate Transparency (CT) RFC6962, then they may want to provide the client with a Signed Certificate

Reviewer comments:
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.

Revised text:
The default format of the certificate is DER (application/pkix-cert). The client may request other formats by including an Accept header in  <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.  <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
Original text:
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>  It is up to the server's local policy to decide which names are acceptable in a certificate, given the authorizations that the server

Reviewer comments:
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?)

Revised text:
subject name, or in an extensionRequest attribute RFC2985 requesting a subjectAltName extension.  <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