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

Mahesh Jethanandani <mjethanandani@gmail.com> Mon, 26 February 2018 19:15 UTC

Return-Path: <mjethanandani@gmail.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 66CBB126E64; Mon, 26 Feb 2018 11:15:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 hJy9oS1jqQCt; Mon, 26 Feb 2018 11:15:08 -0800 (PST)
Received: from mail-pl0-x22d.google.com (mail-pl0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93616126C26; Mon, 26 Feb 2018 11:15:08 -0800 (PST)
Received: by mail-pl0-x22d.google.com with SMTP id u13so9848329plq.1; Mon, 26 Feb 2018 11:15:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=aEIABOaquKeF9KEYTdoR9pihFr/SzQfw1a9Gbe+dQtw=; b=uRD7OF1eEAHhwSCetI3KNtRfSEUmE9KHLtTgkhfBME+FeWpjdACbZYapGjlbXIJt4d eHctQKmc1oy/1ZDe8SEhOad1g/x9ir4hKHdSx3tKaPZ1p82sj4l05Lq/CKVXLd6ptycg 8hvEzEZjrl7fS0mNTZ1GIa9JdgCG28P74hUn4E+7MD9yOBauA+9zUAIZAqHr7z3YGzGS bM4f1xGPPsXku3navwyqR+UIQBF1+S9Zqoga0/fjbFlw37hQacO+IAr5yx3M4zK1t1Bq h/u/EqNGfihYmjE81jJXHoZ9rldED11PqmFzBEqcuKaHSxKYgTE9BFMaSjBB9qMHtO7k iYDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=aEIABOaquKeF9KEYTdoR9pihFr/SzQfw1a9Gbe+dQtw=; b=HJgAjY1PSPEqusbPyvZN7lL14/EkrDPiKXE4kqeJwOI7C99j+chnNRFsP7FykYVGrq qslzfy+SUs9wyMQzg/hXR/NTMfyBCL7livf4iOMEo9+YGwa1TBIGOSCIpq1qBy5ajYRj van89yyWPNMZXA7sGpk8nKLPi1nNKpTr9K1XnBKmHVBYt5ARtN2T/WJtiPXRrJx/gZpy yn3zQwx0ykX5MBTMyKFTkCCXXl1ifrkjh8Kzbr83RTM4MBdk2x24/cfytpS/PcMr1w10 oQbM77cc4/LQgQ/0WQno+oiwwJjD5ItHRW9ermu41ins1taVjBqKqhga50BTi7KvVKVP 18pA==
X-Gm-Message-State: APf1xPBQpvEjjmuuBOeav01LQZQn1kVTFW2J4QiKtSpY7YJK9Axd/PBV axTavIZvQoDNO3utImGVljQ=
X-Google-Smtp-Source: AH8x2252nUzFdZ2Ltp0Vg6GZVjnA7wYV4k+Z2hz8Wug2iQ+uzHWZm9q3UYbuPd8g9MkJxFFSIHwgNw==
X-Received: by 2002:a17:902:ab84:: with SMTP id f4-v6mr11791834plr.239.1519672508050; Mon, 26 Feb 2018 11:15:08 -0800 (PST)
Received: from ?IPv6:2601:647:4700:1280:59d9:6f72:9685:4ce6? ([2601:647:4700:1280:59d9:6f72:9685:4ce6]) by smtp.gmail.com with ESMTPSA id k192sm8240820pfc.98.2018.02.26.11.15.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 11:15:07 -0800 (PST)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <E4EDCE65-70A1-41CD-ABFE-C46E758732A1@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E1D4E7F4-1E32-49FC-8232-3AE9E349B709"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 26 Feb 2018 11:20:55 -0800
In-Reply-To: <ed68a5f1-7854-3d7c-2ff7-ee71857707d9@tail-f.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>, "draft-ietf-netmod-acl-model@ietf.org" <draft-ietf-netmod-acl-model@ietf.org>
To: Per Hedeland <per@tail-f.com>
References: <35213d61-08b4-ce5b-f7b2-251d2d5c2e70@tail-f.com> <87y3jf51ed.fsf@nic.cz> <ed68a5f1-7854-3d7c-2ff7-ee71857707d9@tail-f.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/pxwo3_RGTZDVL57zNGnyX51oik0>
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 19:15:11 -0000


> On Feb 26, 2018, at 9:01 AM, Per Hedeland <per@tail-f.com> wrote:
> 
> [Adding Cc to draft-ietf-netmod-acl-model@ietf.org <mailto: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.

I would agree that that is not how I am reading RFC 7950. For now my choice is to change all the derived-from() to derived-from-or-self().

> 
>> 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?
> 
> --Per
> 
>> Lada
>> 
>>> 
>>> --Per Hedeland
>>> 
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org <mailto:netmod@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
Mahesh Jethanandani
mjethanandani@gmail.com