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

From: Alissa Cooper <[email-masked]>
Date: Wed, 26 Sep 2018 14:26:40 -0700

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.

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

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 26 Sep 2018 18:17:58 -0700

Hi Alissa,

> On Sep 26, 2018, at 2:26 PM, Alissa Cooper <[email-masked]> wrote:
> 

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

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.

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

> modules will want to import this module and that seems like a strange place to

That is what we could agree with IEEE on.

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

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

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

Same as above.

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

Ok.

> additionally warrant protections against unauthorized log access and a logs

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

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 27 Sep 2018 16:14:48 -0400

Hi Alissa/Mahesh,

> On Sep 26, 2018, at 9:17 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
> Hi Alissa,
> 
>> On Sep 26, 2018, at 2:26 PM, Alissa Cooper <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ <https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/>
>> 
>> 
>> 

There was an IETF-IEEE leadership co-ordination call this afternoon and I reminded the RAC person on the call about this draft and our past interactions with the IEEE. I also send a note to the IETF-IEEE co-ordination group so that any interested persons on the IEEE side will be aware of this draft.

https://www.ietf.org/mail-archive/web/ieee-ietf-coord/current/msg01134.html <https://www.ietf.org/mail-archive/web/ieee-ietf-coord/current/msg01134.html>

So, unless we hear some objections in the near future we are good to go in this regard.

Thanks
Suresh

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 28 Sep 2018 09:18:14 -0400

> On Sep 27, 2018, at 4:14 PM, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Alissa/Mahesh,
> 
>> On Sep 26, 2018, at 9:17 PM, Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Alissa,
>> 

Thank you Suresh, I have cleared my DISCUSS.

Alissa