Change:
Note that the Connection ID in the short header may be omitted.  This is a per-connection configuration option; if the Connection ID is not <del> present, then the peer omitting the connection ID will use the same local address for the lifetime of the connection. </del> <ins> present, then the peer omitting the connection ID needs to use the same local address for the lifetime of the connection and connection migration is not supported for that direction of the connection. </ins> 9.1.

Discussion:
addresses (partially at least)
The text says: “or prime the congestion controller in preparation for switching to the new path.” what does prime mean? and which section explains this function in the QUIC spec?
The idea here is that you can already e.g. estimate RTT or even open the congestion window before you switch. There was already some discussion previously (seePR ) if we want to have this in the document or say more or less. Maybe a question to the rest of the wg (in the next meeting)...?
Unsure about this in this ID: Isn't that suggesting a transport extension/mechanism update... rather than the applicable use?
I don't think it needs an extension. It can simply be done by the client. It's definitely not appropriate to specify a concrete algorithm in this document but it's just listed as one of the things that padding can be used during mitigation.
I'm really unsure about why text about priming is here and where the advice is located. I don't dispute that it can be done, or even that if done appropriately it can help, however it could also be done in a way that might also hinder. If PR 122 removes this word, then this topic can be discussed elsewhere in RFCs.
NAME PR was already merged a long time ago. I was just point at it to say that there has been previous discussion. As the label indicates, we plan to bring the for discussion to the meeting.
CC priming seems like an issue entirely internal to the QUIC implementation. Why should applications know or care about it? I suggest we simply delete this.
I like NAME suggestion.
is my proposal. It doesn't talk about priming/pre-heating anymore but it says what's possible and why this could be interesting for an application.
PR was merged.
We should probably make it clear what the application can do here (SPA for servers; maybe intentional migration for clients?) I'm not sure if migration is transparent to client applications or not.
The client application might have some knowledge if it's behind a NAT or not and as such might want to indicate to use Conn ID or not. We can make that more explicit in the text.
I did some small edits on the text in the connection migration section but NAME maybe you had something more in mind and want to propose more text?
This whole section should then also be moved to after the Conn ID section.

I like the move of text to the manageability draft. If it were me, I'd move "Server-Generated Connection ID" as well, as I don't think apps need to worry about it, but it's not a big deal. I think adding text about server preferred address is probably more important for this draft.
Added some more text in
NAME we think the current state of the draft addresses this issue; could you check and close this issue if so?