Wes Hardaker wrote: >>>>>> On Thu, 13 Aug 2009 08:26:54 -0700, Andy Bierman <i...@andybierman.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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
