Original text:
reset its congestion state (see migration-cc), so the port SHOULD only be changed infrequently. <del> Endpoints that use connection IDs with length greater than zero could have their activity correlated if their peers keep using the same destination connection ID after migration.  The goal is to ensure that packets sent on different paths cannot be correlated.  To </del>  fulfill this privacy requirement, endpoints that initiate migration and use connection IDs with length greater than zero SHOULD provide their peers with new connection IDs before migration.

Reviewer comments:
As discussed in Tokyo, forcing your peer to change a connection ID is still possible, but we would require a change in port in order to effect that. .
I don't remember this being what we agreed, and it's not necessary. You only need to change when you see a new path, not after a new CID. That's how we got rid of counting to infinity.
I'm not sure it is always well-defined when you are on a new path and you risk accidental linkage. I believe this was the thinking behind this.
IIRC, NAME is correct; we agreed to do this on peer address change. If you don't know you've been rebound and you reuse a CID, you've already linked yourself; the peer changing CID in response is pointless. If you either anticipate a rebinding or proactively change ports, and change both CID and address simultaneously, then it doesn't matter which of those triggers the peer to switch. If you switch CID without changing address, the address links you with fairly high probability anyway, so it doesn't really matter if the peer switches.
The recommendation exists to avoid linkability across a non-migrating change in connection ID.
I don't think that that's particularly useful, and it seems to create a bunch of new problems.
My recollection is what NAME says. I remember discussing that changing CID on both sides allows a flow to be broken up into flowlets, but if the address is the same on both sides, that's a pretty clear signal anyways. I am fine with requiring a change only if the peer's CID and address change.
That is not sufficient because the client could be migrating from domestic wifi to mobile, to train wifi, while the server always sees the IP address of the load balancer.
In this case the LB and the server should be regarded as the same thing, and it's the LB's job to convey that somehow.
FWIW, it helps when you have multiple connections coalesced onto a 5-tuple. An endpoints rotates the sending CIDs of all the connections at once, and that triggers the peer to rotate all of it's sending CIDs at once. Then, it becomes very hard for an observer to track the individual connections.
Tokyo:
That being (I'm closing ).
This was

Revised text:
reset its congestion state (see migration-cc), so the port SHOULD only be changed infrequently.  <ins> Endpoints that supply connection IDs with length greater than zero could have their activity correlated if their peers keep using the same destination connection ID after migration.  To ensure that packets sent on different paths cannot be correlated, endpoints SHOULD provide with new connection IDs before peers migrate.  To </ins> fulfill this privacy requirement, endpoints that initiate migration and use connection IDs with length greater than zero SHOULD provide their peers with new connection IDs before migration.