jiebi/CodeConvo huggingface dataset:
Code change:
and .
In light of , NAME concerns about the framework, and NAME declining interest in implementing, I think it's time to simply eliminate this from the document.
Thanks for all the hard work, but sorry to be the cause of it.
Fixed by
How does a dynamic framework survive an HA handover? It would seem to lose all the SID allocations and break all connections.

Related discussion:
text: QUIC-LB requires common configuration to synchronize understanding of encodings and guarantee explicit consent of the server. <del> The load balancer and server MUST agree on a routing algorithm, server ID allocation method, and the relevant parameters for that algorithm. </del> <ins> The load balancer and server MUST agree on a routing algorithm and the relevant parameters for that algorithm. </ins> All algorithm configurations can have a server ID length, nonce length, and key.  However, for Plaintext CID, there is no key. <del> If server IDs are statically allocated, the load balancer MUST receive the full table of mappings, and each server must receive its assigned SID(s), from the configuration agent. </del> <ins> The load balancer MUST receive the full table of mappings, and each server must receive its assigned SID(s), from the configuration agent. </ins> Note that server IDs are opaque bytes, not integers, so there is no notion of network order or host order.
Code change:
and .
In light of , NAME concerns about the framework, and NAME declining interest in implementing, I think it's time to simply eliminate this from the document.
Thanks for all the hard work, but sorry to be the cause of it.
Fixed by
How does a dynamic framework survive an HA handover? It would seem to lose all the SID allocations and break all connections.

Related discussion:
text: fewer than 2^40 tokens are generated with a single key, the risk of collisions is lower than 0.001%. <del> 11.8. When using Dynamic SID allocation, the load balancer's SID table can be as large as 2^56 entries, which is prohibitively large.  To constrain the size of this table, servers are encouraged to accept as few SIDs as possible, so that the remainder do not enter the load balancer's table. </del> 12. There are no IANA requirements.
Code change:
The CID format figure has been removed since draft-ietf-quic-load-balancers-08

Related discussion:
text: The Stream Cipher CID algorithm provides cryptographic protection at the cost of additional per-packet processing at the load balancer to <del> decrypt every incoming connection ID.  The CID format is depicted below. </del> <ins> decrypt every incoming connection ID. </ins> 5.2.1.
Code change:
URL is probably not your intent, but that is what you get with this phrasing. I think that the point is that the values are not predictable to entities other than the one generating it. This appears in several places in the document.
Well URL uses "indistinguishable from random" :-) But OK, I'll seek a new formulation.

Related discussion:
text: octet of the Connection ID are reserved to express the length of the following connection ID, not including the first octet. <del> A server not using this functionality SHOULD make the six bits appear to be random. </del> <ins> A server not using this functionality SHOULD choose the six bits so as to have no observable relationship to previous connection IDs issued for that connection. </ins> 2.4.
Code change:
URL is probably not your intent, but that is what you get with this phrasing. I think that the point is that the values are not predictable to entities other than the one generating it. This appears in several places in the document.
Well URL uses "indistinguishable from random" :-) But OK, I'll seek a new formulation.

Related discussion:
text: respective fields. If there is no key in the configuration, the server MUST fill the <del> Nonce field with bytes that appear to be random.  If there is a key, the server fills the nonce field with a nonce of its choosing.  See cid-entropy for details. </del> <ins> Nonce field with bytes that have no observable relationship to the field in previously issued connection IDs.  If there is a key, the server fills the nonce field with a nonce of its choosing.  See cid- entropy for details. </ins> The server MAY append additional bytes to the connection ID, up to the limit specified in that version of QUIC, for its own use.  These
Code change:
URL is probably not your intent, but that is what you get with this phrasing. I think that the point is that the values are not predictable to entities other than the one generating it. This appears in several places in the document.
Well URL uses "indistinguishable from random" :-) But OK, I'll seek a new formulation.

Related discussion:
text: two connection IDs to the same connection, client, or server.  In particular, all servers using a configuration MUST consistently add the same length to each connection ID, to preserve the linkability <del> objectives of QUIC-LB.  Any additional bytes SHOULD appear random unless individual servers are not distinguishable (e.g. any server using that configuration appends identical bytes to every connection ID). </del> <ins> objectives of QUIC-LB.  Any additional bytes SHOULD NOT provide any observable correlation to previous connection IDs for that connection (e.g., the bytes can be chosen at random). </ins> If there is no key in the configuration, the Connection ID is complete.  Otherwise, there are further steps, as described in the
Code change:
URL is probably not your intent, but that is what you get with this phrasing. I think that the point is that the values are not predictable to entities other than the one generating it. This appears in several places in the document.
Well URL uses "indistinguishable from random" :-) But OK, I'll seek a new formulation.

Related discussion:
text: Whether or not it implements the counter method, the server MUST NOT reuse a nonce until it switches to a configuration with new keys. <del> If the nonce is sent in plaintext, servers MUST generate nonces so that they appear to be random.  Observable correlations between plaintext nonces would provide trivial linkability between individual connections, rather than just to a common server. </del> <ins> Servers are forbidden from generating linkable plaintext nonces, because observable correlations between plaintext nonces would provide trivial linkability between individual connections, rather than just to a common server. </ins> For any algorithm, configuration agents SHOULD implement an out-of- band method to discover when servers are in danger of exhausting
Code change:
Attempt to , . Examples and test vectors not yet updated. PTAL at the description. Is the algorithm accurately described Are things clearer or not
NAME Thanks for all the formatting suggestions. It's cleaned up a bit, although I wasn't able to get aasvg to work. PTAL
Correction. I got aasvg to work but it did not look good at all, probably due to user incompetence. If you would like to submit a PR after this that is prettier, I would welcome it.
Stefan Kolbl points out this problem with the 4-pass method: Indeed, there are ways to avoid ugly and error-prone bit shifting while avoiding this property. In particular, we can always use expand-left, but just padding odd-bytes with zeros to preserve byte boundaries and avoid bit-shifting.
Fixed by
Several problems here: A lot of the description relies on examples rather than normative language. The split of a CID that has an odd length produces HEX sequences with an odd number of characters, which in many circumstances will be interpreted as being (left-)padded with 4 zero bits. If that happened, then bad things would occur. You really need to retain the number of bits. Step 3 passes two arguments to , when it has three. The encryption doesn't bind to the configuration that is in use; instead the high bits of the first octet are set to 0. The formatting of the operations wraps awkwardly. The operators that this uses (^ and primarily) aren't defined. The third input to seems to increment without explanation. Given the examples, I could no doubt work this all out satisfactorily, but that shouldn't be necessary.
Fixed by
A lot.
Yes, the new text seems clear, and correct.

Related discussion:
text: (i.e., the nonce is at least as large as the server ID).  If the server ID is longer, a fourth pass is necessary: <del> "right_0 = right_1 ^ truncate_right( AES_ECB(key, expand_left(left_0, cid_len, 1), len(right_1)) " </del> and the load balancer has to concatenate left_0 and right_0 to obtain the complete server ID.
Code change:
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?

Related discussion:
text: The extracted server mapping might not correspond to an active server. <del> A field that should be all zeroes after decryption may not be so. </del> Load balancers MUST forward packets with long headers with non- compliant DCIDs to an active server using an algorithm of its own choosing.  It need not coordinate this algorithm with the servers.
Code change:
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?

Related discussion:
text: The server ID will start in the second octet of the decrypted connection ID and occupy continuous octets beyond that. <del> 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. </del> <ins> 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. </ins> The configuration agent also selects an 16-octet AES-ECB key to use for connection ID decryption.
Code change:
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?

Related discussion:
text: octet to obtain the config rotation bits.  It then decrypts the subsequent 16 octets using AES-ECB decryption and the chosen key. <del> 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. </del> <ins> The decrypted plaintext contains the server id and opaque server data in that order.  The load balancer uses the server ID octets for routing. </ins> 4.4.3. When generating a routable connection ID, the server MUST choose a connection ID length between 17 and 20 octets.  The server writes its <del> 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. </del> <ins> 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. </ins> The server then encrypts the second through seventeenth octets using the 128-bit AES-ECB cipher.
Code change:
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.

Related discussion:
text: state Retry Service also needs the token key, and to be aware if a NAT sits between it and the servers. <del> 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. </del> <ins> yang-model provides a YANG Model of the a full QUIC-LB configuration. </ins> 9.
Code change:
Let's also consider data use cases here: Fallback to TURN has a severe effect on throughput in many cases.
Sure, could add a brief note on this.
The text here isn't normative, so I don't think we need to have a lengthy discussion of this - a few words should suffice.
Fixed by
LGTM

Related discussion:
text: away. When mDNS fails, ICE will attempt to fall back to either NAT hairpin, <del> if supported, or TURN relay, if not.  As noted in IPHandling, this may result in increased media latency and reduced connectivity/ increased cost (depending on whether the application chooses to use TURN). </del> <ins> if supported, or TURN relay if not.  This may result in reduced connectivity, reduced throughput and increased latency, as well as increased cost in case of TURN relay. </ins> One potential mitigation, as discussed in {#privacy}, is to not conceal candidates created from RFC4941 IPv6 addresses.  This permits
Code change:
PR for I considered referring to RFC6724, but that raises more questions than it answers it seems.
From Tom Pusateri: When more than one IPv4 or more than one IPv6 address is present, it seems like it would be better to first prefer an address that is on a shared network instead of always taking the first one (which doesn’t mean anything in DNS). If you want others to use the same address you should prefer the lowest one or the highest one or something sortable instead of the first one which could be different depending on hashing in a cache.
Discussed and agreement was to find a simple alternate algorithm.
Closed by PR

Related discussion:
text: ".local" name may happen through Unicast DNS as noted in RFC6762, Section 3. <del> An ICE agent that supports mDNS candidates MUST support the situation where the hostname resolution results in more than one IP address. In this case, the ICE agent MUST take exactly one of the resolved IP addresses and ignore the others.  The ICE agent SHOULD use the first IPv6 address resolved, if one exists, or the first IPv4 address, if not. </del> <ins> An ICE agent SHOULD ignore candidates where the hostname resolution returns more than one IP address. </ins> An ICE agent MAY add additional restrictions regarding the ICE candidates it will resolve using mDNS, as this mechanism allows
Code change:
Fixes URL
See URL for details
I added a step where we ignore the candidate in that case. The term 'ignore' should probable be refined as it is used both here and in the context of URL We might want to update ignore in URL context.
LGTM

Related discussion:
text: not end with ".local" or if the value contains more than one ".", then process the candidate as defined in RFC8445. <ins> If the ICE candidate policy is "relay", as defined in JSEP, ignore the candidate. </ins> Otherwise, resolve the candidate using mDNS.  The ICE agent SHOULD set the unicast-response bit of the corresponding mDNS query message; this minimizes multicast traffic, as the response is
Code change:
PR for
Seems all feedback is addresses?
Host ICE candidates, ICE host candidates, or something else?

Related discussion:
text: section 5.1.1, the candidate is processed as follows: Check whether the ICE agent has a usable registered mDNS hostname <del> resolving to the ICE host candidate's IP address.  If one exists, skip ahead to Step 6. </del> <ins> resolving to the ICE candidate's IP address.  If one exists, skip ahead to Step 6. </ins> Generate a unique mDNS hostname.  The unique name MUST consist of a version 4 UUID as defined in RFC4122, followed by ".local".
Code change:
PR for
Seems all feedback is addresses?
Host ICE candidates, ICE host candidates, or something else?

Related discussion:
text: Store the mDNS hostname and its related IP address in the ICE agent for future reuse. <del> Replace the IP address of the ICE host candidate with its mDNS </del> <ins> Replace the IP address of the ICE candidate with its mDNS </ins> hostname, and expose the candidate as usual. An ICE agent can implement this procedure in any way so long as it
Code change:
PR for
Seems all feedback is addresses?
Host ICE candidates, ICE host candidates, or something else?

Related discussion:
text: 2.2. <del> For any remote host ICE candidate received by the ICE agent, the following procedure is used: </del> <ins> For any remote ICE candidate received by the ICE agent, the following procedure is used: </ins> If the connection-address field value of the ICE candidate does not end with ".local" or if the value contains more than one ".",
Code change:
PR for
Seems all feedback is addresses?
Host ICE candidates, ICE host candidates, or something else?

Related discussion:
text: Otherwise, resolve the candidate using mDNS. <del> If it resolves to an IP address, replace the value of the ICE host candidate by the resolved IP address and continue processing of the candidate. </del> <ins> If it resolves to an IP address, replace the mDNS hostname of the ICE candidate with the resolved IP address and continue processing of the candidate. </ins> Otherwise, ignore the candidate.
Code change:
PR for
Seems all feedback is addresses?
Host ICE candidates, ICE host candidates, or something else?

Related discussion:
text: A peer-reflexive remote candidate could be learned and constructed from the source transport address of the STUN Binding request as an ICE connectivity check.  The peer-reflexive candidate could share the <del> same address as a remote host ICE candidate that will be signaled or has been signaled, received and is in the process of name resolution. In addition to the elimination procedure of redundant candidates defined in Section 5.1.3 of RFC8445, which could remove constructed peer-reflexive remote candidates, the address of any existing peer- reflexive remote candidate should not be exposed to Web applications by ICE agents that implement this proposal, as detailed in Section #guidelines. </del> <ins> same address as a remote mDNS ICE candidate whose name is in the process of being resolved.  In addition to the elimination procedure of redundant candidates defined in Section 5.1.3 of RFC8445, which could remove constructed peer-reflexive remote candidates, the address of any existing peer-reflexive remote candidate should not be exposed to Web applications by ICE agents that implement this proposal, as detailed in Section #guidelines. </ins> 3.
Code change:
PR for
Seems all feedback is addresses?
Host ICE candidates, ICE host candidates, or something else?

Related discussion:
text: When there is no user consent, the following filtering should be done to prevent private IP address leakage: <del> host ICE candidates with an IP address are not exposed as ICE candidate events. </del> <ins> ICE candidates with an IP address are not exposed as ICE candidate events. </ins> Server reflexive ICE candidate raddr field is set to 0.0.0.0 and rport to 0. <del> SDP does not expose any a=candidate line corresponding to a host ICE candidate which contains an IP address. </del> <ins> SDP does not expose any a=candidate line corresponding to an ICE candidate which contains an IP address. </ins> Statistics related to ICE candidates MUST NOT contain the resolved IP address of a remote mDNS candidate or the IP address of a peer-