On Mon, Jul 17, 2017 at 05:11:48PM +0200, Juergen Schoenwaelder wrote: > On Mon, Jul 17, 2017 at 04:18:47PM +0200, Lou Berger wrote: > > All, > > > > Per our discussion in today's session, another version of this draft > > is needed to address open issues. As this revision will include > > technical changes, another LC will be needed after that version is > > published. > > > > Please do comment on this version, but be aware this version will *not* > > be submitted for publication. > > > > I planned to review this I-D but I will now wait for the next > version. ;-) However, a few things I already noted: > > - The identifiers are long, I think this was discussed before. I > suggest to replace 'source' with 'src' and 'destination' with > 'dst'; this will likely also make the tree diagram fit the > traditional RFC format again. > > I am not sure about the idea to spell out all the mixed-x-y-z > combinations. This may turn out costly to maintain long term. > > The naming is also inconsistent I think. My understanding is that > mixed-l2-l3-ipv4-acl really means mixed-eth-ipv4-acl. In fact, > ipv4-acl is actually l3 and possibly l4 since the grouping > acl-ip-header-fields uses acl-transport-header-fields. You can skip > the l4 portions since they are in a presence container. Note that this > is different from how you deal with l2 and l3 combinations.
+1, this bothered me too when reading the model. IPv4 and IPv6 is explicitly named while L2 just implies Ethernet. Should have eth-ipv4-acl in the name, or eth-ipv6-acl.. or if we support matches for other L2 technology then include that in the name. While Ethernet is popular we do still have other L2 technologies. > I guess I > would generally prefer a solution that is more orthogonal > wrt. layering and likely not causing maintenance headaches in 5-10 > years from now. I don't immediately see a better way of doing it. It is rather tricky. > That said, I am not planning to implement this YANG module myself so > as long as multiple implementors think this is all good, it might be > sufficient to simply fix terminology and naming to be clear, concise > and consistent. I'm trying to implement it, as a user :) kll -- Kristian Larsson KLL-RIPE +46 704 264511 [email protected] _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
