Per Hedeland <p...@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.
Identities that are considered "abstract" should not be instantiated, and
then derived-from() and derived-from-or-self() give the same result.
Lada
>
> --Per Hedeland
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
