On Thu, 13 Aug 2009 13:55:15 -0700, Andy Bierman
<ietf(_at_)andybierman(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf