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

Per Hedeland <per@tail-f.com> Sat, 24 February 2018 15:13 UTC

Return-Path: <per@tail-f.com>
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 25BFA12706D for <netmod@ietfa.amsl.com>; Sat, 24 Feb 2018 07:13:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 62cJ2ynwykAG for <netmod@ietfa.amsl.com>; Sat, 24 Feb 2018 07:13:18 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 271B91201FA for <netmod@ietf.org>; Sat, 24 Feb 2018 07:13:18 -0800 (PST)
Received: from pluto.hedeland.org (81-228-155-109-no289.tbcn.telia.com [81.228.155.109]) by mail.tail-f.com (Postfix) with ESMTPSA id 6EA2F1AE018B for <netmod@ietf.org>; Sat, 24 Feb 2018 16:13:17 +0100 (CET)
To: "netmod@ietf.org" <netmod@ietf.org>
From: Per Hedeland <per@tail-f.com>
Message-ID: <35213d61-08b4-ce5b-f7b2-251d2d5c2e70@tail-f.com>
Date: Sat, 24 Feb 2018 16:13:17 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/BrMu4-4bP_qUhaIzmUkmLoVd11A>
Subject: [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: Sat, 24 Feb 2018 15:13:19 -0000

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?

--Per Hedeland