Subject: [netmod] WG Last Call: draft-ietf-netmod-acl-model-01.txt

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 6 Feb 2015 13:59:30 -0500

This commences a NETMOD WG Last call for draft-ietf-netmod-acl-model-01.txt.  Please send comments to the list by 20-FEB-2015 by 9AM EST.

Tom and Juergen, NETMOD WG Chairs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Feb 2015 21:15:46 +0100

> This commences a NETMOD WG Last call for draft-ietf-netmod-acl-model-01.txt.  Please send comments to the list by 20-FEB-2015 by 9AM EST.

Before I read this in detail already a few quick comments:

- The module name 'packet-fields' should follow RFC 6020 guidelines.

- Non-normative example modules should be in an appendix marked as
  non-normative.

- The security considerations include a TBD action item.

- If ietf-route-filter.yang is an example, I would probably give it a
  different name that has less chance to be confused with an official
  module.

/js

-- 
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: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Feb 2015 22:14:04 +0100

>   different name that has less chance to be confused with an official

More comments:

- Why do you use the prefix 'ietf' for ietf-yang-types? The default
  would have been 'yang'.

- How is the packet-fields module updated? IETF process? Is this a
  candidate for IANA maintenance?

- Do we need a copyright notice in the module descriptions?

- The description of the revision does not make much sense, and the
  reference even less. I suggest to follow the YANG guidelines,
  RFC 6087.

- Is layer 2 always ethernet or is this

    identity eth-acl {
       base "acl:acl-base";
       description "layer 2 ACL type";
     }

  just a misnomer? Perhaps the description of ip-acl also should be
  "IP layer ACL type" to be precise. But then, the associated grouping
  also includes layer 4 elements (port number ranges).

- Since access-list/acl-type is optional, what is the meaning if it is
  not present?

- I have no clue what to expect in the targets strings in
  acl-oper-data/targets.

- The description of access-list talks about sequence numbers - I
  could not find them. Perhaps the text is outdated?

- I personally would not inline the operational state nodes but this
  may be personal preference.

- Is 'entry' the same as 'rule'? If so, why do we use two terms if one
  would be sufficient?

- I do not understand this:

      The time range is identified by a name
      and then referenced by a function, so that those
      time restrictions are imposed on the function itself.

  I was surprised to find this since the introductory text never
  mentions time filters, it only talks about about packet filters and
  metadata filters. Well, this is filtering on the meta data when a
  packet is received but perhaps this deserves to be mentioned
  somewhere earlier.

- You will be asked later on anyway to use the reserved example IP
  addresses in the examples, so make the changes now.

- In the example in section 4.4, I suggest to remove all the
  edit-config stuff and to show only the config itself. I am also not
  sure the example is correct, has this been validated against the
  schema?

- The explanation given at the beginning of section 4.5 belongs into
  the data model definition. What happens if I configure only an
  upper-port? What if I leave both ports out? What happens if the
  lower-port is larger than the upper-port?

- I generally suggest to use the prefixed defined in an imported
  module unless there is a name clash that makes this impossible.  If
  we always write inet:ipv4-prefix (where possible), it becomes
  simpler for human readers to read modules.

- reference " "; avoids a warning but is otherwise not useful

- The biggest thing that is unclear to me is how these generic acls
  are used in certain contexts. In the operational state, there is a
  list of opaque target strings but I do not know what they contain or
  how they are configured. So how do I use these generic acls?
  Suppose I want to use these acls to control access to my NC
  server. How would I have to extend the NC server config model to do
  that?

- The IANA considerations are incomplete since I think you have two
  modules that need registration.

- Since Section 10 is empty, remove it.

/js

---

From: "Dana Blair (dblair)" <[email-masked]>
Date: Thu, 12 Feb 2015 20:07:19 +0000

Great comments.  The authors are meeting right now and will get back to
the list.

thanks,
Dana

On 2/6/15, 4:14 PM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

>> > This commences a NETMOD WG Last call for
>>draft-ietf-netmod-acl-model-01.txt.  Please send comments to the list by
>>20-FEB-2015 by 9AM EST.
>> >
>> 
>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: "Dana Blair (dblair)" <[email-masked]>
Date: Tue, 17 Feb 2015 14:57:22 +0000

We¹re finalizing updates but have a few clarifying questions and some

>- Since access-list/acl-type is optional, what is the meaning if it is

Not sure what this means.  Can you provide more detail on what you are
looking for ?

>The explanation given at the beginning of section 4.5 belongs into
>  upper-port?

Not allowed.

>What if I leave both ports out? What happens if the

Here is the behavior we want:
source-port-range is not required.  If not present, no port matching.
if present, then lower is required.  If only lower port is present, then a
single
port match.  If lower and upper is present, then it is a multiple port
match.

>  lower-port is larger than the upper-port?

Is there a way in the yang language to enforce upper to be higher than
lower ? 

Otherwise, it will return a run time error.

>- reference " "; avoids a warning but is otherwise not useful

We prefer to avoid warnings.

>The biggest thing that is unclear to me is how these generic acls

Many acls are used for packet filter on interfaces.

Should we update the interfaces.yang module to allow applying an acl ?

Also could be used in routing-cfg.yang module.  Should we update that
 model too ?

>The IANA considerations are incomplete since I think you have two

packet-fields but what is the other one ?  please be specific. - Dana

>- Since Section 10 is empty, remove it.

ok.

thanks,

Dana

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 17 Feb 2015 16:31:05 +0100

> Not sure what this means.  Can you provide more detail on what you are

If this leaf is not present, what happens with the rest that depends
on the type? Is it useful to have this leaf optional?
 
> Otherwise, it will return a run time error.

You can use must statements or description clauses. I think a runtime
error would be a very bad idea. Invalid config should not be accepted
and then lead to runtime errors.

> We prefer to avoid warnings.

But this is then a useless statement.

> Should we update the interfaces.yang module to allow applying an acl ?

No, why would you update interfaces.yang? I would have expected an
augmentation.

> Also could be used in routing-cfg.yang module.  Should we update that

Again, this should be an augmentation.
 
> packet-fields but what is the other one ?  please be specific. - Dana

I think this is is at least ietf-acl and packet-fields (which needs to
get a better name).

/js

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 17 Feb 2015 16:35:13 +0000

One inline below. 

>Again, this should be an augmentation.

Routing policy will be done in a separate draft. Do not augment
routing-cfg as the existing attachment points are being removed. Also, a
prefix-list (present in both the BGP drafts is much more suited to routing
policy). 

Thanks,
Acee

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 17 Feb 2015 21:56:01 +0000

snip for better clarity

> prefix-list (present in both the BGP drafts is much more suited to routing
I think here is some clarification needed

Routing Policy allows you to modify the routes that are advertised to or accepted from a neighbor while using any of the supported routing protocols.

Policy Based Routing (PBR)  (or Filter Based Forwarding in Junos lingo) is an approach where you override some of the fundamental rules of destination based routing and forward packets based on other characteristics of the incoming packets.  This is achieved by writing firewall filters that match the relevant characteristics of the incoming packet (src ip, dst ip, src port, dst port, protocol, packet size, etc) and modify the next-hop based on that match.  The packet is then forwarded to that next-hop rather than using the next-hop associated with the destination ip address alone. 

I think that current ACL model is very well suited for PBR.

For routing policy, you define match conditions followed by action. In Junos, routing policy is defined as a container of terms. Term is another container, that has match condition and action.
If you compare it to ACL model, ACL is container of ACEs. Each ACE is a container that has match condition and action. 

I would argue that each policy could be modeled as such, but that might be long, long shot. I hope we can agree to use ACL model for PBR, where for routing policy I would be happy to present it as an option ...

Dean

---

From: Thomas D. Nadeau <[email-masked]>
Date: Fri, 27 Feb 2015 13:53:27 -0500

The Working Group Last call for this document has concluded. 

	Authors/editors, there were several comments made on the list. Please address those ASAP and publish an update to the document.  Please inform the WG when the updates have been made so that the folks who made comments can determine if their changes have been addressed.

	Thank you,

	—Tom

> On Feb 6, 2015:1:59 PM, at 1:59 PM, Thomas D. Nadeau <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>