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

Andy Bierman <ietf@andybierman.com> Thu, 13 August 2009 20:55 UTC

Return-Path: <ietf@andybierman.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91AA728C0E2 for <secdir@core3.amsl.com>; Thu, 13 Aug 2009 13:55:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.432
X-Spam-Level:
X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFd8JRqMAJPq for <secdir@core3.amsl.com>; Thu, 13 Aug 2009 13:55:12 -0700 (PDT)
Received: from smtp127.sbc.mail.sp1.yahoo.com (smtp127.sbc.mail.sp1.yahoo.com [69.147.65.186]) by core3.amsl.com (Postfix) with SMTP id EBAC828C0E3 for <secdir@ietf.org>; Thu, 13 Aug 2009 13:55:12 -0700 (PDT)
Received: (qmail 1344 invoked from network); 13 Aug 2009 20:53:38 -0000
Received: from unknown (HELO ?192.168.0.10?) (ietf@67.125.157.61 with plain) by smtp127.sbc.mail.sp1.yahoo.com with SMTP; 13 Aug 2009 20:53:37 -0000
X-YMail-OSG: aksmePEVM1lUEdReSWXKC6hvxO_2ZkZsSEmDEMi75FbJzsCbtsHecXpnSQE.w_I8gTdAFvYyselTnrxymMzu.J4NvsoZzTTAbBgFPgiC5P6hXAR3.Yo6OgXrFVHL635zb8uNN.IaRjZd.3r7wf87eFwBtR0XvLo6Rj3YCZUEk68jxkY_bovhSKLGU3JVv3lvmIzrWCDd9OwTZOUEaDy59.r3Tt6Zvu63.6TFFTmVZUGUQa8YFfzV1j5jrFks9o8JYybIXKD9Kbz8cVhZ8LnN4WzwtrfJHgqQ_m2HcFJPEtLHYakqS.vLPTmKZmQzG6_PBYbiG88wKeCp5j9f
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A847DB3.2050209@andybierman.com>
Date: Thu, 13 Aug 2009 13:55:15 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: Wes Hardaker <wjhns1@hardakers.net>
References: <AC6674AB7BC78549BB231821ABF7A9AE8E775BCA45@EMBX01-WF.jnpr.net> <016701ca1bf7$400ac480$0601a8c0@allison> <AC6674AB7BC78549BB231821ABF7A9AE8E777C002A@EMBX01-WF.jnpr.net> <4A83FA7D.9040209@bwijnen.net> <AC6674AB7BC78549BB231821ABF7A9AE8E777C00E6@EMBX01-WF.jnpr.net> <4A8430BE.2050701@andybierman.com> <sdk517cuw1.fsf@wes.hardakers.net>
In-Reply-To: <sdk517cuw1.fsf@wes.hardakers.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "draft-ietf-netconf-partial-lock@tools.ietf.org" <draft-ietf-netconf-partial-lock@tools.ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Aug 2009 20:55:13 -0000

Wes Hardaker wrote:
>>>>>> On Thu, 13 Aug 2009 08:26:54 -0700, Andy Bierman <ietf@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