Original text:
The expand_left() function outputs 16 octets, with its first argument in the most significant bits, its second argument in the least <del> significant byte, and zeros in all other positions.  Thus, </del>  expand_right() is similar, except that the second argument is in the <del> most significant byte, and the first argument is in the least significant bits.  Therefore, </del>  Similarly, truncate_left() and truncate_right() take the most significant and least significant bits, respectively, from a example, 0x7040b81b55ccf3 would split into a left_0 of 0x7040b81 and right_0 of 0xb55ccf3. <del> Encrypt the result of expand_left(left_0) to obtain a ciphertext. </del>  XOR the least significant bits of the ciphertext with right_0 to form right_1. Thus steps 3 and 4 can be expressed as "right_1 = right_0 ^ <del> truncate_right( AES_ECB(key, expand_left(left_0, 0x01)), </del>  len(right_0)) " Repeat steps 3 and 4, but use them to compute left_1 by expanding <del> and encrypting right_1 with the most significant octet as 0x02 and XOR the results with left_0. </del>  "left_1 = left_0 ^ truncate_left( AES_ECB(key, <del> expand_right(right_1, 0x02)), len(left_0)) " </del>  Repeat steps 3 and 4, but use them to compute right_2 by expanding <del> and encrypting left_1 with the least significant octet as 0x03 and XOR the results with right_1. </del>  "right_2 = right_1 ^ truncate_right( AES_ECB(key, <del> expand_left(left_1, 0x03)), len(right_1)) " </del>  Repeat steps 3 and 4, but use them to compute left_2 by expanding <del> and encrypting right_2 with the most significant octet as 0x04 and XOR the results with left_1. </del>  "left_2 = left_1 ^ truncate_left( AES_ECB(key, <del> expand_right(right_2, 0x04)), len(left_1)) " </del>  The server concatenates left_2 with right_2 to form the ciphertext CID, which it appends to the first octet. server ID is longer, a fourth pass is necessary: "right_0 = right_1 ^ truncate_right(AES_ECB(key, expand_left(left_0, <del> 0x01))) " </del>  and the load balancer has to concatenate left_0 and right_0 to obtain the complete server ID. design decisions that could impact the operation of QUIC-LB. The maximum Connection ID length could be below the minimum necessary <del> for one or more encoding algorithms. </del>  unroutable provides guidance about how load balancers should handle unroutable DCIDs.  This guidance, and the implementation of an

Reviewer comments:
in accordance with the 2nd crypto review
In the second crypto review () there was a note that plaintexts of different lengths might end up with similar results, if the extra bits were zeros. The suggestion to fix this was to update the path index to also include the length.
Looks good, except for the missing parenthesis.

Revised text:
The expand_left() function outputs 16 octets, with its first argument in the most significant bits, its second argument in the least  <ins> significant byte, its third argument in the second least significant byte, and zeros in all other positions.  Thus, </ins> expand_right() is similar, except that the second argument is in the  <ins> most significant byte, the third is in the second most significant byte, and the first argument is in the least significant bits. Therefore, </ins> Similarly, truncate_left() and truncate_right() take the most significant and least significant bits, respectively, from a example, 0x7040b81b55ccf3 would split into a left_0 of 0x7040b81 and right_0 of 0xb55ccf3.  <ins> Encrypt the result of expand_left(left_0, index)) to obtain a ciphertext, where 'index' is one octet: the two most significant bits of which are 0b00, and the six least significant bits are the length of the resulting connection ID in bytes, cid_len. </ins> XOR the least significant bits of the ciphertext with right_0 to form right_1. Thus steps 3 and 4 can be expressed as "right_1 = right_0 ^  <ins> truncate_right( AES_ECB(key, expand_left(left_0, cid_len, 1)), </ins> len(right_0)) " Repeat steps 3 and 4, but use them to compute left_1 by expanding  <ins> and encrypting right_1 with the most significant octet as the concatenation of 0b01 and cid_len, and XOR the results with left_0. </ins> "left_1 = left_0 ^ truncate_left( AES_ECB(key,  <ins> expand_right(right_1, cid_len, 2)), len(left_0)) " </ins> Repeat steps 3 and 4, but use them to compute right_2 by expanding  <ins> and encrypting left_1 with the least significant octet as the concatenation of 0b10 and cid_len, and XOR the results with right_1. </ins> "right_2 = right_1 ^ truncate_right( AES_ECB(key,  <ins> expand_left(left_1, cid_len, 3), len(right_1)) " </ins> Repeat steps 3 and 4, but use them to compute left_2 by expanding  <ins> and encrypting right_2 with the most significant octet as the concatenation of 0b11 ands cid_len, and XOR the results with left_1. </ins> "left_2 = left_1 ^ truncate_left( AES_ECB(key,  <ins> expand_right(right_2, cid_len, 4), len(left_1)) " </ins> The server concatenates left_2 with right_2 to form the ciphertext CID, which it appends to the first octet. server ID is longer, a fourth pass is necessary: "right_0 = right_1 ^ truncate_right(AES_ECB(key, expand_left(left_0,  <ins> 1 + cid_len))) " </ins> and the load balancer has to concatenate left_0 and right_0 to obtain the complete server ID. design decisions that could impact the operation of QUIC-LB. The maximum Connection ID length could be below the minimum necessary  <ins> to use all or part of this specification.  The minimum Connection ID length could exceed the limits in this specification. </ins> unroutable provides guidance about how load balancers should handle unroutable DCIDs.  This guidance, and the implementation of an