IETF Logo Mail Archive

Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00

Ladislav Lhotka <lhotka@nic.cz> Mon, 19 December 2016 13:14 UTC

Return-Path: <lhotka@nic.cz>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEBB129A1E; Mon, 19 Dec 2016 05:14:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.1
X-Spam-Level:
X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YO5PT2Zj2iYO; Mon, 19 Dec 2016 05:14:51 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E06D129A20; Mon, 19 Dec 2016 05:14:50 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:691f:24b5:66f8:76be] (unknown [IPv6:2001:718:1a02:1:691f:24b5:66f8:76be]) by mail.nic.cz (Postfix) with ESMTPSA id 967DB75DBC; Mon, 19 Dec 2016 14:14:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1482153289; bh=YJHx5RcAP2rGd/zqh2R6rtjUjcZE3HZysDl+EFwT+zw=; h=From:Date:To; b=RA/l3pDfIHRGhpRbZFDkHk0HeAgJ0snJooHQvuNpZ2DECN49xHz3N+0vaBcYg6Eex NPMtNwkDUWBEFnbYqx2dkmytPqL05wGkj4uRnRZL/HSC88MVw0DiUVA1A3Jg0c2QUP 2oWFeAUxBvrwzUzdDJw2EhV3NkWZ7kCM7bfUxj80=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Ladislav Lhotka <lhotka@nic.cz>
In-Reply-To: <20161219124853.GB2012@elstar.local>
Date: Mon, 19 Dec 2016 14:14:49 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <357D486B-0EB0-45E6-9583-730AF0FBB260@nic.cz>
References: <CABCOCHQZJvCp2=Ay=nMfZPqwLkKe2OCZAZhTaKVryNEKThitNw@mail.gmail.com> <CAGyj0qOOJZg2b9UA2q7oAEkdEJaNLUd6n_Dc+CE5=U8N7ifsrw@mail.gmail.com> <F8614A0D-518C-4A05-BB7D-C460CD3D5972@nic.cz> <52c8547e61354c1a9adefc69ff07a4a7@XCH-RTP-013.cisco.com> <CABCOCHToDs98tr3o5Np1vjvKa9uMS_MWKJZHo8GQtNj_1xXEiQ@mail.gmail.com> <004101d25589$a0cd5f20$e2681d60$@gmail.com> <CABCOCHTnCu4uE=da2Z+rOArGBoMXcicsofgLQP8LPLGkR-ho5Q@mail.gmail.com> <m2mvfyr3jd.fsf@birdie.labs.nic.cz> <001001d259cf$3d5a0de0$b80e29a0$@hansfords.net> <462EE5E8-2FBD-4946-93B5-81E048AB3BE2@nic.cz> <20161219124853.GB2012@elstar.local>
To: Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de>
X-Mailer: Apple Mail (2.3259)
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/BzieZ-Ykpri9Jyhr10_9auYcC0U>
Cc: NetMod WG Chairs <netmod-chairs@ietf.org>, NetConf WG Chairs <netconf-chairs@ietf.org>, NetMod WG <netmod@ietf.org>, Netconf <netconf@ietf.org>
Subject: Re: [Netconf] [netmod] WG adoption poll draft-nmdsdt-netmod-revised-datastores-00
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Dec 2016 13:14:52 -0000

> On 19 Dec 2016, at 13:48, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> 
> On Mon, Dec 19, 2016 at 11:37:57AM +0100, Ladislav Lhotka wrote:
>> 
>> I am not proposing to ban candidate or something but IMO it needn't be part of the base NETCONF (or whatever protocol) spec.
>> 
> 
> Lets recall that candidate is a _capability_. Nobody is required to
> implement it.

Yes, this is what I wrote. My point is that this capability could/should be moved out of the NETCONF spec to a separate document. The latter can then be modified without affecting the former. 

> 
>> A typical problem of candidate combined with NACM is that user A edits item X and B edits Y in candidate. If B doesn't have write access to X and A to Y, then none of them is able to make a commit.
>> 
> 
> The problem is caused by allowing users with inconsistent access
> rights to both use candidate. So you get what you asked for. But I

Well, as soon as you let clients manage their private data (user accounts, routing instances etc.) you get these "inconsistent" access rights automatically.

> assume you can still do <discard-changes> and recover.

..., or find somebody with superuser privileges to perform the commit, but it is clumsy either way. Automated solutions are likely to break.

Lada

> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

v2.23.0 | Report a Bug | By Email