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

From: Kristian Larsson <[email-masked]>
Date: Thu, 17 Aug 2017 14:19:28 +0200

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-masked]

---

From: Kristian Larsson <[email-masked]>
Date: Thu, 17 Aug 2017 18:16:01 +0200

Pardon my ignorance as this might have been asked before but why
is the actions/packet-handling modelled as a choice? It would
seem an identity would be better or perhaps even an enum?

   kll

On Fri, Jul 07, 2017 at 06:34:28PM +0000, Kent Watsen wrote:
> 
> 
> This is a notice to start a three week NETMOD WG last call for the
> document:
> 
>     Network Access Control List (ACL) YANG Data Model
>     https://tools.ietf.org/html/draft-ietf-netmod-acl-model-11
> 
> Note: Three weeks is more than needed, especially given this 
>       draft has been through Last Call before, but we understand
>       folks are busy these days.
> 
> Please indicate your support or concerns by Friday, July 28, 2017.
> 
> We are particularly interested in statements of the form:
>   * I have reviewed this draft and found no issues.
>   * I have reviewed this draft and found the following issues: ...
> 
> As well as:
>   * I have implemented the data model in this draft.
>   * I am implementing the data model in this draft.
>   * I am considering to implement the data model in this draft.
>   * I am not considering to implement the data model in this draft.
> 
> Thank you,
> NETMOD WG Chairs
> 
> 
> 
> 
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Sonal Agarwal <[email-masked]>
Date: Mon, 21 Aug 2017 08:05:12 -0700

Hi Kristian,

Thank you for your feedback on the model. I do not recollect that anybody
has questioned the 'action' statement in the last year. The 'action'
statement and the 'choice' container was something that was inherited when
the model was initially written.

It is easy to convert this to an identity. I am also wondering if we should
explicitly define 3 identities.

PERMIT/ACCEPT - allow/accept the packet
DROP - drop packet and send ICMP message
REJECT - drop packet and do not send ICMP message

Could you please give me your thoughts on this?

Best regards,
Sonal.