>>>>> On Thu, 13 Aug 2009 13:55:15 -0700, Andy Bierman <ietf@xxxxxxxxxxxxxxx> said: AB> Oherwise the agent would deadlock. AB> discard-changes does not affect the running configuration. No, but it does affect the other users notion of changes. You should never be allowed to discard changes that another user has made. AB> It just resets the scratchpad database. AB> Why bother applying the ACLs before the edit operation AB> is attempted for real? user 1: add new important policy configuration user 2: discard-changes user 1: commit Granted, user 1 should be using locks of some kind. To undo changes it's rather important that someone with proper authorization to the everything changed (IE, an admin) performs the discard. Or are you suggesting that one shouldn't ever have access control applied to the candidate store in the first place? (I hope not). AB> Requiring small embedded devices to serve as robust AB> database engines may be more expensive than AB> the rest of the code combined. We are coming from AB> an operational environment based on humans using the CLI, AB> which has no locking at all. The globally locked AB> candidate "edit, validate, and commit" model AB> is way better than anything we ever had in SNMP or CLI. If you look at history of operating just about anything, after it gets to a point where multiple operators need to scale things up you'll find that eventually stuff gets put into a multi-user revision database type system. We are far beyond the point where operators are editing single flat-files using "vi" and hitting "save" without any form of revision control. After that point, then went to locking version control systems (sccs? I'm forgetting the early version-control system names). Then people realized that caused huge headaches because the global file locking, although it prevented some types of problems, caused a bunch of other problems. Eventually more modern version control systems were developed that allowed people to simultaneously edit things and only get bothered when conflicts happen. This was a huge win, ask anyone who works with version control systems. But now, in this space, we're going back to the older methodologies of editing a single file and hoping that two people don't conflict (with or without a lock). I've said this before, but I'll repeat it now: netconf, from a protocol-operation point of view, is designed to work in a single-operator type environment. The instant you add multiple-users with or without different roles all these problems come up. This is actually just fine, but it needs to either: 1) be fixed so that these problems go away. 2) stop being advertised as a multi-operator type solution. I think "being fixed" is a great long term goal. But for right now, I'd suggest we simple say "this is version 1 at the moment and it is currently designed for use by single-operator systems". (And it doesn't prevent an external version-control system for being the master and pushing the config down. It just doesn't work on the device itself). -- Wes Hardaker Cobham Analytic Solutions _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf