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

Andy Bierman <> Fri, 14 August 2009 15:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A7373A6D31 for <>; Fri, 14 Aug 2009 08:12:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.488
X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dKQNOrbE+N0e for <>; Fri, 14 Aug 2009 08:12:46 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id E939E3A6CDE for <>; Fri, 14 Aug 2009 08:12:45 -0700 (PDT)
Received: (qmail 81614 invoked from network); 14 Aug 2009 15:12:47 -0000
Received: from unknown (HELO ? (ietf@ with plain) by with SMTP; 14 Aug 2009 15:12:47 -0000
X-YMail-OSG: ftp8zPkVM1nRxYBaJI2kokGKf5TRXoqH5cu5CMadm.Ip9OIytD1fIxOmUkRhutuK1aJJJ2ZdEyW4q_imBxLZfQYq3RRZQDUOLLLCAbF6pv9Imtn.VwJ.v8NzX8Oq3YTbEFx.nQG7hlILgmUXpwgLkmpoHvtMY8KNkhOUT2nNlcE76Z7Y5Dqatf5QDv0N819thAgi7WPUVEw822M0VY1E8o1ECjMcCvbeRtsNtCanJV3MTfNx223Icz7qcTEZNKw82OPJ49AHj7gBsdvNXmUjZm.spjYhBWei2DDDNUnCaV9C9A0ojrM2xk.4d7m1WRjo_uUye8zTs.xjibubLCpHdV3Cp8DvtusAsl02r5FkhL8R
X-Yahoo-Newman-Property: ymail-3
Message-ID: <>
Date: Fri, 14 Aug 2009 08:12:27 -0700
From: Andy Bierman <>
User-Agent: Thunderbird (X11/20090608)
MIME-Version: 1.0
To: Wes Hardaker <>
References: <> <016701ca1bf7$400ac480$0601a8c0@allison> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Aug 2009 15:12:47 -0000

Wes Hardaker wrote:
>>>>>> On Thu, 13 Aug 2009 13:55:15 -0700, Andy Bierman <> 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).