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
- [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