Per Hedeland <[email protected]> writes: > [Adding Cc to [email protected]] > > On 2018-02-26 14:24, Ladislav Lhotka wrote: >> Per Hedeland <[email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
