On 04/01/2015 01:38 AM, Randy Bush wrote: > why are you trying to rescue the case where a router (or cache) upgrades > versions in the middle of a session? > o upgrade should be very rare > o reload is relatively cheap > o and you are generating kinky corner cases to patch it > > session reset.
I wasn't trying to rescue it, I was trying to ensure a session reset. > the bloody router (or cache) will have reloaded anyway > and does not have the old state. Either end can upgrade to support version 1 before the other is ready; version 1 is only negotiated after both ends support it. I know that our cache implementation does not lose state unless the database is manually cleared, but I can't speak for other cache or router implementations. I agree that the simplest way to fix this issue is to require a reset query when a new version is negotiated, but I don't think that can be done by relying on state being lost. For reference, here's the text that I originally proposed: The cache MUST maintain a separate session for each protocol version it supports, and a router MUST NOT attempt to reuse session information across multiple protocol versions. If one of those requirements is too burdensome, either of them would be sufficient by itself to ensure that a reset query happens when the negotiated protocol version changes. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
