Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06

From: Eliot Lear <[email-masked]>
Date: Mon, 4 Jan 2016 19:23:38 +0100

Hi Juergen,

On this point:

On 12/21/15 4:33 PM, Juergen Schoenwaelder wrote:

> And
>  should the interface reference not use a more specific type than
>  'string’?
>> Interface references can be many things, from standard naming we are familiar, e.g. ge-1/0/0.1 to a numerical value like 13276. Leaving it as string gives us most flexibility in that regards.
> I disagree that the goal here is most flexibility. We do have an
> interfaces data model in the IETF. Why are we avoiding to refer to it
> here?
>

I think it would be helpful if you could be specific as to your
concern.  It is absolutely the case that the SNMP folk did an awful lot
of work on managing interfaces.  While I am not concerned about the form
of the name, I wonder if your concern is around some of the semantics,
but I can't tell.

Eliot

---

From: Andy Bierman <[email-masked]>
Date: Mon, 4 Jan 2016 10:45:03 -0800

Hi,

I think this issue was discussed at length during ietf-interfaces work.
The WG gave up on the ideal goal that an NMS can pick the interface name
as if it were just another administrative string.  Instead, every vendor
can have
their own rules for embedded semantics in the identifier.  Every server can
reject perfectly valid interface names because they are the "wrong" value
for that specific port (where the "right" value is up to the NMS to know
because it is out of scope for the standard).

It may take another decade to get rid of all the bad decisions CLI
has given to network management.

Andy

On Mon, Jan 4, 2016 at 10:23 AM, Eliot Lear <[email-masked]> wrote:

> >> Interface references can be many things, from standard naming we are
> familiar, e.g. ge-1/0/0.1 to a numerical value like 13276. Leaving it as
> string gives us most flexibility in that regards.
> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors
>
>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 4 Jan 2016 22:24:36 +0100

Hi,

I guess what I'm hearing is that we should do a hopefully very short
augmentation for domain names in the matches clause and standardize that
separately.  Does that seem reasonable?

Eliot

On 12/19/15 2:05 PM, Dean Bogdanovic wrote:
> The basic design idea for the base model is structure that all vendors support. Some of the examples mentioned below, like FQDN, are not supported by all vendors and are protected by IPR (which I wasn’t aware of it). There are many possible match conditions that could be added to the base model, like Auth header in IPSec or IPSec encapsulation security payload to keep it with security. There are many match conditions in Class of Services as well. All these match conditions would have created more issues to come to consensus about the base model, so for that reason we went with the minimal model that would be easy for all vendors to implement.
>
> Dean
>
>> On Dec 18, 2015, at 5:21 PM, Sterne, Jason (Jason) <[email-masked]> wrote:
>>
>> I'm not a fan of adding something like that in the base model.  Let's get a basic model done and then we can consider an extension draft.  I'd think that things like TCP flags, for example, would be a more natural & common thing to add to an ACL model than a host name match so I can't see host name being in there before TCP flags (which I'm not advocating for in the base model).
>>
>> I also don't think the metadata interface match should be in this base model either.  That is out of place IMO.  The base model provides an ACL that can then get associated with objects like interfaces (as in the example in section A.3)
>> I'd also suggest we consider making the actions 'deny' and 'permit' presence containers instead of empty leafs.  That would allow easier augmentations (e.g. additional 'permit' parameters for policy based forwarding for example).
>>
>> Regards,
>> Jason
>>
>> -----Original Message-----
>> From: netmod [mailto:[email-masked]] On Behalf Of Nadeau Thomas
>> Sent: Thursday, December 17, 2015 10:53
>> To: Lear Eliot
>> Cc: Benoit Claise; RTG YANG Design Team; netmod WG
>> Subject: Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06
>>
>>
>> 	You raise a good point. Do the contributors/editors have any thoughts on this suggestion?
>>
>> 	—Tom
>>
>>
>>> On Dec 17, 2015:9:44 AM, at 9:44 AM, Eliot Lear <[email-masked]> wrote:
>>>
>>>
>>>
>>> On 12/17/15 2:45 PM, Nadeau Thomas wrote:
>>>> 	Do you mean an ASCII DNS name (versus an IP address w a mask)?
>>> I was thinking of "host" in RFC 6021.
>>>
>>> Eliot
>>>
>>>
>> netmod mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netmod
>> Rtg-dt-yang-arch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Jan 2016 10:30:28 +0100

> of the name, I wonder if your concern is around some of the semantics,

My question is why the model does not use interface-ref or
interface-state-ref defined in RFC 7223 but instead an opaque string
to refer to an interface. Have we thought about the design tradeoffs?

My question is _not_ about how we deal with interface naming schemes,
that discussion took place when RFC 7223 was created.

/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: Dean Bogdanovic <[email-masked]>
Date: Wed, 6 Jan 2016 16:59:54 +0100

> On Jan 4, 2016, at 10:24 PM, Eliot Lear <[email-masked]> wrote:
> 
> Hi,
> 

Yes, if you think there is a need for such a draft and IPR issue is cleared, WG adopts it, why not

Dean

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 6 Jan 2016 18:28:41 +0100

> On Jan 6, 2016, at 10:30 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

In the example where the ACL is attached to the interface, we are using interface-ref, so replacing interface in the metadata, can be easily done.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 6 Jan 2016 19:31:35 +0100

> Yes, if you think there is a need for such a draft and IPR issue is cleared, WG adopts it, why not

The only reason not to do that is you will end up many many of drafts
like mine, dinking the model.  I realize some view that as a positive. 
I'm not so sure.

Eliot

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Jan 2016 09:23:36 +0100

> In the example where the ACL is attached to the interface, we are using interface-ref, so replacing interface in the metadata, can be easily done.

This does not answer why input-interface is of type string... I do not
understand what 'replacing interface in the metadata, can be easily
done' tells me.

/js

---

From: Eliot Lear <[email-masked]>
Date: Thu, 7 Jan 2016 09:59:01 +0100

On 1/7/16 9:23 AM, Juergen Schoenwaelder wrote:
> This does not answer why input-interface is of type string...

To be perfectly clear you seek that type string be replaced with
interface-ref?

Eliot

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Jan 2016 10:07:15 +0100

> To be perfectly clear you seek that type string be replaced with

I think for this leaf the type of choice would be interface-state-ref
unless there are strong reasons to use something opaque.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 7 Jan 2016 10:16:43 +0100

> On 07 Jan 2016, at 10:07, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Unfortunately, this is impossible because configuration leafrefs cannot refer to leafs in state data.

Should this CLR be removed? IMO, yes.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Jan 2016 10:24:43 +0100

> Unfortunately, this is impossible because configuration leafrefs cannot refer to leafs in state data.

The problem is that the config true on input-interface is perhaps an
error given the description:

    leaf input-interface {
        type string;
        description
           "Packet was received on this interface.";
    }

This sounds to me like state data.

> Should this CLR be removed? IMO, yes.

No.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 7 Jan 2016 10:26:45 +0100

> On 07 Jan 2016, at 10:24, Juergen Schoenwaelder <[email-masked]> wrote:
> 

As I understand it, it is a match condition for a received packet, i.e. configuration.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Jan 2016 10:29:55 +0100

> As I understand it, it is a match condition for a received packet, i.e. configuration.

Maybe that is true but then the description is rather misleading.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 7 Jan 2016 10:35:56 +0100

> On 07 Jan 2016, at 09:59, Eliot Lear <[email-masked]> wrote:
> 
> 
> 

This would be somewhat awkward for interfaces for which no configuration exist - a dummy configuration entry would need to be created. This might have been the reason why the authors chose a simple string. The same problem appears elsewhere, too.

Lada

---

From: Dean Bogdanovic <[email-masked]>
Date: Thu, 7 Jan 2016 15:23:14 +0100

> On Jan 7, 2016, at 10:07 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

We interface-state-ref, the interface has to exists. With interface-ref, the interface doesn’t have to exists in order for the configuration to be committed. So if you reference to something opaque is that interface doesn’t necessarily exist, then this is what we wanted to achieve.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 7 Jan 2016 15:35:44 +0100

> Maybe that is true but then the description is rather misleading.

I agree that is configuration information and that the wording is
imperfect.  How about this:

"Interface upon which a packet is received."

Eliot

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Jan 2016 16:21:42 +0100 (CET)

Dean Bogdanovic <[email-masked]> wrote:
> 
> > On Jan 7, 2016, at 10:07 AM, Juergen Schoenwaelder
> > <[email-masked]> wrote:
> > 
> We interface-state-ref, the interface has to exists.

With YANG 1.1, a leafref can be marked as "require-instance false",
which allows a interface-state-ref to be used in config:

   type if:interface-state-ref {
     require-instance false;
   }
   // + add description that explains what happens if there is no such
   //   instance

(NOTE: this doesn't work w/ pyang at the momement, I am working on a
fix)

/martin

> With
> interface-ref, the interface doesn’t have to exists in order for the
> configuration to be committed. So if you reference to something opaque
> is that interface doesn’t necessarily exist, then this is what we
> wanted to achieve.

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 07 Jan 2016 16:39:45 +0100 (CET)

Hi,

> (NOTE: this doesn't work w/ pyang at the momement, I am working on a

FYI, I have fixed pyang now (branch yang-1.1) to allow
require-instance in derived leafrefs.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Jan 2016 16:45:23 +0100

> (NOTE: this doesn't work w/ pyang at the momement, I am working on a

And it would have to be if:interface-ref instead if:interface-state-ref
I think.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 08 Jan 2016 12:52:37 +0100 (CET)

> And it would have to be if:interface-ref instead if:interface-state-ref

No, I meant interface-state-ref.  This way you can put a filter on
non-configured interfaces.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Jan 2016 13:09:00 +0100

> non-configured interfaces.

But with require-instance false, this is also true for
if:interface-ref.  If I preconfigure and interface, I might also want
to preconfigure ACLs refering the preconfigure interface. And note
that if:interface-state-ref refers to a config false leaf.

/js

---

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 8 Jan 2016 13:12:32 +0100

> On Jan 8, 2016, at 1:09 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

In this case we have to change to yang-version 1.1. The plan was to have it for 1.0. Do we want to move the ACL model to YANG minimum version 1.1?

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 08 Jan 2016 13:24:23 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> if:interface-ref.

Sure.

> If I preconfigure and interface, I might also want
> to preconfigure ACLs refering the preconfigure interface.

But this is also ok for interface-state-ref with require-instance
false.  I prefer this, b/c then we can say that once the target leaf
exists, the filter applies.

> And note

Yes, this is ok w/ require-instance false.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 08 Jan 2016 13:26:19 +0100 (CET)

Dean Bogdanovic <[email-masked]> wrote:
> 
> > On Jan 8, 2016, at 1:09 PM, Juergen Schoenwaelder
> In this case we have to change to yang-version 1.1. The plan was to
> have it for 1.0. Do we want to move the ACL model to YANG minimum
> version 1.1?

I think it is ok.  We're fixing issues like this one in 1.1 so that we
don't have to rely on various workarounds.  Note that the second WGLC
for 1.1 just ended, w/ mostly minor proposed edits.

/martin

---

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 11 Jan 2016 12:16:40 +0100

Are there any other opinions on switching YANG version for ACL model from 1.0 to 1.1? Would like to get more opinions on this, besides Martin.

Dean

> On Jan 8, 2016, at 1:26 PM, Martin Bjorklund <[email-masked]> wrote:
> 
> Dean Bogdanovic <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Robert Wilton <[email-masked]>
Date: Mon, 11 Jan 2016 11:26:01 +0000

Hi Dean,

I agree with Martin's proposed solution.

I.e. switch to YANG 1.1, and use his proposed interface-state-ref & 
require-instance false solution.

Thanks,
Rob

On 11/01/2016 11:16, Dean Bogdanovic wrote:
> Are there any other opinions on switching YANG version for ACL model 
> from 1.0 to 1.1? Would like to get more opinions on this, besides Martin.
>
> Dean
>
>> On Jan 8, 2016, at 1:26 PM, Martin Bjorklund <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>>> <[email-masked] 
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>>> Juergen Schoenwaelder <[email-masked] 
>>>>> <mailto:[email-masked]>> wrote:

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Jan 2016 12:29:10 +0100

I think we discussed at one of the previous IETFs that we will use
YANG 1.1 in the IETF once it is published. Please check the archives.
If I am correct, then you would have to be fast with finishing the ACL
model.

/js

---

From: Nadeau Thomas <[email-masked]>
Date: Mon, 11 Jan 2016 07:51:14 -0500

Yes, this is correct. We agreed to this explicitly.

	—Tom

> On Jan 11, 2016:6:29 AM, at 6:29 AM, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 11 Jan 2016 17:58:52 +0100

> On Dec 21, 2015, at 4:33 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> On Sat, Dec 19, 2015 at 07:50:58AM -0500, Dean Bogdanovic wrote:
>> Juergen,
>> 
>> Please see answers inline
>> 
>> Dean
>> 
>>> On Dec 11, 2015, at 12:31 PM, Juergen Schoenwaelder <[email-masked]> wrote:
>>> 
>>> On Wed, Dec 09, 2015 at 08:27:04AM -0800, Nadeau Thomas wrote:
>>>> 
>>>> 	This email initiates a NETMOD WG Last call for draft-ietf-netmod-acl-model-06. 
>>>> Please review the draft and make any comments to the list by Wednesday, 16 December, 2015
>>>> by 8AM EST.
>>>> 
>>> 
>>> Technical
>>> 
>>> - I am not sure I personally like the acl-oper-data and ace-oper-data
>>> containers in the middle of the config true tree. I understand that
>>> operational state in this case is likely tightly bound to the
>>> lifetime of the config state but I also generally prefer to have a
>>> clean separation of config from state. But since I am not
>>> implementing this, I am happy to leave the decision to those who
>>> write the code.
>>> 
>>> - I would probably have used src-ipv4-prefix and dst-ipv4-prefix
>>> instead of source-ipv4-network and destination-ipv4-network and
>>> I would probably have used src-mac-address and src-mac-address-mask
>>> and dst-mac-address and dst-mac-address-mask. Generally simple
>>> src instead source and dst instead destination - lines up all
>>> much more nicely.
>> 
>> I know that src and dst are pretty standard abbreviations, but have preference to use full words.
>> 
> 
> My eyes prefer the shorter versions but it might be subjective where
> the line between arconyms and words is drawn. For me, things are not
> done consistently according to my personal preferences. ;-)

As many people, so many different preferences :)

> 
>>> - I would have put the acl-name and acl-type first followed by the
>>> entries list.
>> 
>> Can you please expand on this? Is there any major difference? OR just design choice?
> 
> Technically you can define key leafs anywhere but I think there are some
> benefits of defining them at the beginning of a list:
> 
> a) I find it nice if the leafs listed in the key statement follow the
>   key statement and not N pages down the document.
> b) If you put them at the end and you have to add additional definitions,
>   you will end up with leafs somewhere in the middle.
> c) The XML encoding requires to ship key leafs first and it might be
>   simpler if the key leafs are also defined first in the data model
>   (so if you use the same order, you actually get things correct).
> 
> Now you tell me what the advantages are to put them at the end…

I think this ended up being an edit oversight. In the draft 02, the stated leafs were at the top

module: ietf-acl
+--rw access-lists
+--rw access-list* [access-control-list-name]
+--rw access-control-list-name         string
+--rw access-control-list-type?        access-control-list-type
+--ro access-control-list-oper-data
|  +--ro (targets)?
|     +--:(interface-name)
|        +--ro interface-name*   string
+--rw access-list-entries
+--rw access-list-entry* [rule-name]

I don’t remember if there was any specific reason to push the acl-name and acl-type to the end. Will bring it back up.
> 
>>> - I also wonder why we use both the term 'entry' and 'rule', why not
>>> pick one of them? You have for example rule-name (which is the key
>>> of the list but again comes last).
>> This is a bit of compromise between Cisco and Juniper terminology. In Cisco it is ACE and in Juniper term. But in the yang model and in the text we are using consistently one or the other word.
> 
> For the sake of clarity, I personally would prefer to have a single
> term. I think Linux packet filters call things rules. I think BSD
> packet filtering calls things rules. Wikipedia seem say that packet
> filters consist of filtering rules... So I guess I have a preference
> but I will not get a sleepless night over this.

Authors are Cisco/Juniper people, so were using that terminology and I believe that CSCO and JNPR are more used in networking then Linux :)

> 
>>> - Should there be features for ace-eth and ace-ipv4 and ace-ipv6 or do
>>> we expect that all implementations will always support all three?
>>> Another option would be to have the generic model completely without
>>> any protocol specific elements and to have separate models to
>>> augment in ipv4, ipv6, and ethernet specific ace types. I actually
>>> think this would make much more sense since you would not have a
>>> module 'packet fields' but instead a clear extension of the
>>> ietf-access-control-list module. You could also drop the examples
>>> how to extend the core model since the ip and ethernet extensions
>>> would already serve the purpose. You also would not need features
>>> since an implementation advertises the extension modules.
>> 
>> We started early with such design, but then the WG feedback moved us to the current  design.
> 
> Can you provide pointers to minutes etc? I think the routing model
> also has a core model where even unicast routing is augmented in. This
> seems to make the boundary between the generic infrastructure and the
> addins very clear.

I haven’t seen a network device with filters without supporting L2 and L3 types. This is how we started originally, but then comments came in on the mailing list and wanted exact typing. Please see the thread

http://www.ietf.org/mail-archive/web/netmod/current/msg12144.html

Model was changed for IETF 94 and at the WG meeting nobody raised the issue.

> 
>>> - The 'uses packet-fields:metadata' resolves to a leaf
>>> 'input-interface' which is of type string. Is this the only metadata
>>> field we ever envision to be there? If so, why not make it part of
>>> the base model? If not, what is the extensibility model here?  
>> 
>> It can be used for route filtering
> 
> Yeah, but the questions were:
> 
> - Is this the only metadata field we ever envision to be there?
No, it can be timestamp, RIB, VRF, etc.

> - If so, why not make it part of the base model?

We are early in the modeling and people were asking to remove time range from the base model and create separate draft, as many other features are using time-range.
> - If not, what is the extensibility model here?
> 
>>> And

There is discussion in separate thread on this. And it seems we are in agreement to move this model to YANG 1.1 and use Martin B proposed solution.
> 
>>> - Some implementations support the action to jump or goto other
>>> acls. Is this not common enough to include it as a base action,
>>> perhaps protected by a feature?
>> 
>> Yes among vendors, but it can be very specific. Example, in Juniper implementation there are two types of filters, classical and Fast Update Filters (FUF). Classic filters support (on specific HW platforms) filter as action, but FUF does not. Not all terms and not all actions are supported on FUFs. So you have to see what filter type and what platform it is, in order to such a specific action.
> 
> What speaks against making jump and/or call actions a feature?

jump is not supported on all platforms and all types of filters.
> 
>>> - In the example in section 4.3, does the CLI shown really help much?
>>> The syntax is pretty system specific.
>> 
>> OTH, it is widely understood and self explanatory.
> 
> The question was whether it is needed to show system specific CLI.
> BTW, I note that the textual description says "deny ... from
> _leaving_".  How is the 'from leaving' translated into the XML? Is
> there any distinction between input and output filters (or forwarding
> filters or whatever your engine supports)?

We can improve the text description. Why not show system specific CLI? It is something widely understood and it is an example. 

This is what is being translated into XML
               access-list ip sample-ip-acl
               deny tcp host 10.10.10.1 host 10.10.10.255

And usually people understand real example better, then just text description.

> 
>>> In the XML shown, can you not
>>> leave out all the fields that are not set? This would remove a lot
>>> of noise. I do not understand what having both actions deny and
>>> permit at the same time means. Did you validate the example against
>>> the data model? (I also find the keys at the end somewhat strange
>>> and not that NETCONF XML serialization actually requires the keys to
>>> be sent first.)
> 
>> We used pyang sample xml skeleton to create the xml example.
> 
> Whatever, the noise does not really help and the example might even
> mislead people to believe they have to write down all unused leafs.

We could edit the empty fields out, but from personal experience working with customers, I was getting questions that the compiler output and the examples are not matching (it was vendor data modeling language).
> 
>> Leaving both actions in the document is my fault. In the model, action is a choice, and it was a bad copy paste job. Didn’t choose :)
>>> 
>>> - The clarification whether the boundary port numbers are included in
>>> a port range should be in the YANG model. The YANG model should also
>>> say what it means if one of the ranges is not present. We should not
>>> define the semantics by examples.
>> I’m loosing you here. We are stating in the model if the boundary port numbers are included in a port rang.
> 
> Ack, I found it in the description of container source-port-range (and
> previously I looked at lower-port and upper-port).
> 
>>> 
>>> - I do not understand section 5. It shows some nftables syntax but
>>> does not really shed a light on what the example shown does or how
>>> that maps to the YANG data model. So I am left somewhat clueless.
>> 
>> Just wanted to point out that the basic structure of iptables is similar to ACL yang model, so a translation from one to the other should be a  simple process. If someone wants to make it compliant.
> 
> It escapes me how the iptables fragment shown in page 18 maps to the
> YANG model. What is the substance behind the statement "It should be
> fairly easy to do translation between ACL YANG model described in this
> draft and Linux nftables."? Has someone done a mapping? It is not
> obvious to me how this works.

No, the mapping between nftables and ACL YANG model  has not been finished. 
> 
>>> - Can I trigger multiple actions from an ace? Or do I have to
>>> replicate the ace to do that? In general, there is extension of
>>> a choice (means one of several) and there are extension of a
>>> choice already present.
>> Again, this is very platform dependent, so didn’t want to include it in the base model.
>> 
> 
> So what would I do if I want to 'log' and 'deny'? Even if the base
> model does not do that, how can I augment this in? The base model must
> provide the necessary extensibility hooks.

Logging/counting and another action (permit/deny) is possible with most vendors, but other multiple actions are not by most vendors, example to jump to another ACE or ACL. You have to replicate the ACE to do that. So to make it simple, this was the choice we made.
> 
>>> - Empty description statements or descriptions statements "(null)"
>>> need to be fixed.
>> 
>> There are no empty descriptions. You are probably referring to ietf-packet-fields.yang model. There is a bug in pyang which was reported to Martin and fixed since.
> 
> I am talking about this (page 25):
> 
>      description "(null)”;

OK, got it. 
> 
>>> - I am a bit surprised that we do not define how to attach an ACL to
>>> an interfaces or a set of interfaces given that we do have an
>>> interfaces YANG data model. The example given in A.3 makes me wonder
>>> why there should be a counter in the interfaces config tree. The
>>> targets/interface-name back-reference seems to indicate that I can
>>> attach an ACL only to a single interface.
>> 
>> I wasn’t the author of that section
> 
> This is a WG document so this needs to be resolved.

You are right. 
> 
>>> - I do not understand A.4 at all. Defining an identity does not make
>>> the choice work differently.
>>> 
>>> - Has someone tried to implement this?
>> 
>> Was working on implementation while at my previous employer, but am not aware of any other implementation.
> 
> I believe it will help a lot to have prototype implementations of this
> data model in order to make sure the model does actually work and
> provides the extensibility hooks that are necessary. In particular, I
> would feel much more convinced if it would be clear (as a proof of
> concept) how the model maps to say Linux packet filters. I would
> actually not mind if mapping examples from the data model to various
> filtering engines would be in the appendix. This would give evidence
> that people have actually worked through a couple of concrete
> examples.

In this case, I can’t help at the moment, as have left the previous company where I was working on an implementation.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Jan 2016 19:30:53 +0100

> Authors are Cisco/Juniper people, so were using that terminology and I believe that CSCO and JNPR are more used in networking then Linux :)

If I were to have the time, I would even challenge you on
that. Clearly, when you consider # of devices connected to the
Internet, I am sure CISCO and JNPR will loose. But even in enterprise
networks, there are tons of Linux and BSD firewalls. Consider all the
home routers running openWRT and packet filters. So yes, if I would
have time, I would challenge you on that argument.

In some Junos documentation (Junos 14.2), I have seen the terms
'filter' and 'term'. But I might be proven wrong...

> Model was changed for IETF 94 and at the WG meeting nobody raised the issue.

I am talking about the modularity of the base model, I do not see how
the cited thread relates to this.

> We are early in the modeling and people were asking to remove time range from the base model and create separate draft, as many other features are using time-range.

I agree that the decision is kind of tough to make. One option is to
make the base model pretty much content free and to add pretty much
everything in a modular way via extensions of the base model.

> > - If not, what is the extensibility model here?

Question remains open.

> There is discussion in separate thread on this. And it seems we are in agreement to move this model to YANG 1.1 and use Martin B proposed solution.

OK

> >> Yes among vendors, but it can be very specific. Example, in Juniper implementation there are two types of filters, classical and Fast Update Filters (FUF). Classic filters support (on specific H…

This is why getting the modularity right is very important here.

> jump is not supported on all platforms and all types of filters.

A feature does not have to be supported by everyone.

> And usually people understand real example better, then just text description.

May please CISCO people, others likely less. But so be it.
 
> We could edit the empty fields out, but from personal experience working with customers, I was getting questions that the compiler output and the examples are not matching (it was vendor data model…

Which compiler's output? I find it very distracting to list unused
leafs. I assume most NETCONF implementations suppress unused leafs as
well. (I might be proven wrong but I would have a preference to not
use one that sends me tons of useless empty leafs.)

> No, the mapping between nftables and ACL YANG model  has not been finished. 

OK

> Logging/counting and another action (permit/deny) is possible with most vendors, but other multiple actions are not by most vendors, example to jump to another ACE or ACL. You have to replicate the…

So what about counting logging? Can we make the base simple yet
powerful enough via features to match what common open source software
implementations can do?

> In this case, I can’t help at the moment, as have left the previous company where I was working on an implementation.

Perhaps there are others here with sufficient interested to work out
(at least) how the model maps back and forth to the implementation(s)
they are familiar with?

/js

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 19 Jan 2016 07:11:52 -0800

> On Jan 11, 2016, at 7:30 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

I would definitely take you on this one. As OpenWRT is domain of hobbyist. If I may ask you, what device your ISP is sending you as access point? :)

> 'filter' and 'term'. But I might be proven wrong…

Juniper is using filter and term, that is correct, from day one. OTH, Cisco is using Access Control List (ACL) and ACL Entries (ACE) and several other vendors (Brocade, Huawei, ALu, Ericsson Redback) are using those terms too. ACL is well established in the industry. 
> the cited thread relates to this.

Among the vendors, ace-eth, ace-ipv4 and ace-ipv6 are always supported. I appreciate your input, but we did this design choice as design team and went forward with it. Also, the YANG models are not set in stone. I definitely see models evolving.

> use one that sends me tons of useless empty leafs.) 

There is a vendor that had data modeling language and compiler shipping in their SDK. It is private DM language and it is not used outside of that vendor and customers.
> powerful enough via features to match what common open source software

We made a different design choice. 
> (at least) how the model maps back and forth to the implementation(s)

I did it for Juniper and it is working well for Junos, but didn’t finish it. I can’t speak for Cisco people, but they are co-authors on the draft and were fine with the model.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 Jan 2016 17:48:30 +0100

On Tue, Jan 19, 2016 at 07:11:52AM -0800, Dean Bogdanovic wrote:
> I would definitely take you on this one. As OpenWRT is domain of
> hobbyist. If I may ask you, what device your ISP is sending you as
> access point? :)

Which ISP is sending their customers a Cisco or Juniper device? The
big players in the German market all sell something that is based that
the very end on Linux or BSD. Isn't FritzBox for example Linux based?
Are the cheap Asian home routers not all at the end Linux based? I
guess this debate does not really belong here and we should take is
elsewhere (but I am sure I will win this easily).

> Juniper is using filter and term, that is correct, from day
> one. OTH, Cisco is using Access Control List (ACL) and ACL Entries
> (ACE) and several other vendors (Brocade, Huawei, ALu, Ericsson
> Redback) are using those terms too. ACL is well established in the
> industry.

While we can have a lengthy debate about terminology, I think more
important is to get functionality right.

> Among the vendors, ace-eth, ace-ipv4 and ace-ipv6 are always supported. I appreciate your input, but we did this design choice as design team and went forward with it. Also, the YANG models are not…

My main concern is that we need to get the extensibility of the model
right. One way to make sure we achieved this goal is to actually treat
everything as an extension of the core model (this forces us to get
the extensibility right). This is essentially what we did with the
routing data model and the interfaces data model.

/js

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Jan 2016 18:16:47 +0100

Hi Juergen,

Skipping down...

> important is to get functionality right. 

Agree.  We are arguing over labels that aren't generally meant for
humans ANYWAY.

> routing data model and the interfaces data model.
While I agree I am also becoming concerned that we may be going down a
rat hole from which we may not return.  The above thread snippets have
lost so much context that one cannot divine what it is we are arguing
over.  While a design team certainly does not represent consensus, can
we please at least argue over what it is we are supposed to be arguing
over?  With regard to this model, I could imagine innumerable ways to
represent an access list.  The deference due the people who wrote this
stuff out is at least to recognize that.  If you are going to propose an
alternative at this point, please do it the old fashion way: send text.

Eliot

---

From: "Lisa (Yi) Huang" <[email-masked]>
Date: Tue, 19 Jan 2016 18:18:24 +0000

In current devices, access lists could be configured before interface
available as part of provisioning configuration. Using interface-ref would
loose this flexibility. Also, in the 1st draft of ³Yang Data Model for
Stateless Packet Filter Configuration², the community doesn¹t like
interface-ref because of lacking of flexibility. In YANG 1.1, the new
require-instance statement might help this situation. We would discuss it
in authors to figure out whether to adapt YANG 1.1 in this I-D or not.

Thanks,
Lisa

---

From: "Kiran Koushik Agrahara Sreenivasa (kkoushik)" <[email-masked]>
Date: Tue, 19 Jan 2016 18:53:33 +0000

Hi Juergen,

>> Among the vendors, ace-eth, ace-ipv4 and ace-ipv6 are always supported.
>>I appreciate your input, but we did this design choice as design team
>>and went forward with it. Also, the YANG models are not set in stone. I
>>definitely see models evolving.
>

While I agree that your approach worked with the routing and interfaces
data models, we as a design team decided to include what we thought was
core functionality and then also allow extensibility on top of it. At
least folks in Cisco and Brocade liked this approach better.

Thanks
Kiran

---

From: Ebben Aries <[email-masked]>
Date: Thu, 21 Jan 2016 22:37:11 -0700

> I would definitely take you on this one. As OpenWRT is domain of hobbyist. If I may ask you, what device your ISP is sending you as access point? :)

Consider all of the massive content/DC server farms which may run on
every host.  Between this, home routers and other Linux/BSD based
network connected devices, I'd say nftables, iptables, pf, etc.. are
nothing to discount here as 1st class citizens

/ebben

---

From: Eliot Lear <[email-masked]>
Date: Fri, 22 Jan 2016 06:52:04 +0100

Hi,

> nothing to discount here as 1st class citizens

We are talking about labels and not the concept, where there the
conceptual approach doesn't vary that much.  Pick SnaggableFarb and
let's move on, please?

Eliot

---

From: Ebben Aries <[email-masked]>
Date: Thu, 21 Jan 2016 23:14:50 -0700

> use one that sends me tons of useless empty leafs.)

I agree, the goal of this XML example is to match an RPC with the CLI
example above it.  No reason to include all possible leafs.

Another state of confusion is an acl-type of 'ipv4-acl' with references
to both ace-ipv6 and ace-ipv6 leafs

---

From: Eliot Lear <[email-masked]>
Date: Fri, 22 Jan 2016 08:07:07 +0100

> example above it.  No reason to include all possible leafs.

+1.

> to both ace-ipv6 and ace-ipv6 leafs

Yes, not to mention both <permit /> and <deny /> in the same ACE.

Eliot

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jan 2016 15:45:32 +0100

Eliot,

I posted a technical review of the ACL draft on December 11th to the
list since the document was send to WG last call. I believe the I-D
has technical issues that need to be resolved. I am not going to
repeat my technical comments.

Note I have been one of the _few_ who actually read the I-D when it
was sent to WG last call. And yes, I believe a standard in this area
needs to be highly extensible (so we better get this right) and I
believe it needs to be resonably match widely deployed open source
packet filters and not just Juniper and Cisco gear.

/js

PS: I reduced the CC: list to the NETMOD WG since this is where the
    work is supposed to take place.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 27 Jan 2016 15:48:27 +0000

All,

On 1/27/16, 9:45 AM, "netmod on behalf of Juergen Schoenwaelder"
<[email-masked] on behalf of
[email-masked]> wrote:

>was sent to WG last call.

FWIW, I also read the document both after it was accepted as a WG document
and during WG last call. There have been some points of discussion during
the document’s life that were discussed on the NETMOD list or during
NETMOD open meetings. There are some YANG nodes that I probably would have
named differently as well. However, I believe WG last call is a bit late
and would not let my personal biases delay document publication.

Thanks,
Acee 

> And yes, I believe a standard in this area
>> >> Among the vendors, ace-eth, ace-ipv4 and ace-ipv6 are always
>>supported. I appreciate your input, but we did this design choice as
>>design team and went forward with it. Also, the YANG models are not set
>>in stone. I definitely see models evolving.