Re: [netmod] derived-from() vs derived-from-or-self() in acl model

Ladislav Lhotka <lhotka@nic.cz> Tue, 27 February 2018 06:44 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 2249A120454; Mon, 26 Feb 2018 22:44:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] 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 q1BF87GXZDDH; Mon, 26 Feb 2018 22:44:26 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1B41200B9; Mon, 26 Feb 2018 22:44:25 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 46AF41820412; Tue, 27 Feb 2018 07:41:11 +0100 (CET)
Received: from localhost (37-48-39-170.tmcz.cz [37.48.39.170]) by trail.lhotka.name (Postfix) with ESMTPSA id 64B2A18203DE; Tue, 27 Feb 2018 07:41:08 +0100 (CET)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Per Hedeland <per@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org>
Cc: "draft-ietf-netmod-acl-model@ietf.org" <draft-ietf-netmod-acl-model@ietf.org>
In-Reply-To: <ed68a5f1-7854-3d7c-2ff7-ee71857707d9@tail-f.com>
References: <35213d61-08b4-ce5b-f7b2-251d2d5c2e70@tail-f.com> <87y3jf51ed.fsf@nic.cz> <ed68a5f1-7854-3d7c-2ff7-ee71857707d9@tail-f.com>
Mail-Followup-To: Per Hedeland <per@tail-f.com>, "netmod\@ietf.org" <netmod@ietf.org>, "draft-ietf-netmod-acl-model\@ietf.org" <draft-ietf-netmod-acl-model@ietf.org>
Date: Tue, 27 Feb 2018 07:44:18 +0100
Message-ID: <87371nq6d9.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/f6KCIKWmM5Dzf2DyBnGLhedSICk>
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: Tue, 27 Feb 2018 06:44:29 -0000

Per Hedeland <per@tail-f.com> writes:

> [Adding Cc to draft-ietf-netmod-acl-model@ietf.org]
>
> On 2018-02-26 14:24, Ladislav Lhotka wrote:
>> 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.
>
> Be that as it may, it is obviously not what RFC 7950 says.

Of course not, but something is wrong if we need to have this discussion.

>
>> Identities that are considered "abstract" should not be instantiated, and
>> then derived-from() and derived-from-or-self() give the same result.
>
> So I guess your take is that the *-acl-type identities derived from
> acl:acl-base in the ietf-access-control-list module should be considered
> "abstract", and thus the example should not use ipv4-acl-type for the
> 'type' leaf, but instead some other identity derived from
> acl:ipv4-acl-type. Do the authors agree?

I don't think it is abstract, so derived-from() should be replaced
derived-from-or-self(). My point is that this can be done *everywhere*,
so the former function is pretty much useless. But then,
derived-from-or-self is ridiculously long, and the existence of two
functions is confusing.

Lada

>
> --Per
>
>> Lada
>> 
>>>
>>> --Per Hedeland
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67