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?
--Per Hedeland
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
