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

> 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