> On Feb 26, 2018, at 1:31 PM, Per Hedeland <[email protected]> wrote: > > On 2018-02-26 20:20, Mahesh Jethanandani wrote: >>> On Feb 26, 2018, at 9:01 AM, Per Hedeland <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> [Adding Cc [email protected] >>> <mailto:[email protected]>] >>> >>> On 2018-02-26 14:24, Ladislav Lhotka wrote: >>>> Per Hedeland <[email protected] <mailto:[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. >> 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(). > > I think that is a useful change. FWIW, when I actually tried the example > as the payload of an <edit-config> towards our NETCONF server, I found > some other problems, which I believe are still relevant with the pull > request applied: > > 1) (Aldready mentioned) the <l3> element corresponding to the choice in > the model should not be present (RFC 7950 section 7.9.5).
Removed <l3>. Although I have say the tree diagram confused me. It identifies l3 as a node with a +—rw next to it, while for ipv4 it says +—. > > 2) "tcp" is not a valid value for the 'protocol' leaf - from > [email protected]: > > leaf protocol { > type uint8; > description > "Internet Protocol number. Refers to the protocol of the > payload. In IPv6, this field is known as 'next-header."; > reference "RFC 719, RFC 2460."; > } > > I.e. it should be "6". And the reference for this leaf, as well as for > 'length' and 'ttl', should presumably be RFC 791, not RFC 719. Changed it to 6, and 719 to 791. > > 3) 11.11.11.1/24 (for 'destination-ipv4-network') and 10.10.10.1/24 (for > 'source-ipv4-network') are not valid (canonical) values for > inet:ipv4-prefix - from ietf-inet-types.yang: > > The canonical format of an IPv4 prefix has all bits of > the IPv4 address set to zero that are not part of the > IPv4 prefix."; > > And of course it doesn't make much sense to have bits outside the prefix > length set for a match specification. It seems the pull request changes > these prefixes to RFC 1918 / RFC 5737 space, but those prefixes have > the same issue. Made the host part of the network address 0. > > I'm attaching the output from a <get-config> towards our NETCONF server > with these issues fixed (and the derived-from() -> > derived-from-or-self() change made). Thanks. > > --Per > >>> >>>> 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 >>>>> [email protected] <mailto:[email protected]> >>>>> https://www.ietf.org/mailman/listinfo/netmod >> Mahesh Jethanandani >> [email protected] <mailto:[email protected]> > > <example.xml> Mahesh Jethanandani [email protected] _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
