Subject: [netmod] Alissa Cooper's No Objection on draft-ietf-netmod-acl-model-19: (with COMMENT)

From: Alissa Cooper <[email-masked]>
Date: Fri, 28 Sep 2018 06:07:08 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-netmod-acl-model-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks all for getting my question about the IEEE answered.

Original COMMENT:

Sec 1:

s/Policy Based Routing, Firewalls etc./policy-based routing, firewalls, etc./

"The matching of filters and actions in an ACE/ACL are triggered only
   after application/attachment of the ACL to an interface, VRF, vty/tty
   session, QoS policy, routing protocols amongst various other config
   attachment points."

This is a sentence fragment.

s/in the ACE's/in the ACEs/

Sec 3.1:

"There are two YANG modules in the model."

Is this technically correct, given that ietf-ethertypes is also defined here?

Also, I don't think the definition of ietf-ethertypes belongs in an appendix
under the heading "Extending ACL model examples." I can imagine that other
modules will want to import this module and that seems like a strange place to
put it.

Sec 4.1:

For avoidance of confusion, I would suggest replacing "l2," "l3," and "l4" with
"layer2," "layer3," and "layer4," respectively.

s/Definitions of action for this ace entry/Definitions of action for this ACE
entry/

s/Specifies the forwarding action per ace entry/Specifies the forwarding action
per ACE entry/

Sec 4.2:

"This module imports definitions from Common YANG Data Types [RFC6991]
   and references IP [RFC0791], ICMP [RFC0792], Definition of the
   Differentiated Services Field in the IPv4 and IPv6 Headers [RFC2474],
   The Addition of Explicit Congestion Notification (ECN) to IP
   [RFC3168], , IPv6 Scoped Address Architecture [RFC4007], IPv6
   Addressing Architecture [RFC4291], A Recommendation for IPv6 Address
   Text Representation [RFC5952], IPv6 [RFC8200]."

It looks like something is missing from this list, possibly RFC 793.

Sec 5:

In this section or elsewhere it would be nice to see a sentence noting that
this YANG model allows the configuration of packet logging, which if used would
additionally warrant protections against unauthorized log access and a logs
retention policy.