Wes Hardaker wrote: >>>>>> 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. > this assumes you have an access control model in mind. I do too -- they aren't the same. Without any standards for this, neither of us are wrong. > 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. > what is the NETCONF 'add new' operation? step 1 is very unclear. > 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). > I apply it to the candidate and to running, except discard-changes, otherwise the agent would deadlock often and that would be counter-productive to network operations. When you start with an awful design premises like locking should be optional to use, then you might end up with messy code. Nothing new there. > 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). > again -- when locking is optional to use, the database is never going to be very good. > > 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 disagree. The partial-lock feature is not needed in every environment. NETCONF supports the SQL-like model (write directly to the persistent datastore) and that is good enough. Why does the scratchpad model need to be per-session? That is nice-to-have, but not important. > 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). Andy _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf