Original text:
the new connection ID being negotiated via encrypted frames.  See Section 5.1 of QUIC-TRANSPORT.  2.7. The packet number field is always present in the QUIC packet header; forward the packets to that server without retaining connection state. <del> Server-generated connection IDs should seek to obscure any encoding, of routing identities or any other information.  Exposing the server mapping would allow linkage of multiple IP addresses to the same host if the server also supports migration.  Furthermore, this opens an attack vector on specific servers or pools. The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption.  Even when encrypted, a scheme could embed the unencrypted length of the Connection ID in the Connection ID itself, instead of remembering it, e.g. by using the first few bits to indicate a certain size of a well-known set of possible sizes with multiple values that indicate the same size but are selected randomly. QUIC_LB further specified possible algorithms to generate Connection IDs at load balancers. </del> 9.2. While sufficiently robust connection ID generation schemes will

Reviewer comments:
addresses issue
Is this something application designers need to think about or manage? I would hope QUIC implementations would handle this transparently. To the extent you have to configure something like QUIC-LB, that's a manageability thing.
Connection IDs are weird, in that they are important to both implementors / deployers (so applicability) as opposed to operators of networks that are not necessarily at the endpoints (so manageability)
There is text about Connection ID in both documents. We can double-check though that the text is well aligned and splitter correctly.
Well, implementors are explicitly out of scope according to the document's introduction. I would hope that apps didn't have to worry about Connection ID properties very much, or at all. Maybe there is knob or two for information exposure, at most, but I'd consider most of this text to be extraneous to the applicabilty draft.
I think we actually put some text in the wrong doc. PR moves this text from applicability to manageability.

Revised text:
the new connection ID being negotiated via encrypted frames.  See Section 5.1 of QUIC-TRANSPORT. <ins> Server-generated connection IDs should seek to obscure any encoding, of routing identities or any other information.  Exposing the server mapping would allow linkage of multiple IP addresses to the same host if the server also supports migration.  Furthermore, this opens an attack vector on specific servers or pools. The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption.  Even when encrypted, a scheme could embed the unencrypted length of the Connection ID in the Connection ID itself, instead of remembering it, e.g. by using the first few bits to indicate a certain size of a well-known set of possible sizes with multiple values that indicate the same size but are selected randomly. QUIC_LB further specified possible algorithms to generate Connection IDs at load balancers. </ins> 2.7. The packet number field is always present in the QUIC packet header; forward the packets to that server without retaining connection state.  9.2. While sufficiently robust connection ID generation schemes will