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

From: Kent Watsen <[email-masked]>
Date: Fri, 7 Jul 2017 18:34:28 +0000

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 7 Jul 2017 21:24:01 +0200

Kent,

what is the plan concerning the open issues listed in section 8?

/js

On Fri, Jul 07, 2017 at 06:34:28PM +0000, Kent Watsen wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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/>

---

From: Kent Watsen <[email-masked]>
Date: Fri, 7 Jul 2017 19:38:33 +0000

Can the authors please start a thread on each of these open-issues ASAP?

Thanks,
Kent // shepherd

--

Kent,

/js

---

From: David Bannister <[email-masked]>
Date: Fri, 7 Jul 2017 16:39:42 -0400

I have reviewed this draft and it addresses my earlier concerns.

---

From: Lou Berger <[email-masked]>
Date: Mon, 17 Jul 2017 16:18:47 +0200

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.

Kent and Lou

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 17 Jul 2017 17:11:48 +0200

> 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