Wes Hardaker wrote:
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.
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf