Persistence of alternates across network changes

[MikeBishop]

Alternates provided because of location (seattle.edge.net vs. sfc.edge.net) need to be cleared on network changes. (They’re probably direct pointers to individual nodes/datacenters.) Alternates provided because of capabilities (sni.edge.net as alternate of legacy.edge.net) shouldn’t be cleared on network changes, because they’re not location-dependent. (The names probably resolve to different IPs based on location at the DNS level, or they resolve to anycast addresses.)

Should there be a hint to the client that a particular alternate does/doesn’t need to be flushed on changes? Might impact the issues described in 9.2, but TLS should still mitigate without the flushing.

[martinthomson]

I think that flushing is the always-safe option. We can define extensions later if this turns out to be especially problematic (or the optimization that retention affords is especially attractive).

[mnot]

See also #2. It's not clear that flushing a alt-svc used for oppsec is the safest thing.

[mnot]

Discussed in Prague; add a parameter to do this now.