"Eric Voit (evoit)" <[email protected]> wrote: > > From: Juergen Schoenwaelder: Monday, December 12, 2016 6:10 PM > > > > The proper action in this case may be to kill the NETCONF session. > > > > It can be debated whether simply deleting state created by some other > > system > > (the subscription in this case) is a proper management approach since > > it may > > lead to undefined or erratic behaviour of other systems or to loops > > where some > > systems create state that others delete and so on. > > Wouldn't this have implications to I2RS or OpState?
I don't know about i2rs, but it doesn't impact "opstate". > How would an > Operator be able to focus only on the subset of dynamic state which is > currently impacted? > > An analogy might be someone with phone and faulty video service > connected over their broadband connection. They get on the phone with > an operator to troubleshoot their video, but the operator can't reset > the video CPE session without taking out the phone service as well. Maybe this is a good reason for using separate sessions, and not try to do too much in one. The problem is how you expect the client (and maybe server) to recover after a forced termination of an ongoing request. Note that there's no equivalent operation to kill an ongoing <get/> for example. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
