Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
Ladislav Lhotka <lhotka@nic.cz> Tue, 28 November 2017 10:28 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 35A05124BE8 for <netconf@ietfa.amsl.com>; Tue, 28 Nov 2017 02:28:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 js3GlP_Y15Uf for <netconf@ietfa.amsl.com>; Tue, 28 Nov 2017 02:28:31 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0175B1200F3 for <netconf@ietf.org>; Tue, 28 Nov 2017 02:28:29 -0800 (PST)
Received: from birdie8 (unknown [IPv6:2001:1488:fffe:12::380]) by mail.nic.cz (Postfix) with ESMTPSA id 7474963CBC; Tue, 28 Nov 2017 11:28:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1511864907; bh=0DfqW4W+omJ3dGqYMlXbUavsdZTcdMgMiVNLarZtUKk=; h=From:To:Date; b=dEbTsGMYf4aMYTyNYmP1v6WT/WtGOhrr8xai2/p9AO8uGrgh+Lit6JdZE5AMe4B0L JZREr6sllSkrekqo2oMV4FdgfHURhdu/LDvvJohQ5maWbPR7kF6WCoWYs1RIrncIFD psC1HQf7j9Msb+blabscdsPhC2TF+2pXArnJrG2I=
Message-ID: <1511864907.27324.15.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Andy Bierman <andy@yumaworks.com>
Cc: Netconf <netconf@ietf.org>
Date: Tue, 28 Nov 2017 11:28:27 +0100
In-Reply-To: <CABCOCHRyj3=rEeTxLSA=kBhzipVVbPhHYB69MvO5S4b29J_Y6A@mail.gmail.com>
References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> <CABCOCHT_5zHWf3mdNM+8uUd8sqZMKKiwVtr=O4C4BhNrbygNzw@mail.gmail.com> <4e2ff4c7-70bb-280d-b49d-423e70e7f42d@cisco.com> <CABCOCHSYYFrZxC11v_++adG2uCP7urxR=VOKX-+8zXA-qiBCTA@mail.gmail.com> <60763bcf-47d9-d538-f1b3-6d71e3c80d1d@cisco.com> <CABCOCHTEXwhAq6NzoAGHcC-EE19bXJ0kbqPS0hwJB5_+RtOfyg@mail.gmail.com> <e418e007-fbac-029d-9c77-ed33df3d233b@cisco.com> <c2663103-70c2-0f52-f24f-852462509e27@cisco.com> <e41c2a8f-5ed7-9f3e-6dc1-85182c66adbf@cisco.com> <CABCOCHQrSOgGEAPdz5TdGBCGBSPzgAspGRQkgQDr3=H4Xp9JSQ@mail.gmail.com> <d056fdcd-20a8-5459-24ea-81fcfe53e59b@cisco.com> <015101d36513$bba345e0$4001a8c0@gateway.2wire.net> <CABCOCHTg5x_3=u4fMVtF-Rn1T6+gH2ZLMKeo6z5iekUWNt3RXg@mail.gmail.com> <00a701d365ea$e207f000$4001a8c0@gateway.2wire.net> <CABCOCHQHDB_9vQ0W5uA+u__=sezGrVgNtvt==DQhbK1r2MsPUw@mail.gmail.com> <eef4d5a8-4185-24d7-36a7-0f5958804be2@cisco.com> <CABCOCHR-KPG69Ngzc=fb6cmcU4q+SEOt51AX=iYGYJR=pECxPg@mail.gmail.com> <b8b8c99b-4a4b-8c50-355e-724554bb5f23@cisco.com> <CABCOCHTRN4_UpDwKe6mjHs6V5dovZ7V0ZfBk=NG++Yru=3JU+w@mail.gmail.com> <1511801627.6244.39.camel@nic.cz> <CABCOCHRyj3=rEeTxLSA=kBhzipVVbPhHYB69MvO5S4b29J_Y6A@mail.gmail.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.2
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/bK07EnD2wSUOK-QXmA75cCqsRL8>
Subject: Re: [Netconf] draft-ietf-netconf-rfc6536bis: one week review of a specific change
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 28 Nov 2017 10:28:34 -0000
On Mon, 2017-11-27 at 09:20 -0800, Andy Bierman wrote: > > > On Mon, Nov 27, 2017 at 8:53 AM, Ladislav Lhotka <lhotka@nic.cz> wrote: > > On Mon, 2017-11-27 at 08:26 -0800, Andy Bierman wrote: > > > > > > > > > On Mon, Nov 27, 2017 at 7:44 AM, Robert Wilton <rwilton@cisco.com> wrote: > > > > > > > > On 27/11/2017 15:12, Andy Bierman wrote: > > > > > > > > > > On Mon, Nov 27, 2017 at 2:39 AM, Robert Wilton <rwilton@cisco.com> > > wrote: > > > > > > I do get the point that Tom is making here, and have quite a lot of > > > > > > sympathy for it. E.g. by automatically allowing the side effects of > > > > > > when/choice statements then we are introducing a potential security > > hole > > > > > > here that operators may find hard to be aware of and mitigate. > > > > > > It also seems odd to me that a client is allowed to implicitly > > remove > > > > > > some configuration through the side effect of a when/choice > > statement > > > > > > that they are not allowed to delete explicitly. > > > > > > The alternative of requiring appropriate access for the side- > > effects, > > > > > > seems like an intuitively safer design, but I also get Andy's > > concern > > > > > > that security isn't useful if it become so unwieldy that nobody uses > > it. > > > > > > So, I guess the question here is, do we have some concrete examples > > > > > > using real data models where the extra NACM delete rules would be > > > > > > required? If not then perhaps requiring the explicit access for > > side > > > > > > effects would be better. > > > > > > > > > > > > > > > > > > > > > Yes -- please provide some examples where it is better to force the > > > > > operator > > > > > to provide extra "delete" rules to allow false-when data nodes to be > > > > > deleted. > > > > > > > > > It seems to me that these rules would allow individual data structures > > to > > > > > be > > > > > removed by the client, that would not otherwise be possible. > > > > Yes, this is true. > > > > > > > > But it is still odd that they a client is allowed to delete the > > > > configuration, just not explicitly. I.e. it is strange that they > > are > > > > not allowed to put in a semantically equivalent request that explicitly > > > > deletes the configuration, they are only allowed to do it if the delete > > is > > > > implicit. This seems inconsistent. > > > > > > > > > > > > > > It is just as odd that a request to create /foo/case1 will work if > > nothing > > > from > > > the choice-stmt exists, but will fail if /foo/case2 has to be deleted in > > order > > > to create /foo/case1. > > > > Why is this odd? RFC 7950 says: > > > > The "choice" statement defines a set of alternatives, only one of > > which may be present in any one data tree. > > > > So it is quite clear that adding /foo/case1 makes the data tree invalid if > > /foo/case2 exists. > > > > > From a NACM POV, the rule to allow "create /foo/case1" works differently > depending on whether server auto-deletion is used. > > IMO, NACM controls client access, and auto-deletion is server access, > which is mandated by the specific YANG data-def statements. > > > > > > > > > > > > > > If 3 data structures need to be in place "when /foo exists" then > > > > > deleting 1 or 2 of them directly may not be desirable. Deleting > > > > > them all together (i.e., via when-false deletion) may be the intended > > > > > usage. > > > > If there is a dependency that all three exist then that may be better > > > > expressed with a must statement instead. > > > > > > > > > The vendor and operator need to be aware of the data model > > dependencies. > > > > > That said, how come CLI-based configuration does not have this > > problem? > > > > My experience of CLI based configurations do have these sorts of > > problems, > > > > and many more :-) > > > > > > > > > > > > > (Or rather, why has this problem been ignored for so long? Maybe it > > not > > > > > that real?) > > > > This may be the real crux of the argument: > > > > > > > > It probably doesn't make sense to use when statements on disjoint parts > > of > > > > the YANG schema (e.g. it does not make sense for the OSPF YANG model to > > > > depend on whether an interface it runs over has an IP address > > configured). > > > > Instead, a more normal usage would be a flag (e.g. like interface type) > > to > > > > allow/prevent certain child nodes from being available. In these > > scenarios, > > > > if a user is allowed to change the type of an interface then they are > > most > > > > likely allowed to change the other settings on the interface as well. > > > > > > > > So for 'normal' when statements, it probably doesn't make much > > difference > > > > whether or not explicit NACM access is required to the nodes being > > > > implicitly deleted because the client probably already has the necessary > > > > access rights. > > > > > > > > But for the 'corner case' when statement scenario, that are unlikely to > > be > > > > used, it still seems safer to require explicit access permissions than > > > > implicitly accepting the side effect with no NACM validation. > > > > > > > > > > > > > This is fine, except there is no way to tell a normal when from a corner- > > case > > > when. > > > > > > In all cases, the false-when evaluation means the node is not relevant to > > the > > > model anymore. > > > > The client that causes the when expression to become invalid may not be > > entitled > > to decide whether the node is relevant or not. > > > > > The YANG designers need to consider the impact of when statements on the data > model usage. > NACM needs to be used at a sufficiently course granularity and it is quite > possible > to setup NACM with inappropriate granularity, where intended access is blocked > and unintended access is allowed. > > > > > Same for a case that is being replaced by a different case. > > > In order for this NACM threat to be real. the YANG modeler needs to be > > wrong > > > about > > > whether the false-when states are actually irrelevant to the model in its > > new > > > state. > > > > The YANG modeller may be absolutely correct but other modules (out of his > > control) may change this. > > > > > The widespread use of vendor extensions and deviations makes it impossible to > focus on just the standard modules when considering access control. > Perhaps the best the IETF can do is identify YANG usage patterns that need to > considered > when configuring NACM. > > Another option is to create smarter NACM filters, based on tags, not data > nodes. > Data rules are very sharp knifes that need to be used with care. Eliminating side effects would make them considerably more robust. Rules about a particular instance should ideally fully determine what can happen with it - such rules would be easy to set up up and maintain. Lada > > > Lada > > > > Andy > > > > > > > > > > > Thanks, > > > > Rob > > > > > > > > > > > > > Andy > > > > > > > > > > > > > Thanks, > > > > > > Rob > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > On 25/11/2017 15:53, Andy Bierman wrote: > > > > > > > > > > > > > > On Sat, Nov 25, 2017 at 4:42 AM, t.petch <ietfc@btconnect.com> > > wrote: > > > > > > > > ----- Original Message ----- > > > > > > > > From: "Andy Bierman" <andy@yumaworks.com> > > > > > > > > To: "t.petch" <ietfc@btconnect.com> > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Nov 24, 2017 at 3:02 AM, t.petch <ietfc@btconnect.com> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > <inline> > > > > > > > > > > > > > > > > > > > > Tom Petch > > > > > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > > From: "Robert Wilton" <rwilton@cisco.com> > > > > > > > > > > Sent: Thursday, November 23, 2017 10:44 AM > > > > > > > > > > > > > > > > > > > > > Hi Andy, > > > > > > > > > > > > > > > > > > > > > > On 22/11/2017 18:09, Andy Bierman wrote: > > > > > > > > > > > > On Wed, Nov 22, 2017 at 5:41 AM, Benoit Claise wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi Rob, > > > > > > > > > > > > > > > > > > > > > > > > At that points in time, if it clarifies the spec. > > and > > > > > > > > the > > > > > > > > > > authors > > > > > > > > > > > > agree with this, let's do the right thing. > > > > > > > > > > > > > > > > > > > > > > > > I will add the new text if that is what the WG wants. > > > > > > > > > > > > > > > > > > > > > Having read this draft, I was undecided what the intended > > > > > > > > behavior > > > > > > > > > > > actually should be. > > > > > > > > > > > > > > > > > > > > > > The way that Yumapro and Tail-f have implemented this is > > > > > > > > reasonable, > > > > > > > > > > and > > > > > > > > > > > is probably also the way that I would implemented it. > > > > > > > > > > > > > > > > > > > > > > But I also think that it would be a reasonable > > implementation > > > > > > > > for > > > > > > > > a > > > > > > > > > > > server to calculate the full change set (taking account of > > > > > > > > side > > > > > > > > > > effects > > > > > > > > > > > from when and choice statements) to the datastore before > > > > > > > > checking > > > > > > > > the > > > > > > > > > > > "write data node access control" against the resultant > > change > > > > > > > > set. > > > > > > > > > > > > > > > > > > > > > > My interpretation is that the RFC text is ambiguous on > > what > > > > > > > > the > > > > > > > > > > correct > > > > > > > > > > > behavior is, and one could make a reasonable argument that > > the > > > > > > > > current > > > > > > > > > > > RFC actually specifies that the alternative behavior is > > > > > > > > correct, > > > > > > > > i.e. > > > > > > > > > > > requiring delete access even if a node is implicitly > > changes > > > > > > > > as a > > > > > > > > side > > > > > > > > > > > effect. E.g. section 3.2.3 of RFC 6536 states: > > > > > > > > > > > > > > > > > > > > > > If the protocol operation would result in the deletion > > of > > > > > > > > a > > > > > > > > > > datastore > > > > > > > > > > > node and the user does not have "delete" access > > permission > > > > > > > > for > > > > > > > > > > that > > > > > > > > > > > node, the protocol operation is rejected with an > > > > > > > > "access-denied" > > > > > > > > > > > error. > > > > > > > > > > > > > > > > > > > > Rob > > > > > > > > > > > > > > > > > > > > I have been reading that paragraph since this thread started > > and > > > > > > > > > > wondering how it could be thought unclear, what am I > > missing:-) > > > > > > > > > > > > > > > > > > > > To me it clearly states that the user must have the > > appropriate > > > > > > > > access > > > > > > > > > > for the consequences of whatever they do, be that 'when', > > > > > > > > 'choice' > > > > > > > > or > > > > > > > > > > anything else! Indeed, I see exactly that behaviour in > > > > > > > > operational > > > > > > > > > > (non-network) databases of which I am a user with limited > > > > > > > > privileges. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is not correct. > > > > > > > > > The server is the entity that is cleaning up false when-stmt > > or > > > > > > > > unselected > > > > > > > > > cases > > > > > > > > > for a choice-stmt. > > > > > > > > > > > > > > > > > > NACM does not prevent the sever from making any changes to the > > > > > > > > system. > > > > > > > > > It only affects the operations requested by a client. > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > My model is slightly different, that the server is a black box, > > with > > > > > > > > an > > > > > > > > interface through which I can make authorised changes. If > > something > > > > > > > > I > > > > > > > > do causes the deletion of something I am not allowed to delete, > > may > > > > > > > > be > > > > > > > > not even to read, well, we part company on the acceptability of > > > > > > > > that! > > > > > > > > > > > > > > > > I do accept, as Randy points out, that the situation is > > > > > > > > complicated. I > > > > > > > > am reminded of the issues that came up relating to the 'when' > > > > > > > > statement > > > > > > > > when preparing YANG 1.1. Yes, 'when' makes things possible and > > is > > > > > > > > very > > > > > > > > useful but at the same time, its side effects can be > > troublesome. I > > > > > > > > would like to wrap it up in a conceptual bubble so you could not > > > > > > > > have > > > > > > > > the sort of fine-grained access control that allows the case > > that > > > > > > > > Rob > > > > > > > > postulates to occur but have no idea what that might look like. > > And > > > > > > > > I > > > > > > > > don't know how much 'when' is used in that way in existing YANG > > > > > > > > modules - uh huh, more reading required. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > When the access control is too complicated, it does not get used. > > > > > > > Instead, the most likely access control is "everybody is the root > > > > > > > user". > > > > > > > The server pruning of false when/choice data nodes is considered > > > > > > > cleanup. > > > > > > > The pruned data is no longer relevant to the data model. This is > > the > > > > > > > indended > > > > > > > use, but when-stmt can easily be abused. > > > > > > > > > > > > > > The complex tangled web of dependencies is no worse > > > > > > > than it has been with CLI for 30 years, where every dependency is > > ad- > > > > > > > hoc > > > > > > > and probably undocumented. The granularity of CLI-based access > > control > > > > > > > is less granular than NACM. > > > > > > > > > > > > > > It is possible that vendors and operators are willing to spend > > hours > > > > > > > and days > > > > > > > figuring out how to tune the NACM rules to allow a specific edit > > to > > > > > > > work. > > > > > > > Of course the operator will not even be told by the server which > > nodes > > > > > > > are blocking the edit. That would be a security risk. > > > > > > > > > > > > > > IMO NACM will be completely unusable if rules are needed to allow > > > > > > > server cleanup of dead nodes. The additional NACM rules required > > > > > > > might provide more access than intended (unless lots of delete- > > only > > > > > > > rules are added). The huge jump in NACM rule management complexity > > is > > > > > > > a new security vulnerability, which might even be worse than the > > > > > > > vulnerability it is intended to fix. > > > > > > > > > > > > > > > > > > > > > > Tom Petch > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > My other thought was that given all the complexities of > > 'when' > > > > > > > > that > > > > > > > > > > emerged during the specification of YANG 1.1, perhaps, were > > I an > > > > > > > > > > implementor of this, I would take the easy option and ignore > > the > > > > > > > > side > > > > > > > > > > effects of 'when'; but I might feel guilty about doing so. > > > > > > > > > > > > > > > > > > > > If the new paragraphs go in as proposed, then I think that > > the > > > > > > > > two > > > > > > > > > > paragraphs you quote need changing else that section looks > > to me > > > > > > > > like an > > > > > > > > > > oxymoron. > > > > > > > > > > > > > > > > > > > > Tom Petch > > > > > > > > > > > > > > > > > > > > > An <edit-data> request that causes a when constraint to > > > > > > > > evaluate > > > > > > > > > > > differently does result in a deletion of those data nodes > > from > > > > > > > > the > > > > > > > > > > > datastore, and hence according to the text above, requires > > > > > > > > explicit > > > > > > > > > > > "delete" access permission to accomplish that. > > > > > > > > > > > > > > > > > > > > > > Clearly it would be an interop issue if different servers > > > > > > > > implemented > > > > > > > > > > > the NACM path based filtering differently. > > > > > > > > > > > > > > > > > > > > > > Hence why I think that it would be prudent for the draft > > to be > > > > > > > > more > > > > > > > > > > > explicit on when and choice statement handling. > > > > > > > > > > > > > > > > > > > > > > Rob > > > > > > > > > > > > > > > > > > > > > > > There have not been any comments on this issue. > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > Regards, Benoit. > > > > > > > > > > > >> > > > > > > > > > > > >> Hi Benoit, > > > > > > > > > > > >> > > > > > > > > > > > >> There is also one further, unrelated change that I > > am > > > > > > > > proposing > > > > > > > > > > > >> is made the draft before it is published, to help > > > > > > > > better > > > > > > > > > > clarify > > > > > > > > > > > >> the expected behavior. It isn't the end of the > > world if > > > > > > > > this > > > > > > > > > > > >> doesn't go in, but I think that it prevents > > sometime > > > > > > > > taking > > > > > > > > a > > > > > > > > > > > >> different, but IMO reasonable, interpretation of > > how > > > > > > > > "when" > > > > > > > > > > > >> statements are considered, and then having a future > > > > > > > > argument > > > > > > > > > > > >> about what behavior it specified in the standard. > > > > > > > > > > > >> > > > > > > > > > > > >> If we clarify it now, then it closes that door :-) > > > > > > > > > > > >> > > > > > > > > > > > >> I've proposed text to Andy and Martin on Monday, > > but > > > > > > > > I've > > > > > > > > not > > > > > > > > > > > >> heard back yet. > > > > > > > > > > > >> > > > > > > > > > > > >> Netconf email with proposed text attached. The text > > > > > > > > doesn't > > > > > > > > > > > >> necessarily have to match this, but personally I > > think > > > > > > > > that > > > > > > > > it > > > > > > > > > > is > > > > > > > > > > > >> useful if the draft says something on this. > > > > > > > > > > > >> > > > > > > > > > > > >> Thanks, > > > > > > > > > > > >> Rob > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> On 22/11/2017 13:25, Benoit Claise wrote: > > > > > > > > > > > >>> On 11/10/2017 7:23 PM, Andy Bierman wrote: > > > > > > > > > > > >>>> Hi, > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> Here are some proposed edits to make the data > > rule > > > > > > > > consistent > > > > > > > > > > > >>>> with the examples. > > > > > > > > > > > >>>> Note that this issue is not related to the edit > > in > > > > > > > > the > > > > > > > > > > original > > > > > > > > > > > >>>> 1-week change. > > > > > > > > > > > >>> That's right, but we found a source of > > > > > > > > misinterpretation > > > > > > > > in > > > > > > > > > > the > > > > > > > > > > > >>> draft and you have rightly corrected it in the > > github > > > > > > > > v9. > > > > > > > > > > > >>> > > > > > > > > > > > >>> Regards, Benoit > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> sec. 3.3.5: > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> OLD: > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> data node rule: controls access for a specific > > data > > > > > > > > > > > >>>> node, identified > > > > > > > > > > > >>>> by its path location within the conceptual XML > > > > > > > > document > > > > > > > > > > > >>>> for the > > > > > > > > > > > >>>> data node. > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> NEW: > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> data node rule: controls access for a specific > > data > > > > > > > > node > > > > > > > > > > > >>>> and its descendants, > > > > > > > > > > > >>>> identified by its path location within the > > conceptual > > > > > > > > XML > > > > > > > > > > > >>>> document for the > > > > > > > > > > > >>>> data node. > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> sec 3.4.5, step 6, bullet 2: > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> OLD: > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> * The rule does not have a "rule-type" defined or > > the > > > > > > > > > > > >>>> "rule- > > > > > > > > > > > >>>> type" is "data-node" and the "path" matches the > > > > > > > > > > > >>>> requested > > > > > > > > > > > >>>> data node, action node, or notification node. > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> NEW: > > > > > > > > > > > >>>> * The rule does not have a "rule-type" defined or > > the > > > > > > > > > > > >>>> "rule- > > > > > > > > > > > >>>> type" is "data-node" and the "path" matches the > > > > > > > > > > > >>>> requested > > > > > > > > > > > >>>> data node, action node, or notification node. A > > path > > > > > > > > is > > > > > > > > > > > >>>> considered to match if the current data node is > > the > > > > > > > > > > > >>>> data node > > > > > > > > > > > >>>> specified by the path, or is a descendant data > > node > > > > > > > > > > > >>>> of this data node. > > > > > > > > > > > >>>> appendix B.4: (2 bugs in explanation) > > > > > > > > > > > >>>> OLD: > > > > > > > > > > > >>>> deny-nacm: This rule denies the "guest" group any > > > > > > > > access > > > > > > > > to > > > > > > > > > > the > > > > > > > > > > > >>>> <nacm> subtree. Note that the default namespace > > is > > > > > > > > only > > > > > > > > > > > >>>> applicable because this subtree is defined in the > > > > > > > > same > > > > > > > > > > > >>>> namespace as the <data-rule> element. > > > > > > > > > > > >>>> NEW: > > > > > > > > > > > >>>> deny-nacm: This rule denies the "guest" group any > > > > > > > > access > > > > > > > > to > > > > > > > > > > the > > > > > > > > > > > >>>> <nacm> subtree. > > > > > > > > > > > >>>> Andy > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> On Fri, Nov 10, 2017 at 9:24 AM, Robert Wilton > > > > > > > > > > > >>>> <rwilton@cisco.com <mailto:rwilton@cisco.com>> > > wrote: > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> > > > > > > > > > > > >>>> On 10/11/2017 16:33, Andy Bierman wrote: > > > > > > > > > > > >>>>> > > > > > > > > > > > >>>>> > > > > > > > > > > > >>>>> On Fri, Nov 10, 2017 at 8:16 AM, Robert > > Wilton > > > > > > > > > > > >>>>> <rwilton@cisco.com <mailto:rwilton@cisco.com > > >> > > > > > > > > wrote: > > > > > > > > > > > >>>>> > > > > > > > > > > > >>>>> > > > > > > > > > > > >>>>> > > > > > > > > > > > >>>>> On 10/11/2017 15:49, Andy Bierman wrote: > > > > > > > > > > > >>>>>> > > > > > > > > > > > >>>>>> > > > > > > > > > > <snip> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Kent Watsen
- [Netconf] draft-ietf-netconf-rfc6536bis: one week… Benoit Claise
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Mahesh Jethanandani
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Per Hedeland
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Martin Bjorklund
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Mahesh Jethanandani
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Mahesh Jethanandani
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Mahesh Jethanandani
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Mahesh Jethanandani
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Benoit Claise
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Benoit Claise
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Martin Bjorklund
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … t.petch
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Randy Presuhn
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Randy Presuhn
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … t.petch
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Ladislav Lhotka
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Ladislav Lhotka
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Ladislav Lhotka
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Robert Wilton
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Ladislav Lhotka
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Andy Bierman
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … t.petch
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Ladislav Lhotka
- Re: [Netconf] draft-ietf-netconf-rfc6536bis: one … Benoit Claise