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. 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. 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. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
