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

[Adding Cc to 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.

> 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
>> https://www.ietf.org/mailman/listinfo/netmod
> 