Re: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt

[Andy Bierman <[e-mail]>]

Wes Hardaker wrote:
>>>>>> On Thu, 13 Aug 2009 13:55:15 -0700, Andy Bierman <[e-mail]> 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