Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-11

[Kristian Larsson <[e-mail]>]

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
[phone]                                [e-mail]