Re: [netmod] derived-from() vs derived-from-or-self() in acl model
Ladislav Lhotka <lhotka@nic.cz> Mon, 26 February 2018 13:25 UTC
Return-Path: <lhotka@nic.cz>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EDE12D779 for <netmod@ietfa.amsl.com>; Mon, 26 Feb 2018 05:25:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 Hv5yBT65Z7rh for <netmod@ietfa.amsl.com>; Mon, 26 Feb 2018 05:25:04 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E66F7126DED for <netmod@ietf.org>; Mon, 26 Feb 2018 05:25:03 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 17A221820413; Mon, 26 Feb 2018 14:21:54 +0100 (CET)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 0F5E718203F6; Mon, 26 Feb 2018 14:21:50 +0100 (CET)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Per Hedeland <per@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org>
In-Reply-To: <35213d61-08b4-ce5b-f7b2-251d2d5c2e70@tail-f.com>
References: <35213d61-08b4-ce5b-f7b2-251d2d5c2e70@tail-f.com>
Mail-Followup-To: Per Hedeland <per@tail-f.com>, "netmod\@ietf.org" <netmod@ietf.org>
Date: Mon, 26 Feb 2018 14:24:58 +0100
Message-ID: <87y3jf51ed.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/_HTUjd-2-bPzV58qgNwalvJaIyc>
Subject: Re: [netmod] derived-from() vs derived-from-or-self() in acl model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Feb 2018 13:25:06 -0000
Per Hedeland <per@tail-f.com> writes: > Hi, > > A customer of ours using one of the draft versions of the > ietf-access-control-list module reported that it was not possible to > configure an ethernet ace with type acl:eth-acl-type, due to the > derived-from() in > > container eth { > when "derived-from(../../../../type, " + > "'acl:eth-acl-type')"; > if-feature match-on-eth; > uses pf:acl-eth-header-fields; > description > "Rule set that matches ethernet headers."; > } > > evaluating to "false". I pointed out that this is correct behavior of > our SW, since acl:eth-acl-type is not derived from acl:eth-acl-type, and > it would need to be derived-from-or-self() in order to evaluate to > "true". I also ventured a guess (not having followed the development of > the acl model in detail) that the intent was that vendors should define > their own identities, that actually *were* derived from acl:eth-acl-type > (and ditto for all the other *-acl-type identities, of course). > > However I'm not at all sure that the guess is correct, and if so why > this should be *enforced* by excluding the base identity. And having a > look at the example in section 4.3 of draft-ietf-netmod-acl-model-16, it > seems to be doing exactly what our customer tried, alhough with > ipv4-acl-type: > > <data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > <access-lists xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list"> > <acl> > <name>sample-ipv4-acl</name> > <type>ipv4-acl-type</type> > <aces> > <ace> > <name>rule1</name> > <matches> > <l3> > <ipv4> > <protocol>tcp</protocol> > > As far as I can see, this snippet is invalid for the model, since the > 'ipv4' container has > > container ipv4 { > when "derived-from(../../../../type, " + > "'acl:ipv4-acl-type')"; > > - and ipv4-acl-type is *not* derived from ipv4-acl-type. (Of course > there shouldn't be any <l3> element either, but that's another thing.) > > So, is it the case that the derived-from()s should actually be > derived-from-or-self()s, or is the example wrong? This has to do with the irreflexivity property of identity derivation, which is, in my view, an unnecessary complication. It would be simpler but sufficient to define derivation as a reflexive relation, and have only one "derived-from()" XPath function. Identities that are considered "abstract" should not be instantiated, and then derived-from() and derived-from-or-self() give the same result. Lada > > --Per Hedeland > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67
- [netmod] derived-from() vs derived-from-or-self()… Per Hedeland
- Re: [netmod] derived-from() vs derived-from-or-se… Ladislav Lhotka
- Re: [netmod] derived-from() vs derived-from-or-se… Per Hedeland
- Re: [netmod] derived-from() vs derived-from-or-se… Mahesh Jethanandani
- Re: [netmod] derived-from() vs derived-from-or-se… Per Hedeland
- Re: [netmod] derived-from() vs derived-from-or-se… Mahesh Jethanandani
- Re: [netmod] derived-from() vs derived-from-or-se… Per Hedeland
- Re: [netmod] derived-from() vs derived-from-or-se… Ladislav Lhotka