Wes Hardaker wrote:
On Thu, 13 Aug 2009 08:26:54 -0700, Andy Bierman
<ietf(_at_)andybierman(_dot_)com> said:
AB> discard-changes only works because authorization is ignored,
AB> otherwise the agent would be deadlocked.
Huh???? why would discard-changes be authorization ignorant??? That's
just as unsafe (unless you're only discarding your own changes).
Oherwise the agent would deadlock.
discard-changes does not affect the running configuration.
It just resets the scratchpad database.
Why bother applying the ACLs before the edit operation
is attempted for real?
AB> Only the global lock operation defined in RFC 4741
AB> can prevent this problem.
The global lock has different issues.
The problem isn't with the locking. Locking, and partial locking are
good. It's with the global-level commit operation.
Requiring small embedded devices to serve as robust
database engines may be more expensive than
the rest of the code combined. We are coming from
an operational environment based on humans using the CLI,
which has no locking at all. The globally locked
candidate "edit, validate, and commit" model
is way better than anything we ever had in SNMP or CLI.
If concurrent edits instead of serialized edits are needed,
then the :writable-running + :partial-lock capabilities
support that.
Andy
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf