jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-quic-load-balancers

Commentary: Secure ciphers are much more important for Shared State Retry than for the load balancer stuff and Initial Encryption . Therefore , some crypto agility to allow this mechanism to adapt as ciphers deprecate would be good . The key sequence can also imply a cipher , so we 'll add that to the data model . Some fields will vary length based on the cipher . We should also make it so everyone MUST support AES128 - GCM .
Shared-state Retry Services use the AES-128-ECB cipher.  Future
standards could add new algorithms that use other ciphers to provide
cryptographic agility in accordance with RFC7696.  Retry Service and
server implementations SHOULD be extensible to support new
algorithms.
Draft: draft-ietf-quic-load-balancers

Commentary: Made the changes to merge this . 
 Hi  : The defination of and brought me a great confusion when I implement the share - state retry service . Though finally I got what the draft want to express , I still suggest we should give more information about them According to section 1.5 of rfc5084 : According to section 3.4 of rfc5116 I guess that in current draft is the define in rfc5116 , is just a random value(or a incrementing number ) to generate . If I were true , please consider my PR for my suggestion . 
 Additional , it 's no need to make the length of ( current draft define ) variable , just 96 bit is sufficient . Current aes-128 - gcm related cipher suites all use this value 
 We can also add some illustration of , draft use in other place
The token key and IV are retrieved using the Key Sequence.
The nonce, N, is formed by combining the IV with the 96 bit unique
token number.  The 96 bits of the unique token number are left-
padded with zeros to the size of the IV.  The exclusive OR of the
padded unique token number and the IV forms the AEAD nonce.
The Key Sequence is the 8 bit identifier to retrieve the token key
and IV.
The AEAD IV, is a 96 bit data which produced by implementer's
custom AEAD IV derivation function.
The AEAD nonce, N, is formed by combining the AEAD IV with the 96
bit unique token number.  The 96 bits of the unique token number
are left-padded with zeros to the size of the IV.  The exclusive
OR of the padded unique token number and the AEAD IV forms the
AEAD nonce.
Draft: draft-ietf-quic-load-balancers

Commentary:   : a typo . AEAD checksum to AEAD ICV(defined in rfc4106 ) 
 Hi  : is not a standard name of AEAD verification message , which should be , see section 6 of rfc4106
The 96 bit unique token number is set to a random value using a
cryptography- grade random number generator.
The 96 bit unique token number is set to a random value using a
cryptography-grade random number generator.
The AEAD Checksum is computed as part of the AEAD encryption
process, and is verified during decryption.
The AEAD Integrity Check Value(ICV), defined in Section 6 of
RFC4106, is computed as part of the AEAD encryption process, and
is verified during decryption.
If the token checksum passes, and the ODCIL and RSCIL fields are both
zero, then this is a NEW_TOKEN token generated by the server.
Processing of NEW_TOKEN tokens is subtly different from Retry tokens,
as described below.
If the token verification passes, and the ODCIL and RSCIL fields are
both zero, then this is a NEW_TOKEN token generated by the server.
Processing of NEW_TOKEN tokens is subtly different from Retry tokens,
as described below.
Draft: draft-ietf-quic-load-balancers

Commentary: Sec 11.4 recommends either separating mistrustful servers by IP , or assigning them different config rotation bits . The text is not adequate . Separating by IP address undermines the privacy value of ECHO & DoH ( see the MAPRG IETF 110 talk ) Any sub - IP routing has to be SNI - switched ; if ECHO is operating , the load balancer must be a " client - facing server " in the ECHO architecture ( draft - ietf - tls - esni Sec 3.1 ) . Doing SNI switching as an ECHO server and then just encoding the result in the config rotation bits leaks the information they 're trying to conceal . It might be worth it to fix up the " arbitrary algorithm " text to consider possible SNI switching . As we migrate towards ECHO and DoH , maybe the best we can do is give all tenants on an IP the same config and try to obscure their co - tenancy as much as possible .
To avoid this, the configuration agent SHOULD issue QUIC-LB
configurations to mutually distrustful servers that have different
keys for encryption algorithms.  The load balancers can distinguish
these configurations by external IP address, or by assigning
different values to the config rotation bits (config-rotation).  Note
that either solution has a privacy impact; see multiple-configs.
These techniques are not necessary for the plaintext algorithm, as it
does not attempt to conceal the server ID.
To avoid this, the configuration agent SHOULD issue QUIC-LB
configurations to mutually distrustful servers that have different
keys for encryption algorithms.  In many cases, the load balancers
can distinguish these configurations by external IP address.
tenants can use 4-tuple routing in their CIDs (in which case they
SHOULD disable migration in their connections), which neutralizes
the value of QUIC-LB but preserves privacy.
When configuring QUIC-LB, administrators must evaluate the privacy
tradeoff considering the relative value of each of these properties,
given the trust model between tenants, the presence of methods to
obscure the domain name, and value of address migration in the tenant
use cases.
As the plaintext algorithm makes no attempt to conceal the server
mapping, these deployments SHOULD simply use a common configuration.
Draft: draft-ietf-quic-load-balancers

Commentary: This is in response to a post made on . 
 Thanks for the PR ! So as an interoperability standard , if the retry service encodes " 4000 " , what does the server do with that ? Do we need to add a config parameter for the time_t that serves as time 0 ? 
 Timestamps should be absolute , not relative , in which case I 'm not sure you need a 0 . There 's nothing special about midnight 1 January 1970 . 
 Ah , so you 're just suggesting declaring a later date to begin the epoch ? Makes sense 
 Why do we need to have a sential time ? If it 's a precision vs. range issue then shifting the epoch makes sense . 
 Sorry , I do n't know what " sential time " is . What are you proposing ? 
 What I 'm proposing is that we not treat any times differently . It 's not clear to me why 4000 needed special treatment . 
 4000 is just an example . The intent of using the epoch was to have common agreement on when tokens expire without any QUIC - LB - specific coordination . The current draft uses 1970 as a timebase , which absolutely makes integers longer than it needs to be . IIUC the PR does n't have any baseline so it 's unclear how the server and retry service are supposed to interpret each other 's expiration times . As we 're probably speaking past each other : what , precisely , does the integer in this field indicate ? 
 It 's the end of the validity period for the token in some convenient timebase . 
 Alright , we agree on that . So this PR is being a little less precise on synchronization , which is fine , but is n't addressing the fact that we 're counting from 1970 . Fair enough .
Both server and service must have access to Universal time, though
tight synchronization is unnecessary.
Both server and service must have time synchronized with respect to
one another to prevent tokens being incorrectly marked as expired,
though tight synchronization is unnecessary.
Draft: draft-ietf-quic-load-balancers

Commentary: As the config gets more complicated , the C - ish pseudocode is getting more unwieldy . YANG is the standard for configuration models , so I should bite the bullet and just figure out YANG .
The following pseudocode describes the data items necessary to store
a full QUIC-LB configuration at the server.  It is meant to describe
the conceptual range and not specify the presentation of such
configuration in an internet packet.  The comments signify the range
of acceptable values where applicable.
yang-model provides a YANG Model of the a full QUIC-LB configuration.
Draft: draft-ietf-quic-load-balancers

Commentary: Ended up rewriting the Retry Requirements for shared - state while adding the bit about port verification . Inspired by the review here :
If the token checksum passes, and the ODCIL and RSCIL fields are both
zero, then this is an expired NEW_TOKEN token generated by the
server.  An active Retry Service MUST drop the packet and issue a
Retry packet with the appropriate token.
The service SHOULD drop packets if the Timestamp of the retry token
points to a past date; however, in order to allow for clock skew, it
SHOULD NOT drop packets if the Timestamp merely points to a a few
seconds in the past.
It SHOULD forward packets if the AEAD checksum and the Timestamp can
be verified, regardless of the other fields.
However, the service MUST NOT decrypt or validate tokens if there is
a NAT between it and the servers.
In inactive mode, the service SHOULD forward all packets to the
server so that the server can issue an up-to-date token to the
client.
In inactive mode, the Retry service forwards all packets without
further inspection or processing.
Retry services MUST NOT issue Retry packets except where explicitly
allowed below, to avoid sending a Retry packet in response to a Retry
token.
If the token checksum passes, and the ODCIL and RSCIL fields are both
zero, then this is a NEW_TOKEN token generated by the server.
Processing of NEW_TOKEN tokens is subtly different from Retry tokens,
as described below.
The service SHOULD drop a packet containing a token where the ODCIL
is greater than zero and less than the minimum number of octets for a
client-generated CID (8 in QUIC version 1).  The service also SHOULD
drop a packet containing a token where the ODCIL is zero and RSCIL is
nonzero.
If the Timestamp of a token points to time in the past, the token has
expired; however, in order to allow for clock skew, it SHOULD NOT
consider tokens to be expired if the Timestamp encodes a few seconds
in the past.  An active Retry service SHOULD drop packets with
expired tokens.  If a NEW_TOKEN token, the service MUST generate a
Retry packet in response.  It MUST NOT generate a Retry packet in
response to an expired Retry token.
If a Retry token, the service SHOULD drop packets where the port
number encoded in the token does not match the source port in the
encapsulating UDP header.
All other packets SHOULD be forwarded to the server.
Draft: draft-ietf-quic-load-balancers

Commentary: There are so many variable length fields that the ASCII art does n't serve much of a purpose . Just switch to the notation used in quic - transport for the various CID and token formats .
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.
CR: Config Rotation bits.
CID Len: Length Self-Description (if applicable).  Encodes the length
of the Connection ID following the First Octet.
Config Rotation: Indicates the configuration used to interpret the
CID.
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.
Draft: draft-ietf-quic-load-balancers

Commentary: 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 at the same time . 
 LGTM . A suggestion , but I 'm OK either way .
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.
Draft: draft-ietf-quic-load-balancers

Commentary: Less emphasis on load balancers , more on the other stuff . More text on the use cases and less on " how " .
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.
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.
Draft: draft-ietf-quic-load-balancers

Commentary: 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 ) , I just think that there is no need for quic lb considering sni
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.
Draft: draft-ietf-quic-load-balancers

Commentary: 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 ? 
 have a look at the PR , please
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.
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).
Draft: draft-ietf-quic-load-balancers

Commentary: Make it clear that the server has to provide the client with a compliant  if the client is n't already using one . 
 Dear sir , As you know , there is no bit in the cid to mark whether the cid encoded the server info or not . In this case , no matter the server info encoded or not , the load balancer needs to decrypt or decode the cid . Do you think this is a useless try when the packet is the first initial packet ? Do you think this is a useful idea to expand the cid format to use the first bit to mark the cid encoded or not ? However , in this case , the client need to obey the rule . 
 In fact , there is a bit . If the first two bits are ' 11 ' that means that the server did n't encode its ID and the load balancer should use 4 - tuple routing : The very first packet usually has a CID chosen by the client , which knows nothing about QUIC - LB . The beginning of Section 4 is mostly about how load balancers should handle these . 
 OK , I almost have forgot the first two Config Rotation bits can be used to mark the cid server info 's validity . However , in this case , I want to know , for the very first packet , will the draft suggest the clients to generate the dcid with the first two bits " 11 " , if they know the QUIC - LB used . As , if so , the QUIC - LB know all packets ' cid information to prevent useless decode / decrypt try for the very first packet . 
 No , this draft does not assume client cooperation at all . The very beginning of Section 4 explains how to handle client - generated CIDs . 
 Thanks for your reply . Actually , I understand your works and Section 4 . However , my point is that , even this draft does not assume client cooperation at all , this draft can suggest the client to generate a cid with 11 for the very first initial packet . This is useful for QUIC - LB if client obeys the rule , if not , the Section 4 also works well . 
 In I 'm adding CR bits as a reason for noncompliance . It 's fine if the client wants to set ' 11 ' , but I do n't think it 's important to do that . At most all we 're saving the LB is a very small decrypt operation . 
 Even thought the decryption has a low consumption , I insist that the cost can be avoided . I admit that the lb ca n't assume client cooperation at all , however , the draft can suggest the client to obey the rule : " As , it is impossible for the client to know the server information at the beginning of the QUIC conn , so the DCID in the initial ca n't encode the server info , in this case , the  should make the first two bits with " 11 " . "
The config rotation bits config-rotation may not correspond to an
active configuration.
Servers that receive packets with noncompliant CIDs MUST use the
available mechanisms to induce the client to use a compliant CID in
future packets.  In QUIC version 1, this requires using a compliant
CID in the Source CID field of server-generated long headers.
Draft: draft-ietf-quic-load-balancers

Commentary: Updated the test vectors for the latest version of the spec , PCID , and made them usable to test server implementations .
Note that server IDs are opaque bytes, not integers, so there is no
notion of network order or host order.
Draft: draft-ietf-quic-load-balancers

Commentary: The encrypted CID format includes a zero - pad field that is used to detect whether the decryption succeeded or not . I suggest merging this field with the server ID field , and test whether the decryption succeed by checking whether the server ID is valid or not . This assumes that the server ID field is sparsely populated . For example , if there are just 256 servers , in theory a 1 - octed field would be sufficient ; instead , we could use a 4 or 5 octet server ID field that would be sparsely populated , allowing for error detection . This would allow for unified validity detection across all supported methods : clear text : verify that the server ID is valid ; obfuscated : the divider need to have the same size as the full length server ID ; the modulo is the server ID ; validity can be verified there . stream : decrypt and verify that the server - id is valid encrypt : decrypt and verify that the server - id is valid It would also allows for simplification of the configuration for the encrypted method , by specifying just one field instead of two . 
 Yes , I agree this is simpler with no cost at all . Care to do a PR ?
A field that should be all zeroes after decryption may not be so.
The configuration agent selects a zero-padding length.  This SHOULD
be at least four octets to allow detection of non-compliant DCIDs.
The server ID and zero- padding length MUST sum to no more than 16
octets.  They SHOULD sum to no more than 12 octets, to provide
servers adequate space to encode their own opaque data.
They server ID length MUST be no more than 16 octets and SHOULD sum
to no more than 12 octets, to provide servers adequate space to
encode their own opaque data.
The decrypted plaintext contains the server id, zero padding, and
opaque server data in that order.  The load balancer uses the server
ID octets for routing.
When generating a routable connection ID, the server MUST choose a
connection ID length between 17 and 20 octets.  The server writes its
provided server ID into the server ID octets, zeroes into the zero-
padding octets, and arbitrary bits into the remaining bits.  These
arbitrary bits MAY encode additional information.  Bits in the first,
eighteenth, nineteenth, and twentieth octets SHOULD appear
essentially random to observers.  The first octet is reserved as
described in first-octet.
The decrypted plaintext contains the server id and opaque server data
in that order.  The load balancer uses the server ID octets for
routing.
When generating a routable connection ID, the server MUST choose a
connection ID length between 17 and 20 octets.  The server writes its
provided server ID into the server ID octets and arbitrary bits into
the remaining bits.  These arbitrary bits MAY encode additional
information.  Bits in the eighteenth, nineteenth, and twentieth
octets SHOULD appear essentially random to observers.  The first
octet is reserved as described in first-octet.
Draft: draft-ietf-quic-load-balancers

Commentary: Added language about ICMP packets . 
 QUIC - LB LBs will not have the ability to properly route ICMP PTB messages without some additional work . 1 ) Servers SHOULD prepend a garbage Handshake packet to their MSS Probes , so that the SCID is there . 2 ) LBs SHOULD learn to parse these to extract the SCID and route them as they would a packet with that DCID . Alternatively , it could keep track of client  / ports and their mapping to servers . 
 Looks good to me . One minor suggestion on text change , but feel free to ignore it .
For protocols where 4-tuple load balancing is sufficient, it is
straightforward to deliver ICMP packets from the network to the
correct server, by reading the IP and transport-layer headers to
obtain the 4-tuple.  When routing is based on connection ID, further
measures are required, as most QUIC packets that trigger ICMP
responses will only contain a client-generated connection ID that
contains no routing information.
To solve this problem, load balancers MAY maintain a mapping of
Client IP and port to server ID based on recently observed packets.
Alternatively, servers MAY implement the technique described in
Section 14.4.1 of QUIC-TRANSPORT to increase the likelihood a Source
Connection ID is included in ICMP responses to Path Maximum
Transmission Unit (PMTU) probes.  Load balancers MAY parse the echoed
packet to extract the Source Connection ID, if it contains a QUIC
long header, and extract the Server ID as if it were in a Destination
CID.