Re: [netmod] Alissa Cooper's Discuss on draft-ietf-netmod-acl-model-19: (with DISCUSS and COMMENT)

[Mahesh Jethanandani <[e-mail]>]

Hi Alissa,

> On Sep 26, 2018, at 2:26 PM, Alissa Cooper <[e-mail]> wrote:
> 
> Alissa Cooper has entered the following ballot position for
> draft-ietf-netmod-acl-model-19: Discuss
> 
> 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/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> We previously had a work item we were tracking with the IEEE leadership around
> the IEEE writing a YANG module for ethertypes. I just wanted to check that the
> IEEE is aware that this document is defining a placeholder module for
> ethertypes until such time that they define one.

They were told as much in the joint IETF-IEEE meeting.

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Sec 1:
> 
> s/Policy Based Routing, Firewalls etc./policy-based routing, firewalls, etc./

Isn’t Policy Based Routing (PBR) and particular form of routing, with its own acronym and all? I can make the F in Firewalls, lowercase.

> 
> "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.


How about this:

OLD:
   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.


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

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

Ok.

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

That is what we could agree with IEEE on.

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

I would object to making these changes in the model, particularly since the description already defines what they are.

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

It is referring to the node ‘ace’ defined in the module.

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

Same as above.

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

Ok.

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

How about this addition to the section under list of subtrees and data nodes that are sensitive and vulnerable:

      /acls/acl/aces/ace/actions/logging: This node specifies ability to log
      packets that match this ace entry.  Unauthorized write access to this
      node can allow intruders to enable logging on one or many ace entries, 
      overwhelming the server in the process. Unauthorized read access of this node 
      can allow intruders to access logging information, which could be used to
      attack the server.

Thanks.

Mahesh Jethanandani
[e-mail]