jiebi/TextFlow huggingface dataset:
Original text:
21.13. Deployments should limit the ability of an attacker to target a new <del> connection to a particular server instance.  This means that client- controlled fields, such as the initial Destination Connection ID used on Initial and 0-RTT packets SHOULD NOT be used by themselves to make routing decisions.  Ideally, routing decisions are made independently of client-selected values; a Source Connection ID can be selected to route later packets to the same server. </del>  21.14.

Reviewer comments:
This was just old and needed a little bit of a refresh. Removing the recommendation, which was counter to established views and unnecessary. I will let others determine whether this is editorial/design.
NAME said:
I think that the point of this section is to highlight the possibility that routing based on client-selected values exposes servers to load that is balanced under client - and therefore attacker - control. I don't think that it needs to include such a strong recommendation. If people deploying load balancers are not concerned about this, then that is good. That makes the recommendation less good. As this is very old text, it needs a bit of a cleanup anyway. I'm going to suggest something along the lines of my statement above in a pull request and we can polish the wording there. I don't think that we should remove the Retry SCID language. That remains an option for servers, even if they don't want to exercise the option (whether load balancers look at Retry tokens is very much down to how the various functions are distributed). What could happen is that the Retry SCID is chosen so that the next initial can be routed as though it were chosen by a client, but in such a way as it results in the connection being sent to a lightly-loaded server instance. That is, if the load balancer routes inchoate Initials based on connection ID, knowledge of that routing algorithm is used to direct traffic. That said, I understand that what is more likely here is that Initials with inauthentic Destination Connection ID fields will be routed using other information: round-robin, random, five-tuple, or whatever.
I think you're proposing that the text I quoted be deleted. That is satisfactory, and what I would recommend as well.
Returning to an open state as the chairs directed in their plan.
Closing this now that the IESG have approved the document(s).
To be safe, let's mark this design.

Revised text:
21.13. Deployments should limit the ability of an attacker to target a new  <ins> connection to a particular server instance.  Ideally, routing decisions are made independently of client-selected values, including addresses.  Once an instance is selected, a connection ID can be selected so that later packets are routed to the same instance. </ins> 21.14.
Original text:
The endpoint uses RTT samples and peer-reported host delays (see Section 13.2 of QUIC-TRANSPORT) to generate a statistical description of the network path's RTT.  An endpoint computes the following three <del> values for each path: the minimum value observed over the lifetime of the path (min_rtt), an exponentially-weighted moving average (smoothed_rtt), and the mean deviation (referred to as "variation" in the rest of this document) in the observed RTT samples (rttvar). </del>  5.1.

Reviewer comments:
This should be fixed. I've sent out .
The natural question that follows will be "which period of time", but I think that is already.Thanks, LG

Revised text:
The endpoint uses RTT samples and peer-reported host delays (see Section 13.2 of QUIC-TRANSPORT) to generate a statistical description of the network path's RTT.  An endpoint computes the following three  <ins> values for each path: the minimum value over a period of time (min_rtt), an exponentially-weighted moving average (smoothed_rtt), and the mean deviation (referred to as "variation" in the rest of this document) in the observed RTT samples (rttvar). </ins> 5.1.
Original text:
5.2. min_rtt is the sender's estimate of the minimum RTT observed for a <del> given network path.  In this document, min_rtt is used by loss detection to reject implausibly small rtt samples. </del>  min_rtt MUST be set to the latest_rtt on the first RTT sample. min_rtt MUST be set to the lesser of min_rtt and latest_rtt (latest-

Reviewer comments:
This should be fixed. I've sent out .
The natural question that follows will be "which period of time", but I think that is already.Thanks, LG

Revised text:
5.2. min_rtt is the sender's estimate of the minimum RTT observed for a  <ins> given network path over a period of time.  In this document, min_rtt is used by loss detection to reject implausibly small rtt samples. </ins> min_rtt MUST be set to the latest_rtt on the first RTT sample. min_rtt MUST be set to the lesser of min_rtt and latest_rtt (latest-
Original text:
in compliance with RFC6437, unless the local API does not allow setting IPv6 flow labels. <del> The IPv6 flow label SHOULD be a pseudo-random function of the source and destination addresses, source and destination UDP ports, and the Destination Connection ID field.  The flow label generation MUST be designed to minimize the chances of linkability with a previously used flow label, as a stable flow label would enable correlating activity on multiple paths; see migration-linkability. A possible implementation is to compute the flow label as a cryptographic hash function of the source and destination addresses, source and destination UDP ports, Destination Connection ID field, and a local secret. </del>  10.

Reviewer comments:
This was a little tricky as the current text already had what we wanted. But it wasn't quite clear on rationale, so I added some of that.
Éric Vyncke said:
I believe that the view was that a PRNG was inferior to a PRF because it required state, but yes, it should be fine. Should we have avoided repeating advice from 6437? (I forget who contributed this text, but I think that it was an RFC 6437 author.)
Text originates with Christian NAME in . A few people have touched it since for editorial purposes, but that doesn't change the point of what you're asking about.

Revised text:
in compliance with RFC6437, unless the local API does not allow setting IPv6 flow labels.  <ins> The flow label generation MUST be designed to minimize the chances of linkability with a previously used flow label, as a stable flow label would enable correlating activity on multiple paths; see migration- linkability. RFC6437 suggests deriving values using a pseudorandom function to generate flow labels.  Including the Destination Connection ID field in addition to source and destination addresses when generating flow labels ensures that changes are synchronized with changes in other observable identifiers.  A cryptographic hash function that combines these inputs with a local secret is one way this might be implemented. </ins> 10.
Original text:
QUIC begins every connection in slow start with the congestion window set to an initial value.  Endpoints SHOULD use an initial congestion window of 10 times the maximum datagram size (max_datagram_size), <del> limited to the larger of 14720 bytes or twice the maximum datagram size.  This follows the analysis and recommendations in RFC6928, increasing the byte limit to account for the smaller 8-byte overhead of UDP compared to the 20-byte overhead for TCP. </del>  If the maximum datagram size changes during the connection, the initial congestion window SHOULD be recalculated with the new size.

Reviewer comments:
Éric Vyncke said:
I think the ambiguity is whether the "limited to" is saying: the maximum datagram size is no more than twice the maximum datagram size (which is nonsensical) the initial congestion window is min(10maxdatagramsize, max(14720 bytes, 2maxdatagramsize)) Given that one of the possible interpretations is logically inconsistent, the other one must be correct. I'm not sure how to make this sentence clearer except through pseudo-code. Looking at the pseudo-code, there isn't any -- kInitialWindow is declared to be a constant, value defined by this text, but the definition of this constant is given in terms of a variable (maxdatagramsize). Maybe kInitialWindow should become a variable itself, and then have pseudo-code with the max/min relationship added to B.3?
This is clearer; thanks.

Revised text:
QUIC begins every connection in slow start with the congestion window set to an initial value.  Endpoints SHOULD use an initial congestion window of 10 times the maximum datagram size (max_datagram_size),  <ins> while limiting the window to the larger of 14720 bytes or twice the maximum datagram size.  This follows the analysis and recommendations in RFC6928, increasing the byte limit to account for the smaller 8-byte overhead of UDP compared to the 20-byte overhead for TCP. </ins> If the maximum datagram size changes during the connection, the initial congestion window SHOULD be recalculated with the new size.
Original text:
An endpoint MUST include the value from the Source Connection ID field of the packet it receives in the Destination Connection ID <del> field.  The value for Source Connection ID MUST be copied from the Destination Connection ID of the received packet, which is initially randomly selected by a client.  Echoing both connection IDs gives clients some assurance that the server received the packet and that the Version Negotiation packet was not generated by an attacker that is unable to observe packets. </del>  An endpoint that receives a Version Negotiation packet might change the version that it decides to use for subsequent packets.  The

Reviewer comments:
The names are capitalized, but we don't say "the ... field." We probably should.

Revised text:
An endpoint MUST include the value from the Source Connection ID field of the packet it receives in the Destination Connection ID  <ins> field.  The value for the Source Connection ID field MUST be copied from the Destination Connection ID field of the received packet, which is initially randomly selected by a client.  Echoing both connection IDs gives clients some assurance that the server received the packet and that the Version Negotiation packet was not generated by an attacker that is unable to observe packets. </ins> An endpoint that receives a Version Negotiation packet might change the version that it decides to use for subsequent packets.  The
Original text:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP <del> 14 BCP14 when, and only when, they appear in all capitals, as shown here. </del>  This document uses the variable-length integer encoding from QUIC- TRANSPORT.

Reviewer comments:
I've had to make some changes in the template to deal with some odd regressions in CircleCI (see URL for details). This is the updated configuration.
Yeah, given how this breaks in Circle; that's probably wise.
NAME NAME do you think that you could stop following this project in CircleCI? Then we can merge this one.
Is there a reason not to simply move this repo over to GitHub Actions as well?

Revised text:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP  <ins> 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> This document uses the variable-length integer encoding from QUIC- TRANSPORT.
Original text:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP <del> 14 BCP14 when, and only when, they appear in all capitals, as shown here. </del>  Definitions of terms that are used in this document:

Reviewer comments:
I've had to make some changes in the template to deal with some odd regressions in CircleCI (see URL for details). This is the updated configuration.
Yeah, given how this breaks in Circle; that's probably wise.
NAME NAME do you think that you could stop following this project in CircleCI? Then we can merge this one.
Is there a reason not to simply move this repo over to GitHub Actions as well?

Revised text:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP  <ins> 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> Definitions of terms that are used in this document:
Original text:
The entries in iana-setting-table are registered by this document. <del> For fomatting reasons, setting names can be abbreviated by removing the 'SETTING_' prefix. </del>  Each code of the format "0x1f * N + 0x21" for non-negative integer values of "N" (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe)

Reviewer comments:
which also occurs in H3 but apparently wasn't caught.
Throughout, the document uses "SETTINGS" as the first part of thte HTTP/3 setting names. We have updated this sentence for consistency. Please let us know if any corrections are needed. Original: For fomatting reasons, the setting names here are abbreviated by removing the 'SETTING' prefix. Current: For formatting reasons, the setting names here are abbreviated by removing the 'SETTINGS_' prefix.
Fixed in .

Revised text:
The entries in iana-setting-table are registered by this document.  <ins> For formatting reasons, setting names can be abbreviated by removing the 'SETTINGS_' prefix. </ins> Each code of the format "0x1f * N + 0x21" for non-negative integer values of "N" (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe)
Original text:
header field names proliferates. <del> Client applications interfacing with different servers may thus need to process different headers, or the very same application interface </del>  that sits behind different reverse proxies may reply with different throttling headers.

Reviewer comments:
Improves terminology
In other parts of the document we still use client as we are not sure whether to refer explicitly to a User Agent or not. Ideas welcome...
See RFC 7230 terminology definitions (, not changing in the new specs, FWIW).

Revised text:
header field names proliferates.  <ins> User Agents interfacing with different servers may thus need to process different headers, or the very same application interface </ins> that sits behind different reverse proxies may reply with different throttling headers.
Original text:
"RateLimit-Reset": containing the time remaining in the current window, specified in seconds. <del> The behavior of "RateLimit-Reset" is compatible with the "delta- </del>  seconds" notation of "Retry-After". The fields definition allows to describe complex policies, including

Reviewer comments:
uses http-core semantics fixes Sections refs cc: NAME
I'll wait for the new i-d-template image, but will do.
Please use either [RFCxxxx], Section yyy or Section yyy of [RFCxxxx]
Addressed by now.
If you start using the new kramdown-rcf2629 section ref syntax, you may want to do that consistently...

Revised text:
"RateLimit-Reset": containing the time remaining in the current window, specified in seconds.  <ins> The behavior of "RateLimit-Reset" is compatible with the "delay- </ins> seconds" notation of "Retry-After". The fields definition allows to describe complex policies, including
Original text:
This specification does not cover the throttling scope, that may be the given resource-target, its parent path or the whole Origin <del> RFC6454 section 7. </del>  The rate-limit headers may be returned in both Successful and non Successful responses.  This specification does not cover whether

Reviewer comments:
uses http-core semantics fixes Sections refs cc: NAME
I'll wait for the new i-d-template image, but will do.
Please use either [RFCxxxx], Section yyy or Section yyy of [RFCxxxx]
Addressed by now.
If you start using the new kramdown-rcf2629 section ref syntax, you may want to do that consistently...

Revised text:
This specification does not cover the throttling scope, that may be the given resource-target, its parent path or the whole Origin  <ins> (see Section 7 of RFC6454). </ins> The rate-limit headers may be returned in both Successful and non Successful responses.  This specification does not cover whether
Original text:
capitals, as shown here. This document uses the Augmented BNF defined in RFC5234 and updated <del> by RFC7405 along with the "#rule" extension defined in Section 7 of MESSAGING. </del>  <del> The term Origin is to be interpreted as described in RFC6454 section 7. </del>  <del> The "delta-seconds" rule is defined in CACHING section 1.2.1. </del>  2.

Reviewer comments:
uses http-core semantics fixes Sections refs cc: NAME
I'll wait for the new i-d-template image, but will do.
Please use either [RFCxxxx], Section yyy or Section yyy of [RFCxxxx]
Addressed by now.
If you start using the new kramdown-rcf2629 section ref syntax, you may want to do that consistently...

Revised text:
capitals, as shown here. This document uses the Augmented BNF defined in RFC5234 and updated  <ins> by RFC7405 along with the "#rule" extension defined in Section 5.6.1 of SEMANTICS. </ins>  <ins> The term Origin is to be interpreted as described in Section 7 of RFC6454. </ins>  <ins> The "delay-seconds" rule is defined in Section 10.2.4 of SEMANTICS. </ins> 2.
Original text:
The header value is <del> The delta-seconds format is used because: </del>  it does not rely on clock synchronization and is resilient to clock adjustment and clock skew between client and server (see <del> SEMANTICS Section 4.1.1.1); </del>  it mitigates the risk related to thundering herd when too many clients are serviced with the same timestamp.

Reviewer comments:
uses http-core semantics fixes Sections refs cc: NAME
I'll wait for the new i-d-template image, but will do.
Please use either [RFCxxxx], Section yyy or Section yyy of [RFCxxxx]
Addressed by now.
If you start using the new kramdown-rcf2629 section ref syntax, you may want to do that consistently...

Revised text:
The header value is  <ins> The delay-seconds format is used because: </ins> it does not rely on clock synchronization and is resilient to clock adjustment and clock skew between client and server (see  <ins> Section 5.6.7 of SEMANTICS); </ins> it mitigates the risk related to thundering herd when too many clients are serviced with the same timestamp.
Original text:
5. <del> This section documents the considerations advised in Section 15.3.3 </del>  of SEMANTICS. An intermediary that is not part of the originating service

Reviewer comments:
uses http-core semantics fixes Sections refs cc: NAME
I'll wait for the new i-d-template image, but will do.
Please use either [RFCxxxx], Section yyy or Section yyy of [RFCxxxx]
Addressed by now.
If you start using the new kramdown-rcf2629 section ref syntax, you may want to do that consistently...

Revised text:
5.  <ins> This section documents the considerations advised in Section 16.3.3 </ins> of SEMANTICS. An intermediary that is not part of the originating service
Original text:
8.3.1. <del> The server does not expose "RateLimit-Remaining" values, but resets the limit counter every second. </del>  It communicates to the client the limit of 10 quota-units per second always returning the couple "RateLimit-Limit" and "RateLimit-Reset".

Reviewer comments:
Improves example description
https://ietf-wg-URL The example with just RateLimit-Limit and RateLimit-Reset In it seems this is a case where the RateLimit-Reset value is not able to be used to determine how long one should wait, but is rather just a Limit definition ? Why not then just use RateLimit-Limit: 10;w=1 and omit the other two headers ? Is this to cater for the inevitable 429 to provide a RateLimit-Reset value at that point ? If that is the case I question the value of using the two headers in “successful” responses.
This example is related to an implementation that uses the "old" ratelimit field set, that do not support . We should improve the description.
:+1:

Revised text:
8.3.1.  <ins> The server does not expose "RateLimit-Remaining" values (for example, because the underlying counters are not available).  Instead, it resets the limit counter every second. </ins> It communicates to the client the limit of 10 quota-units per second always returning the couple "RateLimit-Limit" and "RateLimit-Reset".
Original text:
does not need to make them accessible to clients.  Clients SHOULD NOT attempt to dereference or manipulate them.  7.3. Using the Accept Option, the requester can control whether this list

Reviewer comments:
This contains what I think of the easy fixes to the requirements of replicated RDs. See URL for more discussion, please comment on whether you think those changes are acceptable.
The minimum for interoperability IMO is that client's don't always pick the first choice -- because if they do, no fault tolerance is possible. Do you think that that even this is too much specification of behavior, or did I write more in the PR than what would be needed to satisfy that minimum requirement?
chrysn schreef op 2018-02-01 17:03: Is that so? The first choice of one client is not necessarily the first choice of another when we are confronted with RDs which have contact problems. Several protocols have handled this problem: like dhcp for example. Why not copy that behavior?
I think we're talking about different "first"s here. I'm not concerned with what happens when multiple servers answer the multicast CoAP request. (Led to an interesting chat with PIM people but is not a matter that should concern the RD). What I do think we should give guidance is what happens if the RDAO announces multiple addresses (something explicitly allowed in the current draft), or the URI discovery response contains more than one rt="URL" link Both are within what I think we describe as acceptable server behavior. If clients are unaware and just always pick the first line (because it looks like a zero-or-one situation to the implementers), interoperability issues will arise when two are announced an the first one fails.
Ok, got it, see below chrysn schreef op 2018-02-02 12:11: Yeah, that's a nuisance. Someone seems to know what they want that for, annd probably have some intelligent algorithm to break ties.......... One might say that client MAY choose their RD randomly. I assume that is a multicast response? Then the first response is probably the closest and the best choice. And when one MC response contains multiple RD links, We are not responsible, and something clever is being thought out somewhere, we hope. I think DHCP specifies clients to wait so many seconds before choosing a server. When the first one fails, the client will try the second one, und so weiter ... What am I missing still?
for interoperability, the client behavior when multiple URIs are discovered, or the RD does not answer, need not be specified. The text starts to look more and more like Bonjour

Revised text:
does not need to make them accessible to clients.  Clients SHOULD NOT attempt to dereference or manipulate them. <ins> A Resource Directory can report endpoints or groups in lookup that are not hosted at the same address.  While the setup and management of such a distributed system is out of scope for this document, lookup clients MUST be prepared to see arbitrary URIs as registration or group resources in the results. </ins> 7.3. Using the Accept Option, the requester can control whether this list