Subject: [netmod] I-D Action: draft-ietf-netmod-acl-model-17.txt

From: [email-masked]
Date: Sat, 03 Mar 2018 14:13:00 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

        Title           : Network Access Control List (ACL) YANG Data Model
        Authors         : Mahesh Jethanandani
                          Lisa Huang
                          Sonal Agarwal
                          Dana Blair
	Filename        : draft-ietf-netmod-acl-model-17.txt
	Pages           : 57
	Date            : 2018-03-03

Abstract:
   This document defines a data model for Access Control List (ACL).
   ACL is a ordered-by-user set of rules, used to configure the
   forwarding behavior in device.  Each rule is used to find a match on
   a packet, and define actions that will be performed on the packet.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-acl-model-17
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-17

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sat, 3 Mar 2018 14:18:36 -0800

This version of the draft addresses comments raised during LC, shepherd review and other comments received during that period.

> On Mar 3, 2018, at 2:13 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
[email-masked]

---

From: Kent Watsen <[email-masked]>
Date: Wed, 7 Mar 2018 21:55:12 +0000

[To all those that said this draft was ready, really?]

Hi Mahesh,

Thanks for the update.  I found some more issues.  Some must be fixed, 
others are nits, and might be caught by the RFC Editor.  But I think
that it's embarrassing to receive comments for such things from the 
IESG, as is recently the case for the syslog draft, so please see 
what you can do.

Thanks,
Kent

From Idnits:

  ** There are 6 instances of too long lines in the document, the longest one
     being 7 characters in excess of 72.

  You wrote before that it was "Fixed", but it's still here?  Note: "**" is
  an error (idnits label)

  -- The document has examples using IPv4 documentation addresses according
     to RFC6890, but does not use any IPv6 documentation addresses.  Maybe
     there should be IPv6 examples, too?

  I don't feel strongly about this, but if it's easy enough to do...

In the Abstract:
  - I think the word "an" is missing (e.g., an ACL)

In the Introduction:
  - should "ordered-by-user" be "ordered-by user" to avoid confusion, or perhaps say it another way?
  - what does "a tuple of" mean?  Can this be restated?
  - s/In case vendor supports it/In case a vendor supports it/ ?
  - "The list of X is endless depending on...".  Is "endless" the right word, perhaps restate?
  - same sentence as above, should "networked devices" be "network" or "networking" devices?

In Section 3:
  - "A network system usually have a list of ACLs"  (s/system/systems/ or s/have/has/?)
  - "The match criteria consist of packet header matching" - is consist the right word?
  - "It as also possible for ACE to match on metadata"  s/as/is/ and s/ACE/an ACE/
  - "When applied to interfaces of a networked device, the ACL is applied in a direction
     which indicates if it should be applied to packet entering (input) or leaving the
     device (output)."  - restate to talk about "ingress" and "egress"?
  - "An example in the appendix shows how to express it in YANG model." - either this
    is not true, or the sentence should not be at the end of this paragraph

In Section 3.1:
  - s/and must statements/and 'must' statements/
  - s/define new "matches" choice/define a new "matches" choice/ ?

In Section 4.1:
  - "ietf-access-control-list" is the standard top level module for access lists
      - what does this mean?
  - The "access-lists" container stores a list of "acl". - s/stores/has or contains?/ 
  - "...that can be used to determine which rule was matched upon" - not sure if this
    part is needed, or maybe better restated ", which can later be used to determine..."?
  - s/ability for ACL's to be/ability for ACLs to be/

In Section 4.1 (in the YANG module):
  - A number of identities read "ACL that primarily matches...".  Is "primarily"
    an accurate word? - if so, then do we need to say anything about when it's
    not the case?  Separately, s/ACL/an ACL/?
  - A number of features read "Device can support..." - s/Device/The device/?
  - "It can have one or more Access Control Lists" - lists should be singular.
  - "An Access Control List(ACL)" - put a space before (ACL)
  - " Indicates the primary intended" - here's that word "primary" again...
  - s/a list of access-list-entries(ACE)/ a list of access-list-entry nodes (ACE)/?
  - s/List of access list entries(ACE)/List of access list entry nodes (ACE)/?
      - there is more than one instance of this in the model
  - "../../../../type" - still some long relative XPaths
  - " or referring to a group of source ports" - this isn't there yet.  I think you
    want to say something like "this is a choice so as to support future 'case'
    statements, such as one enabling a group of source ports to be referenced"
  - ditto for "or referring to a group of destination ports."
  - ditto on both of the above for the "udp" container
  - is it possible for both "egress-interface" and "ingress-interface" leafs to 
    be specified at the same time?  - if not, should there a 'must' statement to
    prevent that possibility? - or an explanation for what happens if it occurs?
  - s/The ACL's applied/The ACLs applied/   (this happens more than once in model)

In Section 4.2:
  - references them by "uses" --> references them by 'uses' statements  ???
  - not all your 'reference' statements have the title of the referenced document.
  - "then the datagram must be destroyed" - s/destroyed/dropped/?
  - "or referring to a group of ..."  - same comments as for previous module
  - "ece" is missing a 'reference' statement?  - 
  - "Indicates that the Urgent pointer field is significant" - urgent is
    capitalized, but there's no context as for why.  Perhaps missing a
    reference statement too?
  - in "window-size" leaf description, remove parentheses

In Section 4.3:
  - the text says that it drops traffic from X to Y, but the example seems to do
    the reverse.

In Section 4.4:
  - The "With the follow XML example:" <EXAMPLE> "This represents..." is 
    difficult to read.  How about just having "The following XML example ...:"?
  - does the second example provide any value of the first? - seems the same to me...
  - seems like example 3 could also be expressed as "<lower-port>21</lower-port>",
    right?  - the text at the beginning of the section says this construct is
    possible, but there is no example for it.  Maybe this makes a better ex #2?

In all your YANG modules:
  - replace "NETMOD (NETCONF Data Modeling Language)" with "NETMOD (Network 
    Modeling) Working Group"

In Section ??:
  In the examples, why did you add the "<?xml version="1.0" encoding="UTF-8"?>"
  line and the "config" element?  - the examples validate equally well when
  these are removed.

In Section 6:
  - s/three YANG module/three YANG modules/

In Section 6.1:
  - The first paragraph says "three URI", but it should be "three URIs"

In Section A.1:
  - "The following figure is the tree structure" - should say "tree diagram" and
    should reference the tree-diagrams draft, or else have a draft-wide "Tree
    Diagram Notation" section in the Introduction.
  - s/In other example/In another example/?
  - s/with new choice of actions/with a new choice of actions/?

In Section A.3;
  - some 'reference' statements are missing titles
  - some 'description' statements might benefit from a 'reference' statement
  - "The uint16 type placeholder type..." - is this a typo?

Kent

===== original message ======

> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Dacl-2Dmodel_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=44GJlqxqB0YK5G9gb1TUzAobugMHxDWflaPCZ3IYpKA&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Dacl-2Dmodel-2D17&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=rbm91SSJ_0sxFxb692d0FH0G-dbBTAUCf2KRySyztJQ&e=
> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dnetmod-2Dacl-2Dmodel-2D17&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=siypyBn3F8o6bsB3Z3E5qS0uaSq2EUGUPwirx_a_KDw&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dnetmod-2Dacl-2Dmodel-2D17&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=t2lpzSSW72BvQK1VjPoxX0ADxhb9ZD0fp3fXqcd80g8&e=
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=xP7z9VxUgtOtSVIgqPF5RKIqTOi6wj-HEXvZKBRTiUw&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=OKIVLXLo0Rsrf1DSoLWSyHj97DuE6vuaJ4Cqk_oi1HA&e=

Mahesh Jethanandani
[email-masked]

_______________________________________________
netmod mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=OKIVLXLo0Rsrf1DSoLWSyHj97DuE6vuaJ4Cqk_oi1HA&e=

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 8 Mar 2018 16:40:54 -0800

Kent,

> On Mar 7, 2018, at 1:55 PM, Kent Watsen <[email-masked]> wrote:
> 

Hmm. The idnits at submission time did not complain. Will apply the new script that you provided to make sure I wrap them around.

>  - I think the word "an" is missing (e.g., an ACL)

Added.

>  - should "ordered-by-user" be "ordered-by user" to avoid confusion, or perhaps say it another way?

How about this in both the Abstract and the Introduction.

OLD:
ACL is a ordered-by-user set of rules

NEW:
An ACL is a set of rules, in an order set by the user

>  - what does "a tuple of" mean?  Can this be restated?

How about this?

OLD:
The match criteria consist of a tuple of packet header match criteria and can have metadata match criteria as well.

NEW:

>  - s/In case vendor supports it/In case a vendor supports it/ ?

Ok.

>  - "The list of X is endless depending on...".  Is "endless" the right word, perhaps restate?
OLD:
The list of potential actions is endless

NEW:
The list of potential actions is limitless

>  - same sentence as above, should "networked devices" be "network" or "networking" devices?

Will change “networked devices” to “networking devices”.

>  - "A network system usually have a list of ACLs"  (s/system/systems/ or s/have/has/?)

s/have/has/.

>  - "The match criteria consist of packet header matching" - is consist the right word?

How would you restate it? (After I have s/consist/consists/)

>  - "It as also possible for ACE to match on metadata"  s/as/is/ and s/ACE/an ACE/

Ok

>     device (output)."  - restate to talk about "ingress" and "egress”?

How about:

When applied to interfaces of a networked device, the ACL is applied in a direction which indicates if it should be applied to ingress interface (input) or egress interface (output).

>    is not true, or the sentence should not be at the end of this paragraph

Removed.

>  - s/and must statements/and 'must' statements/

Done and s/if-feature/‘if-feature’/

>  - s/define new "matches" choice/define a new "matches" choice/ ?

Done.

>  - "ietf-access-control-list" is the standard top level module for access lists

OLD:
"ietf-access-control-list" is the standard top level module for access lists

NEW:
"ietf-access-control-list" is the top level module for access lists

>  - The "access-lists" container stores a list of "acl". - s/stores/has or contains?/ 

s/stores/has/

>    part is needed, or maybe better restated ", which can later be used to determine…"?

Ok.

>  - s/ability for ACL's to be/ability for ACLs to be/

Ok.

>    not the case?

As one of the text says. It primarily matches IPv4, and does not match either ethernet or IPv6 headers. Such ACL types are different from the mixed ACL types that might match on a combination of ethernet and IPv4 headers etc.

>  Separately, s/ACL/an ACL/?

Ok.

>  - A number of features read "Device can support..." - s/Device/The device/?

Ok.

>  - "It can have one or more Access Control Lists" - lists should be singular.

Really? English grammar says that if a sentence has both a singular and a plural, the one nearest to the subject is the one you select.

>  - "An Access Control List(ACL)" - put a space before (ACL)

Ok.

>  - s/a list of access-list-entries(ACE)/ a list of access-list-entry nodes (ACE)/?

Ok.

>      - there is more than one instance of this in the model

Fixed.

>  - "../../../../type" - still some long relative XPaths

Fixed.

>    statements, such as one enabling a group of source ports to be referenced”

How about:

Choice of source port definition using range/operator or referring to a group of source ports, to be added as a future 'case' statement.

>    prevent that possibility? - or an explanation for what happens if it occurs?

Let me discuss this with my co-authors.

>  - s/The ACL's applied/The ACLs applied/   (this happens more than once in model)

Fixed.

>  - references them by "uses" --> references them by 'uses' statements  ???

Ok.

>  - not all your 'reference' statements have the title of the referenced document.

Fixed.

>  - "then the datagram must be destroyed" - s/destroyed/dropped/?

Ok.

>  - "ece" is missing a 'reference' statement?  - 

Added.

>    capitalized, but there's no context as for why.  Perhaps missing a

Added a reference statement.

>  - in "window-size" leaf description, remove parentheses

Ok.

>  - the text says that it drops traffic from X to Y, but the example seems to do

Fixed.

>    difficult to read.  How about just having "The following XML example ...:”?

Fixed.

>  - does the second example provide any value of the first? - seems the same to me…

Will change the example.

>    possible, but there is no example for it.  Maybe this makes a better ex #2?

Have changed the language in the beginning of the section to say:

"When only a port is present, it represents a port, with the operator specifying the range."

That is because, it now a choice between specifying a range or specifying a single port with an operator.

>    Modeling) Working Group”

Ok.

>  line and the "config" element?  - the examples validate equally well when

The examples can then be cut and pasted into any client such as ncclient which takes an entire <rpc>.

>  - s/three YANG module/three YANG modules/

Fixed.

> 
> In Section 6.1:
>  - The first paragraph says "three URI", but it should be "three URIs”

Fixed.

>    Diagram Notation" section in the Introduction.

Added a section in the Introduction.

>  - s/with new choice of actions/with a new choice of actions/?

Both fixed.

>  - some 'reference' statements are missing titles

Added.

>  - some 'description' statements might benefit from a 'reference’ statement

I have added references that I could find.

>  - "The uint16 type placeholder type..." - is this a typo?

Dropped the second “type”.

Thanks.

>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Dacl-2Dmodel_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=44GJlqxqB0YK5G9gb1TUzAobugMHxDWflaPCZ3IYpKA&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dnetmod-2Dacl-2Dmodel_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=44GJlqxqB0YK5G9gb1TUzAobugMHxDWflaPCZ3IYpKA&e=>
>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Dacl-2Dmodel-2D17&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=rbm91SSJ_0sxFxb692d0FH0G-dbBTAUCf2KRySyztJQ&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Dacl-2Dmodel-2D17&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=rbm91SSJ_0sxFxb692d0FH0G-dbBTAUCf2KRySyztJQ&e=>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dnetmod-2Dacl-2Dmodel-2D17&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=siypyBn3F8o6bsB3Z3E5qS0uaSq2EUGUPwirx_a_KDw&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dnetmod-2Dacl-2Dmodel-2D17&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=siypyBn3F8o6bsB3Z3E5qS0uaSq2EUGUPwirx_a_KDw&e=>
>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dnetmod-2Dacl-2Dmodel-2D17&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=t2lpzSSW72BvQK1VjPoxX0ADxhb9ZD0fp3fXqcd80g8&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dnetmod-2Dacl-2Dmodel-2D17&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=t2lpzSSW72BvQK1VjPoxX0ADxhb9ZD0fp3fXqcd80g8&e=>
>> 
>> 
>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>> 
>> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=xP7z9VxUgtOtSVIgqPF5RKIqTOi6wj-HEXvZKBRTiUw&e= <https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=xP7z9VxUgtOtSVIgqPF5RKIqTOi6wj-HEXvZKBRTiUw&e=>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=OKIVLXLo0Rsrf1DSoLWSyHj97DuE6vuaJ4Cqk_oi1HA&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=OKIVLXLo0Rsrf1DSoLWSyHj97DuE6vuaJ4Cqk_oi1HA&e=>
> 
> Mahesh Jethanandani
> [email-masked] <mailto:[email-masked]>
> 
> [email-masked] <mailto:[email-masked]>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=OKIVLXLo0Rsrf1DSoLWSyHj97DuE6vuaJ4Cqk_oi1HA&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=OKIVLXLo0Rsrf1DSoLWSyHj97DuE6vuaJ4Cqk_oi1HA&e=>
Mahesh Jethanandani
[email-masked]

---

From: Kent Watsen <[email-masked]>
Date: Tue, 13 Mar 2018 22:23:22 +0000

Hi Mahesh,

Please look for <KENT> below.

Thanks,
Kent

On 3/8/18, 7:40 PM, "Mahesh Jethanandani" <[email-masked]<mailto:[email-masked]>> wrote:

Kent,

On Mar 7, 2018, at 1:55 PM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

Hi Mahesh,

Thanks,
Kent

From Idnits:

In the Abstract:

Added.

In the Introduction:

OLD:

NEW:

<KENT>or how about "An ACL is a user-ordered set of rules"?

How about this?

OLD:

NEW:

<KENT>or how about "The match criteria can be a multiplicity of criteria, all of which must be true for the match to occur.   The match criteria may match against values in the packet header or against vendor-specific metadata about the packet."?   - or something in between?

Ok.

NEW:

<KENT> or maybe "unbounded"?

In Section 3:

s/have/has/.

<KENT> see above (my comment before last, it is the same sentence, right?)

Ok

How about:

<KENT>or maybe "When applied to interfaces of a networked device, distinct ACLs are defined for the ingress (input) and egress (output) directions."

Removed.

In Section 3.1:

Done.

In Section 4.1:

OLD:

NEW:

<KENT> it's more than the word "standard".  Maybe something like this:  The "ietf-access-control-list"
module defines a container called "access-list"  - what do you think?

<KENT>BTW, why is the container called "access-lists" and not e.g., "acls".  I thought that there was a node-naming idiom along the lines of "/widgets/widget" for when a list is a descendent of a container.

s/stores/has/

Ok.

Ok.

<KENT>But my comment is more that "primarily" seems wishy-washy.  It seems like it doesn't *primarily* do something, it actually does it.   If there is a grey area, where it might match something else, if possible, maybe it would help to call that out?

Ok.

Ok.

<KENT>actually, I'm just going off the fact that the list node is call "acl", which is singular.  Perhaps even better would be to say:  It can contain one or more "acl" nodes - thoughts?

Ok.

Ok.

Fixed.

Fixed.

How about:

<KENT>I like my framing better because 1) it is less committal about the future and 2) it doesn't limit there to being just one 'case' statement that might be added in the future.

<KENT>any update on this?

Fixed.

In Section 4.2:

Ok.

Fixed.

Ok.

Added.

Ok.

In Section 4.3:

Fixed.

In Section 4.4:

Fixed.

<KENT> BTW, I missed it before, but I think the 4.4 section title should be
plural: "Port Range Usage Examples"

Will change the example.

<KENT> was it changed per the next item below, or something else?

Ok.

In Section ??:

In Section 6:

Fixed.

In Section 6.1:

Fixed.

In Section A.1:

Both fixed.

In Section A.3;

Added.

Thanks.

<KENT>np

Kent // shepherd

On Mar 3, 2018, at 2:13 PM, [email-masked]<mailto:[email-masked]> wrote:

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=BgyjnfSrZfswWrTMiW-PdKEJUEl3IXtwCSo1PQyVUaA&s=4FjGOld49GwI0moZ7h6ltluv0RXN1rPmGp0d-8mjDmA&e=>.

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=OKIVLXLo0Rsrf1DSoLWSyHj97DuE6vuaJ4Cqk_oi1HA&e=

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=huBe-BRKk8B5XCRf7lG_gWUwZNr67SAA8GHfgYnyZoc&s=OKIVLXLo0Rsrf1DSoLWSyHj97DuE6vuaJ4Cqk_oi1HA&e=

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 13 Mar 2018 18:46:59 -0700

> On Mar 13, 2018, at 3:23 PM, Kent Watsen <[email-masked]> wrote:
> 
> Hi Mahesh,
>  
> On 3/8/18, 7:40 PM, "Mahesh Jethanandani" <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Kent,
> 
> 
>> On Mar 7, 2018, at 1:55 PM, Kent Watsen <[email-masked] <mailto:[email-masked]>> wrote:
>>  
> <KENT>or how about "An ACL is a user-ordered set of rules”?

Ok.

> <KENT>or how about "The match criteria can be a multiplicity of criteria, all of which must be true for the match to occur.   The match criteria may match against values in the packet header or aga…

Or simply as:

“The match criteria allows for definition of packet headers and metadata, all of which must be true for the match to occur."

> <KENT> or maybe "unbounded”?

Ok.

> <KENT> see above (my comment before last, it is the same sentence, right?)

Once we agree on the above comment, I will replicate it.

> <KENT>or maybe "When applied to interfaces of a networked device, distinct ACLs are defined for the ingress (input) and egress (output) directions.”

Ok.

Ok.

> <KENT>BTW, why is the container called "access-lists" and not e.g., "acls".  I thought that there was a node-naming idiom along the lines of "/widgets/widget" for when a list is a descendent of a c…

History. When we inherited the draft, it was named access-lists. I can change it to “acls”.

> <KENT>But my comment is more that "primarily" seems wishy-washy.  It seems like it doesn't *primarily* do something, it actually does it.   If there is a grey area, where it might match something e…

Ok. Will drop the word “primarily”.

> <KENT>actually, I'm just going off the fact that the list node is call "acl", which is singular.  Perhaps even better would be to say:  It can contain one or more "acl" nodes - thoughts?

But even nodes is a plural. So what would be the difference between “acls” and “acl nodes”. I would rather have the RFC editor deal with this.

Ok.

> <KENT>any update on this?

Yes, it is possible for both the “egress-interface” and “ingress-interface” to be specified at the same time.

> plural: "Port Range Usage Examples”

The title now reads:

"Port Range Usage and Other Examples”. See below.

> <KENT> was it changed per the next item below, or something else?

Changed the example to an ACE entry that drops all ping requests.

>>> On Mar 3, 2018, at 2:13 PM, [email-masked] <mailto:[email-masked]> wrote:
>>> 
>>> 
>>> until the htmlized version and diff are available at tools.ietf.org <https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=BgyjnfSrZfswWrTMiW-PdKEJUEl3IXtwCSo1PQyVUaA&s=4FjGOld49GwI0moZ7h6ltluv0RXN1rPmGp0d-8mjDmA&e=>.
>>> 

Mahesh Jethanandani
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 14 Mar 2018 08:28:26 -0700

Hi Mahesh,

Just one point.

On 13.03.18 18:46, Mahesh Jethanandani wrote:
>> <KENT>or how about "The match criteria can be a multiplicity of
>> criteria, all of which must be true for the match to occur.   The
>> match criteria may match against values in the packet header or
>> against vendor-specific metadata about the packet."?   - or something
>> in between?
>
> Or simply as:
>
> “The match criteria allows for definition of packet headers and
> metadata, all of which must be true for the match to occur."

So long as we make clear what the null set means.  To me, that's "match
everything".

Eliot

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 14 Mar 2018 10:14:00 -0700

> On Mar 14, 2018, at 8:28 AM, Eliot Lear <[email-masked]> wrote:
> 
> Hi Mahesh,
> 
> Just one point.
> 
> So long as we make clear what the null set means.  To me, that's "match everything”.

The description under the ‘matches’ container says:

                If no matches are defined in a particular container,
                then any packet will match that container. If no
                matches are specified at all in an ACE, then any
                packet will match the ACE.

Mahesh Jethanandani
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Wed, 14 Mar 2018 10:14:11 -0700

>                 packet will match the ACE.

Right.  And that's good.

Eliot

---

From: Kent Watsen <[email-masked]>
Date: Wed, 14 Mar 2018 17:42:16 +0000

Hi Mahesh,  please look for <<KENT>> below.

All, please take a look at the question around renaming the "access-lists" container.

Thanks,
Kent

On 3/13/18, 9:46 PM, "Mahesh Jethanandani" <[email-masked]<mailto:[email-masked]>> wrote:

On Mar 13, 2018, at 3:23 PM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

Hi Mahesh,

Thanks,
Kent

Kent,

Hi Mahesh,

Thanks,
Kent

From Idnits:

In the Abstract:

Added.

In the Introduction:

OLD:

NEW:

Ok.

How about this?

OLD:

NEW:

Or simply as:

<<KENT>> okay

Ok.

NEW:

Ok.

In Section 3:

s/have/has/.

<<KENT>> okay.

Ok

How about:

Ok.

Removed.

In Section 3.1:

Done.

In Section 4.1:

OLD:

NEW:

Ok.

<<KENT>> I think it should be "acls", but I wouldn't want to make this change unilaterally.
Does anybody else have an issue with the container being called "access-lists" ?

s/stores/has/

Ok.

Ok.

Ok.

Ok.

<<KENT>> My issue isn't so much the plurality, as it is matching what is in the YANG.   The node is called "acl", so then you want to say that there are multiple "acl" nodes (not "acls").  In fact, putting "acls" would be even more confusing is the "access-lists" container is renamed to "acls".

Ok.

Ok.

Fixed.

Fixed.

How about:

Ok.

<<KENT>> okay, then maybe there can be an explanation of what happens when that occurs?

Fixed.

In Section 4.2:

Ok.

Fixed.

Ok.

Added.

Ok.

In Section 4.3:

Fixed.

In Section 4.4:

Fixed.

The title now reads:

<<KENT>> works for me.

Will change the example.

<<KENT>> okay.  But please tweak all your examples so that a '\' line-wrapping isn't
happening for a single charater.  e.g., remove one space from the indent or put the
xmlns on its own line.

Ok.

In Section ??:

In Section 6:

Fixed.

In Section 6.1:

Fixed.

In Section A.1:

Both fixed.

In Section A.3;

Added.

Thanks.

<KENT>np

Kent // shepherd

Abstract:

Mahesh Jethanandani

Mahesh Jethanandani

Mahesh Jethanandani

---

From: Eliot Lear <[email-masked]>
Date: Wed, 14 Mar 2018 11:56:03 -0700

On 14.03.18 10:42, Kent Watsen wrote:
>
>     <KENT>BTW, why is the container called "access-lists" and not
>     e.g., "acls".  I thought that there was a node-naming idiom along
>     the lines of "/widgets/widget" for when a list is a descendent of
>     a container.
>
>  
>

I would be opposed to a change at this point.  It doesn't change
functionality and we're not saving that many characters.  What is there
is clear.  Please can we just leave this alone.

Eliot

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 14 Mar 2018 12:27:04 -0700

> On Mar 14, 2018, at 10:42 AM, Kent Watsen <[email-masked]> wrote:
> 
> On 3/13/18, 9:46 PM, "Mahesh Jethanandani" <[email-masked] <mailto:[email-masked]>> wrote:
>  
>  
> 
> 
>> On Mar 13, 2018, at 3:23 PM, Kent Watsen <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Hi Mahesh,
>>  
> Does anybody else have an issue with the container being called "access-lists” ?

> <<KENT>> My issue isn't so much the plurality, as it is matching what is in the YANG.   The node is called "acl", so then you want to say that there are multiple "acl" nodes (not "acls").  In fact, putting "acls" would be even more confusing is the "access-lists" container is renamed to "acls”.

Ok. I can reword the sentence to say “It can have one more acl nodes”.

> <<KENT>> okay, then maybe there can be an explanation of what happens when that occurs?

It is a matching leaf, and technically one can match on more than one leaf. So a ‘must’ statement is not needed from a model perspective. Generally though, the packet is either coming in on an ingress (input) interface or going out a output (egress) interface, and one would should have separate ACE entries for each direction the packet travels through the interface. The match will fail if both directions of the interface are specified in the same ACE entry. But isn’t that obvious?

Mahesh Jethanandani
[email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 14 Mar 2018 20:30:20 +0000

I agree that if one is to be consistent with the rest of the model, e.g., “aces”, it should be “acls”. However, both are a bit cryptic. Having said that, “access-lists” isn’t really correct if you’re  going to expand it, it should be “access-control-lists”.

Thanks,
Acee

From: netmod <[email-masked]> on behalf of Mahesh Jethanandani <[email-masked]>
Date: Wednesday, March 14, 2018 at 3:26 PM
To: Kent Watsen <[email-masked]>
Cc: NETMOD WG <[email-masked]>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-17.txt

On Mar 14, 2018, at 10:42 AM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Kent

Hi Mahesh,

Thanks,
Kent

Kent,

Hi Mahesh,

Thanks,
Kent

From Idnits:

In the Abstract:

Added.

In the Introduction:

OLD:

NEW:

Ok.

How about this?

OLD:

NEW:

Or simply as:

<<KENT>> okay

Ok.

NEW:

Ok.

In Section 3:

s/have/has/.

<<KENT>> okay.

Ok

How about:

Ok.

Removed.

In Section 3.1:

Done.

In Section 4.1:

OLD:

NEW:

Ok.

s/stores/has/

Ok.

Ok.

Ok.

Ok.

Ok.

Ok.

Fixed.

Fixed.

How about:

Ok.

Fixed.

In Section 4.2:

Ok.

Fixed.

Ok.

Added.

Ok.

In Section 4.3:

Fixed.

In Section 4.4:

Fixed.

The title now reads:

<<KENT>> works for me.

Will change the example.

Ok.

In Section ??:

In Section 6:

Fixed.

In Section 6.1:

Fixed.

In Section A.1:

Both fixed.

In Section A.3;

Added.

Thanks.

<KENT>np

Kent // shepherd

Abstract:

Mahesh Jethanandani

Mahesh Jethanandani

Mahesh Jethanandani

Mahesh Jethanandani

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 14 Mar 2018 15:04:18 -0700

If we agree to make any change, and currently I do not see a consensus on it, it would be to make it 'acls'. Expanding it to 'access-control-lists', would beg the question of why not expand 'acl', 'ace' and 'aces', and we do not want to go there.

Mahesh Jethanandani 
[email-masked]

> On Mar 14, 2018, at 1:30 PM, Acee Lindem (acee) <[email-masked]> wrote:
> 
> On 3/13/18, 9:46 PM, "Mahesh Jethanandani" <[email-masked]> wrote:
>  
>  
> 
> 
> 
> On 3/8/18, 7:40 PM, "Mahesh Jethanandani" <[email-masked]> wrote:
>  
> Kent,
> 
> 
> 
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 14 Mar 2018 22:12:41 +0000

Agreed – I was just making the point that “access-lists” isn’t correct. It seems there have been other non-backward compatible changes to the model, so I don’t see why you wouldn’t fix it.
Thanks,
Acee

From: Mahesh Jethanandani <[email-masked]>
Date: Wednesday, March 14, 2018 at 6:04 PM
To: Acee Lindem <[email-masked]>
Cc: Kent Watsen <[email-masked]>, NETMOD WG <[email-masked]>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-17.txt

Mahesh Jethanandani

On Mar 14, 2018, at 1:30 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
I agree that if one is to be consistent with the rest of the model, e.g., “aces”, it should be “acls”. However, both are a bit cryptic. Having said that, “access-lists” isn’t really correct if you’re  going to expand it, it should be “access-control-lists”.

Thanks,
Acee

From: netmod <[email-masked]<mailto:[email-masked]>> on behalf of Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 14, 2018 at 3:26 PM
To: Kent Watsen <[email-masked]<mailto:[email-masked]>>
Cc: NETMOD WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-17.txt

Thanks,
Kent

Hi Mahesh,

Thanks,
Kent

Kent,

Hi Mahesh,

Thanks,
Kent

From Idnits:

In the Abstract:

Added.

In the Introduction:

OLD:

NEW:

Ok.

How about this?

OLD:

NEW:

Or simply as:

<<KENT>> okay

Ok.

NEW:

Ok.

In Section 3:

s/have/has/.

<<KENT>> okay.

Ok

How about:

Ok.

Removed.

In Section 3.1:

Done.

In Section 4.1:

OLD:

NEW:

Ok.

s/stores/has/

Ok.

Ok.

Ok.

Ok.

Ok.

Ok.

Fixed.

Fixed.

How about:

Ok.

Fixed.

In Section 4.2:

Ok.

Fixed.

Ok.

Added.

Ok.

In Section 4.3:

Fixed.

In Section 4.4:

Fixed.

The title now reads:

<<KENT>> works for me.

Will change the example.

Ok.

In Section ??:

In Section 6:

Fixed.

In Section 6.1:

Fixed.

In Section A.1:

Both fixed.

In Section A.3;

Added.

Thanks.

<KENT>np

Kent // shepherd

Abstract:

Mahesh Jethanandani

Mahesh Jethanandani

Mahesh Jethanandani

Mahesh Jethanandani

---

From: Kent Watsen <[email-masked]>
Date: Wed, 14 Mar 2018 22:14:12 +0000

Hi Mahesh,

Two instances of <<<KENT>>> below.

Kent // shepherd

On 3/14/18, 3:27 PM, "Mahesh Jethanandani" <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Kent

Hi Mahesh,

Thanks,
Kent

Kent,

Hi Mahesh,

Thanks,
Kent

From Idnits:

In the Abstract:

Added.

In the Introduction:

OLD:

NEW:

Ok.

How about this?

OLD:

NEW:

Or simply as:

<<KENT>> okay

Ok.

NEW:

Ok.

In Section 3:

s/have/has/.

<<KENT>> okay.

Ok

How about:

Ok.

Removed.

In Section 3.1:

Done.

In Section 4.1:

OLD:

NEW:

Ok.

s/stores/has/

Ok.

Ok.

Ok.

Ok.

<<<KENT>>> great, but don't forget the "or"  ;)

Ok.

Ok.

Fixed.

Fixed.

How about:

Ok.

<<<KENT>>> Yes, but matches are typically additive, but here they zero each other out.  When before you wrote that it was possible for these to be specified at the same time, you just meant the current model's syntax allows it, but it doesn't make semantic sense to do so?   If true, then why wouldn't there be a 'must' expressions preventing the possibility?

Fixed.

In Section 4.2:

Ok.

Fixed.

Ok.

Added.

Ok.

In Section 4.3:

Fixed.

In Section 4.4:

Fixed.

The title now reads:

<<KENT>> works for me.

Will change the example.

Ok.

In Section ??:

In Section 6:

Fixed.

In Section 6.1:

Fixed.

In Section A.1:

Both fixed.

In Section A.3;

Added.

Thanks.

<KENT>np

Kent // shepherd

Abstract:

Mahesh Jethanandani

Mahesh Jethanandani

Mahesh Jethanandani

Mahesh Jethanandani

---

From: Kristian Larsson <[email-masked]>
Date: Thu, 15 Mar 2018 16:45:41 +0100

Gentlemen,

... snip snip...
On 2018-03-09 01:40, Mahesh Jethanandani wrote:
> Choice of source port definition using range/operator or referring to a 
> group of source ports, to be added as a future 'case' statement.
> 

It is possible to match both egress-interface and ingress-interface in 
the same ACL. Different devices support different type of attachment 
points for ACLs. Most routers, like an ASR9k or Juniper MX, supports 
attaching ACLs on interfaces in either ingress or egress direction. If 
we apply ACL FOO ingress on interface BAR then it would perhaps be weird 
to use the ingress-interface match in the FOO ACL since 
ingress-interface will always be BAR for every packet evaluated. Using 
egress-interface would make a lot more sense (and we will know the 
egress-interface if the platform performs the route lookup before 
evluating the ACL which is an implementation issue). We could introduce 
a must constraint to avoid a silly situation but I don't think that's a 
real improvement on the model.

Above all, considering the other type of attachment, which we find among 
others on Linux with iptables or nftables, which is a sort of "global" 
attachment point, it makes sense to be able to specify both. nftables 
rules are not written and attached to a particular interface but rather 
end up in a central list of rules and so it makes sense being able to 
write individual rules that match on ingress-interface, egress-interface 
or both (or none). A must constraint would make that impossible, so 
please don't add a must.

Kind regards,
    Kristian.