Original text:
shifting necessary in the event that there are an odd number of octets. <del> The expand_left() function outputs 16 octets, with its first argument in the most significant bits, its second argument in the least significant byte, its third argument in the second least significant byte, and zeros in all other positions.  Thus, </del>  <del> expand_right() is similar, except that the second argument is in the most significant byte, the third is in the second most significant byte, and the first argument is in the least significant bits. Therefore, </del>  <del> Similarly, truncate_left() and truncate_right() take the most significant and least significant bits, respectively, from a ciphertext.  For example, to take 28 bits of a ciphertext: </del>  The example at the end of this section helps to clarify the steps described below. The server concatenates the server ID and nonce to create <del> plaintext_CID. </del>  The server splits plaintext_CID into components left_0 and right_0 <del> of equal length, splitting an odd octet in half if necessary.  For example, 0x7040b81b55ccf3 would split into a left_0 of 0x7040b81 and right_0 of 0xb55ccf3. </del>  <del> 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. </del>  <del> XOR the least significant bits of the ciphertext with right_0 to form right_1. </del>  <del> Thus steps 3 and 4 can be expressed as "right_1 = right_0 ^ truncate_right( AES_ECB(key, expand_left(left_0, cid_len, 1)), len(right_0)) " </del>  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 the concatenation of 0b01 and cid_len, and XOR the results with </del>  left_0. <del> "left_1 = left_0 ^ truncate_left( AES_ECB(key, expand_right(right_1, cid_len, 2)), 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 the concatenation of 0b10 and cid_len, and XOR the results with </del>  right_1. <del> "right_2 = right_1 ^ truncate_right( AES_ECB(key, expand_left(left_1, cid_len, 3), 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 the concatenation of 0b11 ands cid_len, and XOR the results with </del>  left_1. <del> "left_2 = left_1 ^ truncate_left( AES_ECB(key, expand_right(right_2, cid_len, 4), len(left_1)) " </del>  The server concatenates left_2 with right_2 to form the ciphertext <del> CID, which it appends to the first octet. </del>  The following example executes the steps for the provided inputs. Note that the plaintext is of odd octet length, so the middle octet

Reviewer comments:
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.

Revised text:
shifting necessary in the event that there are an odd number of octets.  <ins> When configured with both a key, and a nonce length and server ID length that sum to any number other than 16, the server MUST follow the algorith below to encrypt the connection ID. </ins>  <ins> 4.3.2.1. </ins>  <ins> The 4-pass algorithm is a four-round Feistel Network with the round function being AES-ECB.  Most modern applications of Feistel Networks have more than four rounds.  The implications of this choice, which is meant to limit the per-packet compute overhead at load balancers, are discussed in distinguishing-attacks. The server concatenates the server ID and nonce into a single field, which is then split into equal halves.  In successive passes, one of these halves is expanded into a 16B plaintext, encrypted with AES- ECB, and the result XORed with the other half.  The diagram below shows the conceptual processing of a plaintext server ID and nonce into a connection ID.  'FO' stands for 'First Octet'. 4.3.2.2. Two functions are useful to define: The expand(length, pass, input_bytes) function concatenates three arguments and outputs 16 zero-padded octets. The first argument 'length' is an 8-bit integer that reports the sum of the configured nonce length and server id length in octets, and forms the most significant octet of the output.  The 'length' argument MUST NOT exceed 28. The second argument is an 8-bit integer that is the 'pass' of the algorithm, and forms the second-most significant octet of the output. The third argument is a variable-length stream of octets, which is copied into the third-most significant octet of the output and beyond.  The length of this octet stream is half the 'length', rounded up.  All remaining octets of the output are zero. For example, Similarly, truncate(input, n) returns the first n octets of 'input'. Let 'half_len' be equal to 'plaintext_len' / 2, rounded up. 4.3.2.3. </ins> The example at the end of this section helps to clarify the steps described below. The server concatenates the server ID and nonce to create  <ins> plaintext_CID.  The length of the result in octets is plaintext_len. </ins> The server splits plaintext_CID into components left_0 and right_0  <ins> of equal length half_len.  If plaintext_len is odd, right_0 clears its first four bits, and left_0 clears its last four bits.  For example, 0x7040b81b55ccf3 would split into a left_0 of 0x7040b810 and right_0 of 0x0b55ccf3. </ins>  <ins> Encrypt the result of expand(plaintext_len, 1, left_0) using an AES-ECB-128 cipher to obtain a ciphertext. </ins>  <ins> XOR the first half_len octets of the ciphertext with right_0 to form right_1.  Steps 3 and 4 can be summarized as </ins>  <ins> If the plaintext_len is odd, clear the first four bits of right_1. </ins> Repeat steps 3 and 4, but use them to compute left_1 by expanding  <ins> and encrypting right_1 with pass = 2, and XOR the results with </ins> left_0.  <ins> If the plaintext_len is odd, clear the last four bits of left_1. </ins> Repeat steps 3 and 4, but use them to compute right_2 by expanding  <ins> and encrypting left_1 with pass = 3, and XOR the results with </ins> right_1.  <ins> If the plaintext_len is odd, clear the first four bits of right_2. </ins> Repeat steps 3 and 4, but use them to compute left_2 by expanding  <ins> and encrypting right_2 with pass = 4, and XOR the results with </ins> left_1.  <ins> If the plaintext_len is odd, clear the last four bits of left_2. </ins> The server concatenates left_2 with right_2 to form the ciphertext  <ins> CID, which it appends to the first octet.  If plaintext_len is odd, the four least significant bits of left_2 and four most significant bits of right_2, which are all zero, are stripped off before concatenation to make the resulting ciphertext the same length as the original plaintext. 4.3.2.4. </ins> The following example executes the steps for the provided inputs. Note that the plaintext is of odd octet length, so the middle octet