By first look the changes seemed way too big for errata, but it seems they are getting narrowed down to something that could be actually done by errata.
If we want to do something bigger we can of course do 5723bis and do other things at the same time if needed. Paul Wouters writes: > > The following text: > > > >> MUST NOT send Delete Notifications and > > > > is unnecessary and technically incorrect, because if there is no > > connectivity > > (as turned out after liveness probe failed), the client _cannot_ > > send any message to the server. > > Please, remove it. > > There are cases where the client thinks it can send them, but it should > not. Eg if it connected to a wifi AP that has no more uplink. If it > sends the delete, and the connection would briefly allow packet flow, > then the server would delete the state and invalidate any tickets. So > I think it is important to clarify. And "cannot" is just a subset of > "MUST NOT". This of course would require you to implement and use the window size larger than one. If you use the default size of one, your one slot is already in use by the liveness check, and you can't send the next message until that is finished, and it will not be finished as network is broken... If your implementation actually uses window size larger than one, then it could waste its resources and send the delete using next message id, but I do not see any point in that. Why would any implementation do that? If they are tearing down the connection because other end is dead, why do the want to send message telling the other end the connection is now dead, if it does not reach it. Yes, you could have one way connection, where the other end can actually receive messages but you do not receive replies, but I do not think there is point of implementing feature for just such networks. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
