jiebi/TextFlow huggingface dataset:
Original text:
If the number of necessary server IDs per next hop is uniform, a simple implementation would use successively longer server IDs at each tier of load balancing, and the server configuration would match <del> the last tier.  The forward load balancers would simply treat the least significant bits of the server ID as part of the nonce. </del>  6.2.

Reviewer comments:
Better not to deal with creating a new definition here. Especially one that uses the word "forward". Reword.

Revised text:
If the number of necessary server IDs per next hop is uniform, a simple implementation would use successively longer server IDs at each tier of load balancing, and the server configuration would match  <ins> the last tier.  Load balancers closer to the client can then treat any parts of the server ID they did not use as part of the nonce. </ins> 6.2.
Original text:
All connection IDs use the following format:  4.2. The configuration agent assigns a server ID to every server in its

Reviewer comments:
In (Section 4.1](URL), these fields are not defined: They probably should be.

Revised text:
All connection IDs use the following format: <ins> The First Octet field serves one or two purposes, as defined in first-octet. The Server ID field encodes the information necessary for the load balancer to route a packet with that connection ID.  It is often encrypted. The server uses the Nonce field to make sure that each connection ID it generates is unique, even though they all use the same Server ID. </ins> 4.2. The configuration agent assigns a server ID to every server in its
Original text:
To support a handover, a server involved in the transition could issue CIDs that map to the new server via a NEW_CONNECTION_ID frame, <del> and retire CIDs associated with the new server using the "Retire </del>  Prior To" field in that frame. <del> Alternately, if the old server is going offline, the load balancer could simply map its server ID to the new server's address. </del> 7. The server ID encodings, and requirements for their handling, are

Reviewer comments:
This only works if the cutover is immediate. "going offline" suggests something progressive, which means that this strategy only works if you suddenly start holding a bunch of state. There a lots of caveats here, to the point that I'd probably just drop this whole paragraph.

Revised text:
To support a handover, a server involved in the transition could issue CIDs that map to the new server via a NEW_CONNECTION_ID frame,  <ins> and retire CIDs associated with the old server using the "Retire </ins> Prior To" field in that frame.  7. The server ID encodings, and requirements for their handling, are
Original text:
complete.  Otherwise, there are further steps, as described in the two following subsections. <del> Encryption below uses the AES-128-ECB cipher.  Future standards could add new algorithms that use other ciphers to provide cryptographic agility in accordance with RFC7696.  QUIC-LB implementations SHOULD be extensible to support new algorithms. </del>  4.3.1.

Reviewer comments:
This needs a normative reference. There is likely a NIST SP with a number you can use somewhere.

Revised text:
complete.  Otherwise, there are further steps, as described in the two following subsections.  <ins> Encryption below uses the AES-128-ECB cipher NIST-AES-ECB.  Future standards could add new algorithms that use other ciphers to provide cryptographic agility in accordance with RFC7696.  QUIC-LB implementations SHOULD be extensible to support new algorithms. </ins> 4.3.1.
Original text:
8.2. Attackers in this privileged position are intrinsically able to map <del> two connection IDs to the same server.  The QUIC-LB algorithms do prevent the linkage of two connection IDs to the same individual connection if servers make reasonable selections when generating new IDs for that connection. </del>  8.3.

Reviewer comments:
I would think that you instead want to say if the nonce part is chosen in a manner that is unpredictable to the adversary, or encrypted.

Revised text:
8.2. Attackers in this privileged position are intrinsically able to map  <ins> two connection IDs to the same server.  These algorithms ensure that two connection IDs for the same connection cannot be identified as such as long as the server chooses the first octet and any plaintext nonce correctly. </ins> 8.3.
Original text:
1.2. All wire formats will be depicted using the notation defined in <del> Section 1.3 of RFC9000.  There is one addition: the function len() refers to the length of a field which can serve as a limit on a different field, so that the lengths of two fields can be concisely defined as limited to a sum, for example: x(A..B) y(C..B-len(x)) indicates that x can be of any length between A and B, and y can be of any length between C and B provided that (len(x) + len(y)) does not exceed B. The example below illustrates the basic framework: </del>  2.

Reviewer comments:
Fixing . I love deleting this much text!
This might be achieved as follows:
I'll should also point out that there is optional and you can also do: For any value of , though presumably is at least , it could reasonably be any value up to .

Revised text:
1.2. All wire formats will be depicted using the notation defined in  <ins> Section 1.3 of RFC9000. </ins> 2.
Original text:
QUIC.  For example, a non-compliant DCID might be converted to an integer and divided by the number of servers, with the modulus used to forward the packet.  The number of servers is usually consistent <del> on the time scale of a QUIC connection handshake. </del>  Load balancers SHOULD drop packets with non-compliant DCIDs in a short header. The use of client-generated incoming DCIDs does not persist beyond a few round trips in the connection. <del> In this interval, some exposed fields (e.g.  UDP address and port, source and client-generated destination Connection ID) remain constant for all packets in the connection.  For example, 0RTT and Initial packets use the same CIDs and ports. </del>  If these assumptions are invalid, this specification is likely to lead to loss of packets that contain non-compliant DCIDs, and in

Reviewer comments:
Carefully phrased language that considers NAME 's suggestion that SCID may not be stable across versions, and tries to suggest (IP, port, DCID) as a suitable long header hash without making promises on behalf of quic-invariants.
NAME sayeth on the list: It would be useful to include something like this in Section 4 as a non-normative hint on what fields to use, since our hint currently consists of an example that just uses the DCID. Similarly, make that assumption clearer in Section 8.
For what it's worth, Google's load balancer only uses destination CIDs for routing. We always pick 64bit CIDs during the handshake so we can assume that short headers always carry 64bit CIDs.
Do all CIDs resolve to a valid server ID?
NAME do you not care about an attacker specifically crafting destination CIDs to attack a particular server?
NAME We do not have a concept of server ID, but yes every CID routes to a server. NAME We do not care about that attack. I haven't seen any indication that it can actually cause harm in real life.
NAME very well, then you have no non-compliant DCIDs. You would only need to upgrade your LBs for new versions if they allowed client-chosen DCIDs < 8 bytes.

Revised text:
QUIC.  For example, a non-compliant DCID might be converted to an integer and divided by the number of servers, with the modulus used to forward the packet.  The number of servers is usually consistent  <ins> on the time scale of a QUIC connection handshake.  See also version- invariance. </ins> Load balancers SHOULD drop packets with non-compliant DCIDs in a short header. The use of client-generated incoming DCIDs does not persist beyond a few round trips in the connection.  <ins> While the client is using DCIDs it generated, some exposed fields (IP address, UDP port, client-generated destination Connection ID) remain constant for all packets sent on the same connection. While this document does not update the commitments in QUIC- INVARIANTS, the additional assumptions are minimal and narrowly scoped, and provide a likely set of constants that load balancers can use with minimal risk of version- dependence. </ins> If these assumptions are invalid, this specification is likely to lead to loss of packets that contain non-compliant DCIDs, and in
Original text:
ID Length, Key, and Zero-Padding Length.  The Server ID is unique to each server, but the others MUST be global.  A full QUIC-LB configuration MUST also specify the information content of the first CID octet and the presence and mode of any Retry Service.

Reviewer comments:
Updated the test vectors for the latest version of the spec, added PCID, and made them usable to test server implementations.

Revised text:
ID Length, Key, and Zero-Padding Length.  The Server ID is unique to each server, but the others MUST be global. <ins> Note that server IDs are opaque bytes, not integers, so there is no notion of network order or host order. </ins> A full QUIC-LB configuration MUST also specify the information content of the first CID octet and the presence and mode of any Retry Service.
Original text:
packet.  The client IP address is 16 octets.  If an IPv4 address, the last 12 octets are zeroes. <del> date-time: The date-time string is a total of 20 octets and encodes the time the token was generated.  The format of date-time is described in Section 5.6 of RFC3339.  This ASCII field MUST use the "Z" character for time-offset. </del>  Opaque Data: The server may use this field to encode additional information, such as congestion window, RTT, or MTU.  Opaque data

Reviewer comments:
As the draft describes: 'The date-time string is a total of 20 octets and encodes the time the token was generated. The format of date-time is described in Section 5.6 of [RFC3339].' this needs 20 octets in ascii, may be the unix time which is the the number of seconds since the Unix epoch in 8 octets is a better choice in transmission and computing ?
NAME have a look at the PR, please

Revised text:
packet.  The client IP address is 16 octets.  If an IPv4 address, the last 12 octets are zeroes.  <ins> Timestamp: The timestamp is a 64-bit integer, in network order, that expresses the number of seconds in POSIX time (see Sec. 4.16 of TIME_T). </ins> Opaque Data: The server may use this field to encode additional information, such as congestion window, RTT, or MTU.  Opaque data
Original text:
lead to loss of packets that contain non-compliant DCIDs, and in extreme cases connection failure.  10. QUIC-LB is intended to prevent linkability.  Attacks would therefore

Reviewer comments:
Some load balancers today switch based on the SNI. Obviously, this is not version-invariant. We should add some language about this. What should such an LB when it encounters an unknown version? It probably has no choice but to forward it based on CID and hope for the best.
If the differing domains trust each other, the servers could helpfully generate Retry packets to redirect the client to the right place. This assumes a bunch of shared state, and that those servers support the same version while the LB does not. Of course, if version support differs, the VN process has serious problems.
Maybe encrypt sni will be the real standard later(see URL), I just think that there is no need for quic lb considering sni

Revised text:
lead to loss of packets that contain non-compliant DCIDs, and in extreme cases connection failure. <ins> Some load balancers might inspect elements of the Server Name Indication (SNI) extension in the TLS Client Hello to make a routing decision.  Note that the format and cryptographic protection of this information may change in future versions or extensions of TLS or QUIC, and therefore this functionality is inherently not version- invariant. </ins> 10. QUIC-LB is intended to prevent linkability.  Attacks would therefore
Original text:
Abstract <del> QUIC connection IDs allow continuation of connections across address/ port 4-tuple changes, and can store routing information for stateless or low-state load balancers.  They also can prevent linkability of connections across deliberate address migration through the use of protected communications between client and server.  This creates issues for load-balancing intermediaries.  This specification standardizes methods for encoding routing information given a small set of configuration parameters.  This framework also enables offload of other QUIC functions to trusted intermediaries, given the explicit cooperation of the QUIC server. </del>  1.

Reviewer comments:
Less emphasis on load balancers, more on the other stuff. More text on the use cases and less on "how".

Revised text:
Abstract  <ins> The QUIC protocol design is resistant to transparent packet inspection, injection, and modification by intermediaries.  However, the server can explicitly cooperate with network services by agreeing to certain conventions and/or sharing state with those services. This specification provides a standardized means of solving three problems: (1) maintaining routability to servers via a low-state load balancer even when the connection IDs in use change; (2) explicit encoding of the connection ID length in all packets to assist hardware accelerators; and (3) injection of QUIC Retry packets by an anti-Denial-of-Service agent on behalf of the server. </ins> 1.
Original text:
balancer uses the first two bits of the connection ID to multiplex incoming DCIDs over these schemes.  This section describes three participants: the configuration agent, the load balancer, and the server.

Reviewer comments:
Addresses
The stream and block cipher configuration are locked to AES-ECB. AES-128-ECB too (this needs to be clear). This is a fine design. If a better design is required, that can be achieved by adding a new arm to . It might pay to say that and cite URL at the same time.
LGTM. A suggestion, but I'm OK either way.

Revised text:
balancer uses the first two bits of the connection ID to multiplex incoming DCIDs over these schemes. <ins> Encryption in the algorithms below uses the AES-128-ECB cipher. Future standards could add new algorithms that use other ciphers to provide cryptographic agility in accordance with RFC7696.  QUIC-LB implementations SHOULD be extensible to support new algorithms. </ins> This section describes three participants: the configuration agent, the load balancer, and the server.
Original text:
For brevity, "Connection ID" will often be abbreviated as "CID".  2. 2.1. The first octet has the following fields: <del> CR: Config Rotation bits. </del>  <del> CID Len: Length Self-Description (if applicable).  Encodes the length of the Connection ID following the First Octet. </del>  4.

Reviewer comments:
There are so many variable length fields that the ASCII art doesn't serve much of a purpose. Just switch to the notation used in quic-transport for the various CID and token formats.

Revised text:
For brevity, "Connection ID" will often be abbreviated as "CID". <ins> 1.2. All wire formats will be depicted using the notation defined in Section 1.3 of QUIC-TRANSPORT.  There is one addition: the function len() refers to the length of a field which can serve as a limit on a different field, so that the lengths of two fields can be concisely defined as limited to a sum, for example: x(A..B) y(C..B-len(x)) indicates that x can be of any length between A and B, and y can be of any length between C and B provided that (len(x) + len(y)) does not exceed B. The example below illustrates the basic framework: </ins> 2. 2.1. The first octet has the following fields:  <ins> Config Rotation: Indicates the configuration used to interpret the CID. </ins>  <ins> CID Len or Random Bits: Length Self-Description (if applicable), or random bits otherwise.  Encodes the length of the Connection ID following the First Octet. </ins> 4.
Original text:
BGP (I-D.ietf-idr-bgp-model) <del> PIM (I-D.liu-pim-yang) </del>  NAT management (RFC8512)

Reviewer comments:
PIM ([I-D.liu-pim-yang]) is outadated
see
URL
Closed with commit

Revised text:
BGP (I-D.ietf-idr-bgp-model)  <ins> PIM (I-D.ietf-pim-yang) </ins> NAT management (RFC8512)
Original text:
reused by other VPN-related YANG modules (e.g., L3NM, L3SM, Layer 2 Network Model): "ietf-vpn-common". <del> The YANG data models defined in this document conform to the Network Management Datastore Architecture (NMDA) RFC8342. </del> 2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Reviewer comments:
Error: Unable to parse the XML document: draft-ietf-opsawg-l3sm-l3nm-URL : Line 4822: Entity 'RFC6991' not defined : Line 4823: Entity 'RFC8294' not defined : Line 4867: Entity 'RFC8277' not defined The command "xml2rfc draft-ietf-opsawg-l3sm-l3nm-URL" exited with 1. can you update?

Revised text:
reused by other VPN-related YANG modules (e.g., L3NM, L3SM, Layer 2 Network Model): "ietf-vpn-common".  2. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Original text:
Relies upon application-specific classification. Groups a set of parameters that are used when CsC is enabled such <del> the use of BGP for signalling purposes RFC8277. </del>  Time synchronization may be needed in some VPNs such as infrastructure and management VPNs.  This container is used to

Reviewer comments:
The term was used with signalling and signaling. I modified it to signaling, so it is aligned with L2NM as well

Revised text:
Relies upon application-specific classification. Groups a set of parameters that are used when CsC is enabled such  <ins> the use of BGP for signaling purposes RFC8277. </ins> Time synchronization may be needed in some VPNs such as infrastructure and management VPNs.  This container is used to
Original text:
the L3NM attribute (e.g., actual forwarding policies).  Some of the information captured in L3SM may be maintained locally within the Orchestrator; which is supposed to maintain a "glue" between a <del> Customer view and its network instantiation. </del>  The L3NM module does not attempt to address all deployment cases especially those where the L3VPN connectivity is supported through

Reviewer comments:
Allows a controller to expose the L3SM to which an L3NM is bound
OK! It is optional. Should work typically the other way around, allows the service orchestrator to maintain the match and facilitate reconciliation. NAME Please add some text in the draft to explain the parameter
Please see the change: Will add more text once we will work seriously on the tree structure part.

Revised text:
the L3NM attribute (e.g., actual forwarding policies).  Some of the information captured in L3SM may be maintained locally within the Orchestrator; which is supposed to maintain a "glue" between a  <ins> Customer view and its network instantiation.  Likewise, some of the information captured and exposed using L3NM can fed the service layer (e.g., capabilities) to derive L3SM and drive VPN service order handling. </ins> The L3NM module does not attempt to address all deployment cases especially those where the L3VPN connectivity is supported through
Original text:
IPv4 and IPv6 addresses MUST expose a different mDNS name for each address.  Note that any server-reflexive candidates generated from an mDNS host candidate will have IP addresses as their transport addresses, rather than mDNS hostnames.  Because their transport addresses are different

Reviewer comments:
PR of
Currently it contains: c=IN IP4 address/ttl Obviously, putting one of the candidate's IP address there would defeat the purpose of use mDNS. Options: Can this be omitted? Should it have a fake IP address of the right address family? Should it be allowed to have an mDNS name?
Just use the mDNS name.
If we run into issues, we could use 0.0.0.0:9 as we do when there are no candidates, but that starts to get complicated (i.e. may require updates to other specs)
mDNS name with IP4?
good point - shouldn't matter that much, but IP4 seems like the safest choice.
Agreed to use mDNS + IP4. We'll reevaluate if this causes problems.
Fixed by
We have observed an interop issue in the experimental deployment. Endpoints can fail to parse the SDP when the c= line contains a FQDN. This is the current solution.
Well, at least we thought of the solution already :)

Revised text:
IPv4 and IPv6 addresses MUST expose a different mDNS name for each address. <ins> The mDNS name of an mDNS candidate MUST be used in the connection- address field of its candidate attribute.  When an mDNS candidate is the default candidate, its mDNS name MUST be used in the connection- address field of the SDP "c=" line.  Since an mDNS candidate also conceals its address family, the "c=" line SHOULD use "IP4" in the address-type field. </ins> Note that any server-reflexive candidates generated from an mDNS host candidate will have IP addresses as their transport addresses, rather than mDNS hostnames.  Because their transport addresses are different
Original text:
regarding whether an address is safe to expose.  If so, expose the candidate and abort this process. <del> Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE candidate's IP address.  If one exists, skip ahead to Step 6. </del>  Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local".

Reviewer comments:
PR for
In the section gather candidates, it says: "Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE candidate’s IP address. If one exists, skip ahead to Step 6." We, maybe, should clarify this refers to a registered mDNS hostname as produce by this spec, not another (possibly meaningful) name created in some other context.
Makes sense as an editorial cleanup.
Fixed by

Revised text:
regarding whether an address is safe to expose.  If so, expose the candidate and abort this process.  <ins> Check whether the ICE agent has previously generated, registered, and stored an mDNS hostname for this IP address as per Steps 3, 4, and 6.  If it has, skip ahead to Step 7. </ins> Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local".