Original text:
5.2. <del> The Stream Cipher CID algorithm provides cryptographic protection at the cost of additional per-packet processing at the load balancer to decrypt every incoming connection ID. </del>  5.2.1. considerations. The server encrypts the server ID using exactly the algorithm as <del> described in stream-cipher-load-balancer-actions, performing the </del>  three passes in reverse order. 5.3. <del> The Block Cipher CID Algorithm, by using a full 16 octets of plaintext and a 128-bit cipher, provides higher cryptographic protection and detection of unroutable connection IDs.  However, it also requires connection IDs of at least 17 octets, increasing overhead of client-to-server packets. </del>  5.3.1. map to the same server.  It could then apply analytical techniques to try to obtain the server encoding. <del> The Stream and Block Cipher CID algorithms provide robust protection against any sort of linkage.  The Plaintext CID algorithm makes no attempt to protect this encoding. </del>  Were this analysis to obtain the server encoding, then on-path observers might apply this analysis to correlating different client have each other's stateless reset token unless that key has changed in the interim. <del> The Stream Cipher and Block Cipher algorithms need to generate </del>  different cipher text for each generated Connection ID instance to protect the Server ID.  To do so, at least four octets of the CID are reserved for a nonce that, if used only once, will result in unique zero.  Whether or not it implements this method, the server MUST NOT reuse a nonce until it switches to a configuration with new keys. <del> Both the Plaintext CID and Block Cipher CID algorithms send parts of their nonce in plaintext.  Servers MUST generate nonces so that the plaintext portion appears to be random.  Observable correlations </del>  between plaintext nonces would provide trivial linkability between individual connections, rather than just to a common server.

Reviewer comments:
Some have noted that "Stream Cipher" is now a misnomer. So this PR renames them.

Revised text:
5.2.  <ins> The Encrypted Short CID algorithm provides cryptographic protection at the cost of additional per-packet processing at the load balancer to decrypt every incoming connection ID, unless the load balancer maintains state for the routing information of any given 4-tuple. </ins> 5.2.1. considerations. The server encrypts the server ID using exactly the algorithm as  <ins> described in encrypted-short-load-balancer-actions, performing the </ins> three passes in reverse order. 5.3.  <ins> The Encrypted Long CID Algorithm, by using a full 16 octets of plaintext and a 128-bit cipher, protects the server ID with a single encryption pass.  However, it also requires connection IDs of at least 17 octets, increasing overhead of client-to-server packets. </ins> 5.3.1. map to the same server.  It could then apply analytical techniques to try to obtain the server encoding.  <ins> The Encrypted CID algorithms provide robust protection against any sort of linkage.  The Plaintext CID algorithm makes no attempt to protect this encoding. </ins> Were this analysis to obtain the server encoding, then on-path observers might apply this analysis to correlating different client have each other's stateless reset token unless that key has changed in the interim.  <ins> The Encrypted Short and Encrypted Long algorithms need to generate </ins> different cipher text for each generated Connection ID instance to protect the Server ID.  To do so, at least four octets of the CID are reserved for a nonce that, if used only once, will result in unique zero.  Whether or not it implements this method, the server MUST NOT reuse a nonce until it switches to a configuration with new keys.  <ins> Both the Plaintext CID and Encrypted Long CID algorithms send parts of their nonce in plaintext.  Servers MUST generate nonces so that the plaintext portion appears to be random.  Observable correlations </ins> between plaintext nonces would provide trivial linkability between individual connections, rather than just to a common server.