Subject: Re: [netmod] YANG module for ACL configuration

From: Jonathan Hansford <[email-masked]>
Date: Mon, 03 Sep 2012 11:04:50 +0100

Having just extracted the YANG modules from the document (i.e. not
having reviewed the document yet), here are a couple of issues: 

 	*
RFC6087 states "Each YANG module or submodule contained within an
Internet-Draft or RFC is considered to be a code component. The strings
'<CODE BEGINS>' and '<CODE ENDS>' MUST be used to identify each code
component." acl.yang is the only code component that is identified with
<CODE BEGINS> and none or the code components are identified with <CODE
ENDS>
 	* module acl

 	* <CODE BEGINS> statement identifies the
revision as 2012-08-30 whereas the revision statement identifies it as
2012-08-31

 	* module acl-ip

 	* The typedef for Comparator is in
module acl and should therefore have the appropriate prefix, viz
acl:Comparator

Jonathan 

On 01.09.2012 00:03, Alexander Clemm (alex)
wrote: 

> Dear All, 
> 
> we have just posted an Internet Draft of a
YANG model for ACL configuration: 
http://www.ietf.org/internet-drafts/draft-huang-netmod-acl-00.txt [1] 

> This document defines a YANG data model for Access Control Lists
(ACLs) on a device. An ACL is an ordered set of rules that is used to
filter traffic on a networking device. In the draft you will find
details of how the model is designed and the corresponding YANG modules.

> 
> We are hoping that this model is of interest to this group. Please
take a look and let us know your thoughts and comments. 
> Thanks, 

> Alex & Lisa

Links:
------
[1]
http://www.ietf.org/internet-drafts/draft-huang-netmod-acl-00.txt

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 4 Sep 2012 04:21:02 +0000

Hello Jonathan,

thank you.  These are good catches.  We will correct this in the next revision (once we have received a little more feedback).

Regards
--- Alex

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jonathan Hansford
Sent: Monday, September 03, 2012 3:05 AM
To: [email-masked]
Subject: Re: [netmod] YANG module for ACL configuration

Having just extracted the YANG modules from the document (i.e. not having reviewed the document yet), here are a couple of issues:

  *   RFC6087 states "Each YANG module or submodule contained within an Internet-Draft or RFC is considered to be a code component. The strings '<CODE BEGINS>' and '<CODE ENDS>' MUST be used to identify each code component." acl.yang is the only code component that is identified with <CODE BEGINS> and none or the code components are identified with <CODE ENDS>
  *   module acl
     *   <CODE BEGINS> statement identifies the revision as 2012-08-30 whereas the revision statement identifies it as 2012-08-31
  *   module acl-ip
     *   The typedef for Comparator is in module acl and should therefore have the appropriate prefix, viz acl:Comparator

Jonathan

On 01.09.2012 00:03, Alexander Clemm (alex) wrote:

Dear All,

we have just posted an Internet Draft of a YANG model for ACL configuration:

This document defines a YANG data model for Access Control Lists (ACLs) on a device. An ACL is an ordered set of rules that is used to filter traffic on a networking device. In the draft you will find details of how the model is designed and the corresponding YANG modules.

We are hoping that this model is of interest to this group.  Please take a look and let us know your thoughts and comments.

Thanks,

Alex & Lisa

---

From: Andy Bierman <[email-masked]>
Date: Tue, 4 Sep 2012 08:11:44 -0700

On Mon, Sep 3, 2012 at 9:21 PM, Alexander Clemm (alex) <[email-masked]> wrote:
> Hello Jonathan,
>
>
>
> thank you.  These are good catches.  We will correct this in the next
> revision (once we have received a little more feedback).
>

This is a very substantial YANG module.
It would be nice to have some example configs and use-cases
to demonstrate the YANG module in use.  An endless list of
groupings makes it hard for readers to visualize instance documents.

I don't see how the ACLs hook into the interfaces table.
Is is purely by IP address and not interface?

I noticed a top-level augment-stmt in the same document as the
object being augmented.  What is the point of this structure?

I noticed a <reset-match-counter> RPC operation.
I thought we settled this issue in SNMP in the early 90s.
Counters are shared.  If 1 client resets them, all the other
clients reading them are impacted.

Not sure what WG this belongs in, but not NETMOD.
Seems like a group of experts will need to go over this
rather implementation-specific data model and generalize
it for standards use.

> --- Alex

Andy

> Having just extracted the YANG modules from the document (i.e. not having
> reviewed the document yet), here are a couple of issues:
>
> module acl
> <CODE BEGINS> statement identifies the revision as 2012-08-30 whereas the
> revision statement identifies it as 2012-08-31
>
> module acl-ip
>
> The typedef for Comparator is in module acl and should therefore have the
> appropriate prefix, viz acl:Comparator
>
> Jonathan
>
> This document defines a YANG data model for Access Control Lists (ACLs) on a
> device. An ACL is an ordered set of rules that is used to filter traffic on
> a networking device. In the draft you will find details of how the model is
> designed and the corresponding YANG modules.
>
>
>
> We are hoping that this model is of interest to this group.  Please take a
> look and let us know your thoughts and comments.
>
>
>
> Thanks,
>
>
>
> Alex & Lisa
>
>
>
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Tue, 4 Sep 2012 18:40:15 +0000

Thanks, Andy. I marked my response as <Lisa/> in line below.

On 9/4/12 8:11 AM, "Andy Bierman" <[email-masked]> wrote:

>to demonstrate the YANG module in use.
<Lisa> Here is an example of ip-acl to demonstrate how to use the Yang
module. I can add it to next draft.

ACL Example:

Denies TELNET traffic from 14.3.6.234 bound for host 6.5.4.1 from leaving.
Denies all TFTP traffic bound for TFTP servers. Permits all other IP
traffic.

ACL CLI:

access-list ip iacl

  10 deny tcp 14.3.6.234 0.0.0.0 host 6.5.4.1 eq 23
  20 deny udp any any eq tftp
  30 permit ip any any

The edit-config data part is the following:

<acls>
  <acl >
    <name>iacl</name>
    <acl-type>ip-acl</acl-type>
    <enable-match-counter>false</enable-match-counter>
    <acl-ip:afi>ipv4</acl-ip:afi>
    <acl-ip:ipv4-aces>
    
      <acl-ip:ipv4-ace>
        <acl-ip:sequence-num>10</acl-ip:sequence-num>
        <acl-ip:filters>
          <acl-ip:protocol>6</acl-ip:protocol>
          <acl-ip:ip-source-kind>ip</acl-ip:ip-source-kind>
          <acl-ip:ip-source-address> 14.3.6.234 </acl-ip:ip-source-address>
          <acl-ip:ip-source-mask>0.0.0.0</acl-ip:ip-source-mask>
          <acl-ip:ip-dest-kind>host</acl-ip:ip-source-kind>
          <acl-ip:ip-dest-host-address> 6.5.4.1
</acl-ip:ip-dest-host-address>
          <acl-ip:des-comparator>eq</acl-ip:des-comparator>
          <acl-ip:des-port>23</acl-ip:des-port>
        </acl-ip:filters>
        <acl-ip:actions>
          <acl-ip:action>deny</acl-ip:action>
        </acl-ip:actions>
      </acl-ip:ipv4-ace>

      <acl-ip:ipv4-ace>
        <acl-ip:sequence-num>20</acl-ip:sequence-num>
        <acl-ip:filters>
          <acl-ip:protocol>17</acl-ip:protocol>
          <acl-ip:ip-source-kind>any</acl-ip:ip-source-kind>
          <acl-ip:ip-dest-kind>any</acl-ip:ip-source-kind>
          <acl-ip:des-comparator>eq</acl-ip:des-comparator>
          <acl-ip:des-port>69</acl-ip:des-port>
        </acl-ip:filters>
        <acl-ip:actions>
          <acl-ip:action>deny</acl-ip:action>
        </acl-ip:actions>
      </acl-ip:ipv4-ace>

      <acl-ip:ipv4-ace>
        <acl-ip:sequence-num>30</acl-ip:sequence-num>
        <acl-ip:filters>
          <acl-ip:ip-source-kind>any</acl-ip:ip-source-kind>
          <acl-ip:ip-dest-kind>any</acl-ip:ip-source-kind>
        </acl-ip:filters>
        <acl-ip:actions>
          <acl-ip:action>permit</acl-ip:action>
        </acl-ip:actions>
      </acl-ip:ipv4-ace>
    </acl-ip:ipv4-aces>
      
  </acl>
</acls>

</Lisa>

>An endless list of

<Lisa>Indeed there are a lot of groupings in the model simply because ACL
is large and have a lot of reused part among different types of acl. To
make the draft more readable, I have added the design of model section and
a full expanded tree to help to get an overview picture of the model.

</Lisa>

>Is is purely by IP address and not interface?

<Lisa>This draft did not target to address how the ACL apply to the
interfaces as mentioned in the draft. One potential way is through the
Acl-Ref typedef. Here is a sample usage:

import acl {
  prefix acl;
}

list myInteface {
  ...
  leaf access-group {
    type acl:Acl-Ref;

  }
  ...
}

I did not add this to the draft since there is no limitation how to use it.

</Lisa>

>object being augmented.  What is the point of this structure?

<Lisa>They are not in the same document. Top level container and acl list
are in acl.yang whereas the augment-stmt are in acl-ip.yang, acl-arp.yang,
acl-mac.yang.  </lisa>

>> From: [email-masked] [mailto:[email-masked]] On
>>Behalf Of
>> Jonathan Hansford
>>having
>>take a

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 4 Sep 2012 20:08:25 +0000

Hi Andy,

Lisa already responded to most of the items you raised.

Regarding the resetting of counters:  This actually touches on two issues.  The first issue concerns whether to include support for counters and basic statistics at all, or just focus on configuration.  We were debating with ourselves, but in the end felt that basic statistics are generally just part of ACL management and while they could be broken out, to just include them. If the sentiment is that they should be removed, we can certainly do so.  

The second issue concerns the reset issue per se.  I am certainly aware of the corresponding discussion in conjunction with SNMP.  Again, the question is whether to offer such a facility at all.  Certainly, the argument of wanting to avoid clients needing to be aware of resets is valid as well.  At the same time, the context of Netconf makes some things arguably a little different.  For one, we have the ability to invoke a separate reset "action", which resets the value as a "side effect" as opposed to setting it directly.  This action can certainly have other "side effects", such as recording the time the last reset occurred and a "counter reset" notification.  (Arguably, those need to be introduced, but good to have a discussion on this up front).  Also, SNMP was connectionless, unreliable etc, unlike Netconf, so there is less of an issue of clients missing notifications.  Anyway, it may be good to have an clear policy here - is it the expectation that the SNMP policy is still in effect, or should it be adjusted?    

Regarding the working group, which other working group would it fit in?  To us, Netmod appeared a logical candidate, as it is clearly involved in "contents libraries".  Clearly, the intent is for this is to be generalized for standards-use.  

Thanks
--- Alex

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Tuesday, September 04, 2012 8:12 AM
To: Alexander Clemm (alex)
Cc: Jonathan Hansford; [email-masked]
Subject: Re: [netmod] YANG module for ACL configuration

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Sep 2012 00:36:51 +0200

>  ill in effect, or should it be adjusted?    

Counters have discontinuities. This is true even in SNMP land and
hence we have so called discontinuity indicators in various MIB
modules, sysUpTime being the default. That said, in SNMP land we tried
to minimize discontinuities since, as Andy said, counters are often
read by multiple applications and every discontinuities bites other
applications a bit. In SNMP land, the following principles were
applied:

a) A single counter reading has no meaning. You need to read a counter
   twice and calculate the rate of change.

b) While reading counters to calculate the rate of change, you have to
   check any discontinuity objects in order to throw away readings in
   case a discontinuity occured.

It is because of b) that you want to minimize discontinuities. [I know
that we have zero-based counters where a single reading may be
meaningful but that is not the point here.]

The question which transport a network management protocol uses has
nothing to do with this. A proper SNMP implementation (and not all
programs get a) and b) done correctly) will deal with discontinuities
by (at the end) discarding values. I believe these basic principles
really did not change since the late 80s. If you share counters,
minimize any discontinuities.

[Even if you do down the path of inventing a notification and you
mandate that notification support is in every application reading
counters and the notification records the counter value before the
reset, the value after the reset, and the timestamp, you still have a
problem because the timestamp recorded at the server is only up to a
certain precision synchronized with the timestamps maintained by the
client.]

/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: "Alexander Clemm (alex)" <[email-masked]>
Date: Tue, 4 Sep 2012 22:59:06 +0000

Thank your for the response.  
So, in summary, no reset capability for counters, regardless of protocol, mechanism through which reset occurs, and auxiliary mechanisms to deal with discontinuities.  
I do agree with the argument and we've taken a note to take it out in the next revision.  
While on that topic, what is the sentiment on having counters/statistics at all?  One "best practice" could presumably be to restrict modules used for configuration to configuration, leaving statistics as a completely separate topic.  
--- Alex

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, September 04, 2012 3:37 PM
To: Alexander Clemm (alex)
Cc: Andy Bierman; [email-masked]
Subject: Re: [netmod] YANG module for ACL configuration

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Sep 2012 06:46:55 +0200

On Tue, Sep 04, 2012 at 10:59:06PM +0000, Alexander Clemm (alex) wrote:

> While on that topic, what is the sentiment on having
> counters/statistics at all?  One "best practice" could presumably be
> to restrict modules used for configuration to configuration, leaving
> statistics as a completely separate topic.

I think there is no clear "best practice". I assume once we have a
solution how to deal with operational state, this will find an answer
as well.

/js

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 5 Sep 2012 11:57:34 +0200

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Alexander Clemm (alex)
> Sent: Wednesday, September 05, 2012 1:59 AM
> To: Juergen Schoenwaelder
> Cc: [email-masked]
> So, in summary, no reset capability for counters, regardless of
> protocol, mechanism through which reset occurs, and auxiliary
mechanisms
> to deal with discontinuities.
[[DR]] This is much better, for all the good reasons already mentioned
in the discussion. 

> While on that topic, what is the sentiment on having
counters/statistics
> at all?  One "best practice" could presumably be to restrict modules
> used for configuration to configuration, leaving statistics as a
> completely separate topic.
[[DR]] We do not have yet enough practice, so we cannot assess what is
the best. But this asks the question - what you exactly mean by 'leaving
statistics as a completely separate topic'? Not using NETCONF at all for
statistics, or defining as separate YANG modules. 

Regards,

Dan

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 18 Sep 2012 15:08:47 +0200 (CEST)

Hi,

> take a look and let us know your thoughts and comments.

I have done a high-level review of this draft.  My comments focus on
higher-level issues, rather than details.  

o  Maybe OPSAWG is the right place to do this work?   Andy suggested
   that NETMOD could help other WGs with theier YANG models.  I think
   that would be a good idea for this data model.

o  Is the Intended Status really Informational?

o  All your YANG models should have the <CODE BEGINS> <CODE ENDS>
   markers.    Note that the acl model has </CODE> instead of the
   proper <CODE ENDS>.  Proper markers help tools extract the data
   models.

o  Running pyang on your data models gives two errors that are easy to
   fix:

   [email-masked]:1: warning: unexpected latest revision "2012-08-31" in [email-masked], should be 2012-08-30

   acl-ip.yang:389: error: type "Comparator" not found in module acl-ip

o  I suggest you try to be consistent in the format of the
   YANG models (indentation, placement of statements etc.)  'pyang' can
   help with this - run:

      pyang -f yang --yang-canonical <filename>

   to get started.  This would make the models easier to follow.

o  I did not understand why some ip-related definitions are in
   acl-ip.yang, and some in acl.yang (and same for mac etc).

o  A common pattern in your model is this:

        leaf ip-source-kind {
            type IP-Network-Kind ;
        }
        choice source-address-host-group {
            when "ip-source-kind != 'any'";
            case mask {
                when "ip-source-kind = 'ip'" ;
                leaf ip-source-address { ... }
                leaf ip-source-mask { ... }
            }
            case host {
                when "ip-source-kind = 'host'";
                leaf ip-source-host-address { ... }
            }
            case group {
                when "ip-source-kind = 'group'";
                leaf ip-source-group  {  ... }
            }
        }

  An alternative design which might simplify the model could be to get
  rid of the discriminator:

        choice source-address-host-group {
            case mask { // implies 'ip' kind
                leaf ip-source-address { ... }
                leaf ip-source-mask { ... }
            }
            case host { // implies 'host' kind
                leaf ip-source-host-address { ... }
            }
            case group {  // implies 'group' kind
                leaf ip-source-group  {  ... }
            }
            case any {  // implies 'any' kind
                leaf ip-any { type empty; }
            }
        }
  
   In this particular case, maybe it makes sense to add a form with a
   prefix instead of a mask:

            case prefix {
              leaf ip-source-subnet {
                type inet:ip-prefix;
              }
            }

       <ip-source-subnet>10.0.0.1/24</ip-source-subnet>

 o  If seems a bit odd that there's a choice between a remark and
    filters; this means that you cannot put a comment on an ace that
    has filters.  The model would be simpler if you did:

    OLD:

                choice remark-or-filter {
                    case remark {
                        leaf remark { ... }
                    }
                    case filter {
                        container filters { uses ... }
                }

    NEW:

         leaf remark { ... }
         container filters { uses ... }

    Or maybe also get rid of the 'filters' container:

         leaf remark { ... }
         uses ...

/martin

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Sat, 22 Sep 2012 01:06:25 +0000

Hi Martin,

Thank you for your review!  Quick responses inline.

--- Alex

[...]

<AC> Of course, this is ultimately for the working group to decide.  In our viewpoint, one thing that is still needed from standardization perspective to make YANG truly successful is the development of more "content".  To make YANG truly "stick" in the industry, more YANG modules are needed and the ones that exist must be easy to find.  This IMHO makes it preferrable to concentrate/consolidate them in one place rather than scatter them around - specifically if they concern general-purpose as opposed to very technology/feature-specific modules.  If consolidated in one place, the obvious place that comes to my mind is this working group.  
</AC>

<AC> Actually it would be good to have this standards track.
</AC>

<AC> Agree, we need to fix it.
</AC>

<AC> Agree, we need to fix it.
</AC>

<AC> Agree, we need to fix it.
</AC>

<AC> no comment at this point from our side, we will revisit in our next pass and make sure that design decisions are documented properly
</AC> 

        leaf ip-source-kind {
            type IP-Network-Kind ;
        }

  
<AC>
We were actually considering the alternative design but, at least in the first pass, decided against it.  Your proposed alternative is from a modeling perspective certainly elegant.  However, it introduces certain "context dependencies" - powerful but also a bit more complex because if you want to simply know what type of ip-source-kind you have, you cannot simply find out, but need to know how it is defined (to conclude which type it is).  The current design is more "context independent" - a bit cruder but also simpler in a way, although of course it necessitates a when statement.  

This might be a case where a "best practice" for authors might be useful, actually, as these are clearly design alternatives to accomplish the same thing in different ways.  
</AC>

            case prefix {
              leaf ip-source-subnet {
                type inet:ip-prefix;
              }
            }

<AC> Agree, this makes sense.  We will add it.
</AC>

    OLD:

    NEW:

         leaf remark { ... }

         leaf remark { ... }
         uses ...

<AC>
The two are not the same.  Admittedly, we let the semantics of Cisco CLI design guide us here, in which remarks are truly independent items in an ACL not tied to a particular ACE; they do not share a sequence number with an ACE.  Clearly a design choice, but one that will make the implementation of the YANG module (at least in our case) easier.  
</AC>

---

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Sat, 22 Sep 2012 01:40:50 +0000

Martin,

Thanks for your review. Alex has addressed most of your comments. For this
comment:

>I did not understand why some ip-related definitions are in

Point taken. I do see identity ip-acl, arp-acl, mac-acl should move to
corresponding acl. I will fix it in next revision.

However, some ip-related defition, such as grouping IP-ADDRESS-AND-MASK,
needs to stay in acl.yang. This grouping is used by both acl-ip and
acl-arp. Acl.yang is the best place I can think of without introduce
another yang file. If grouping IP-ADDRESS-AND-MASK stays in acl.yang, the
typedef that used by the grouping need to stay as well. Same to grouping
MAC-ADDRESS-AND-MASK

Thanks,

Lisa

On 9/21/12 6:06 PM, "Alexander Clemm (alex)" <[email-masked]> wrote:

><AC> Of course, this is ultimately for the working group to decide.  In
>our viewpoint, one thing that is still needed from standardization
>perspective to make YANG truly successful is the development of more
>"content".  To make YANG truly "stick" in the industry, more YANG modules
>are needed and the ones that exist must be easy to find.  This IMHO makes
>it preferrable to concentrate/consolidate them in one place rather than
>scatter them around - specifically if they concern general-purpose as
>opposed to very technology/feature-specific modules.  If consolidated in
>one place, the obvious place that comes to my mind is this working group.
> 
></AC>
>
>   [email-masked]:1: warning: unexpected latest revision
>"2012-08-31" in [email-masked], should be 2012-08-30
>
><AC> no comment at this point from our side, we will revisit in our next
>pass and make sure that design decisions are documented properly
></AC> 
>
>We were actually considering the alternative design but, at least in the
>first pass, decided against it.  Your proposed alternative is from a
>modeling perspective certainly elegant.  However, it introduces certain
>"context dependencies" - powerful but also a bit more complex because if
>you want to simply know what type of ip-source-kind you have, you cannot
>simply find out, but need to know how it is defined (to conclude which
>type it is).  The current design is more "context independent" - a bit
>cruder but also simpler in a way, although of course it necessitates a
>when statement.  
>
>This might be a case where a "best practice" for authors might be useful,
>actually, as these are clearly design alternatives to accomplish the same
>thing in different ways.
></AC>
>
>
>The two are not the same.  Admittedly, we let the semantics of Cisco CLI
>design guide us here, in which remarks are truly independent items in an
>ACL not tied to a particular ACE; they do not share a sequence number
>with an ACE.  Clearly a design choice, but one that will make the
>implementation of the YANG module (at least in our case) easier.
></AC>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Sat, 22 Sep 2012 10:29:11 -0700

.....
>                 leaf ip-any { type empty; }

I have a 3rd alternative, which IMO uses the correct YANG
to capture the intent -- since the client provides ip-source-kind
it knows which case to provide as well.

         leaf ip-source-kind {
              type IP-Network-Kind ;
          }
          choice source-address-host-group {
             case mask {
                  must "ip-source-kind = 'ip'" ;
                  leaf ip-source-address { ... }
                  leaf ip-source-mask { ... }
             }
             case host {
                  must "ip-source-kind = 'host'";
                  leaf ip-source-host-address { ... }
              }
              case group {
                   must "ip-source-kind = 'group'";
                   leaf ip-source-group  {  ... }
              }
          }

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 23 Sep 2012 22:00:52 +0200 (CEST)

Hi,

"Lisa Huang (yihuan)" <[email-masked]> wrote:
> acl-arp.

It could be moved to acl-ip.yang, and then acl-arp would import
acl-ip (and similar for MAC-ADDRESS-AND-MASK).

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 23 Sep 2012 22:04:24 +0200 (CEST)

> it knows which case to provide as well.

I don't understand the reasoning.  It seems you are saying that there
are situations in which the client does not provide the data and it
thus doesn't know which case to provide?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 23 Sep 2012 22:18:37 +0200 (CEST)

"Alexander Clemm (alex)" <[email-masked]> wrote:
> We were actually considering the alternative design but, at least in the first
> pass, decided against it.  Your proposed alternative is from a modeling
> perspective certainly elegant.  However, it introduces certain "context
> dependencies" - powerful but also a bit more complex because if you want to
> simply know what type of ip-source-kind you have, you cannot simply find out,
> but need to know how it is defined (to conclude which type it is).  The current
> design is more "context independent" - a bit cruder but also simpler in a way,
> although of course it necessitates a when statement.
> 
> actually, as these are clearly design alternatives to accomplish the same thing
> in different ways.
> </AC>

Here are three alternatives:

(A)

  leaf discriminator {
    type enumeration {
      enum e1 { ... }
      ...
      enum en { ... }
  }
  choice a {
    case c1 {
      when "discriminator = 'e1';
      // c1 data nodes
    }
    ...
    case cn {
      when "discriminator = 'en';
      // cn data nodes
    }
  }

(B)
  choice a {
    case c1 {
      // implies e1
      // c1 data nodes
    }
    ...
    case cn {
      // implies en
      // cn data nodes
    }
  }

(C)

  choice a {
    case c1 {
      container e1 {
        // c1 data nodes
      }
    }
    ...
    case cn {
      container e1 {
        // cn data nodes
      }
    }
  }

(an alternative to A is to use 'must' instead of 'when', as Andy
suggested.  but they both result in the same structure)

In your case I suggested pattern (B).  I think this pattern can be
useful if there are not too many nodes in each case.  In this case
there are one or two nodes, and they are always (?) mandatory, which
means that it is trivial to figure out which case is actually in use.

Pattern (C) is more explicit, but introduces another nesting level.

IMO, pattern (A) is the most complex, or less direct, since it
involves the additional discriminator node, and 'when' (or 'must')
statements.

I think CLIs often use a direct and simple model, so it can often be
useful to think about the data model design from a CLI perspective.
Which information is needed, and how is it given in the CLI?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 23 Sep 2012 13:26:46 -0700

> involves the additional discriminator node, and 'when' (or 'must')

It is useful to have the discriminator node so it can be used
in other unforeseen use-cases in when/must statements.

IMO, providing a case for the wrong discriminator should
be an error (must) not silently dropped nodes (when).

(B) -- no discriminator -- cannot be used to enforce
the correct case.  You can add text like "This object is
ignored unless foo = 3", but we have must/when for
a better solution than this one.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 23 Sep 2012 22:33:38 +0200 (CEST)

> be an error (must) not silently dropped nodes (when).

If the discriminator is set to 'e1' and the client provides nodes for
case 'c2', this is an error even for the 'when' case.

> a better solution than this one.

The point with (B) is that the discriminator is not needed.  If there
are just one or two nodes in each case, why bother with a
discriminator node, it just makes things more complex.

I absolutely agree that there are cases where a discriminator node is
useful, but I also believe that there are cases wher it is not needed
- otherwise we shouldn't have had choice the way it is in YANG today.

/martin

---

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Mon, 24 Sep 2012 04:57:50 +0000

Acl-ip and acl-arp has no other relationship except both could filter on
ip address. From this point of view, it does not quite make sense for
acl-arp to import acl-ip.

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 24 Sep 2012 20:21:58 +0200 (CEST)

Hi,

> acl-arp to import acl-ip.

I think you maybe read too much meaning into the "import" statement?
There does not have to be any relationship between a module and the
module it imports, more than there are some definitions in the
imported module that the importing module wants to reuse.

This said, I agree you don't want to introduce unnecessary
dependencies, but I don't think that's the case here.

/martin

---

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Tue, 25 Sep 2012 17:13:09 +0000

Got it. I will address it in next revision.

---

From: "Muthumayan Madhayyan (muthu)" <[email-masked]>
Date: Thu, 27 Sep 2012 05:34:11 +0000

One other useful RPC for this ACL module would be a mechanism to re-sequence ACE sequence numbers.

Something like:

     rpc resequence-acl {
         description "This RPC is to re-number sequence numbers of ACE entries

         in an ACL. The first ACE entry would use the 'start' number and subsequent

         ACE entries would be assigned increasing sequence numbers 'interval' apart. ";

         input {
             leaf acl-name {
                 type string;
                 mandatory true;
                 description "This name is the acl name.";
             }
             leaf start {
                 type Sequence-Number;
                 description
                     "Starting sequence-num for the first ACE in an ACL.";

             }

             leaf interval {

                 type uint32;
                 description
                     "Gap between sequence number assigned to consecutive ACE entries";

             }

} }

Thanks,

- muthu

From: "Alexander Clemm (alex)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, August 31, 2012 4:03 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [netmod] YANG module for ACL configuration

Dear All,

Thanks,

Alex & Lisa

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 27 Sep 2012 09:00:27 +0200 (CEST)

> re-sequence ACE sequence numbers.

This is the reason why YANG has ordered-by user lists.  With an
ordered-by user list you avoid the renumbering problem, and give the
user the ability to move entires without renaming/renumbering them.

Note that *if* such an RPC operation is introduced, it at least need
to take the configuration datastore as argument (candidate, running).

/martin

> To: "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Sep 2012 07:24:28 -0700

Hi,

I would be strongly opposed to replacement of the standard editing mechanisms
with data-model specific operations.  I do not see anything special about
the ACE lists such that 'ordered-by user' would not work.

Andy

On Wed, Sep 26, 2012 at 10:34 PM, Muthumayan Madhayyan (muthu)
<[email-masked]> wrote:
> From: "Alexander Clemm (alex)" <[email-masked]>
> To: "[email-masked]" <[email-masked]>

---

From: "Muthumayan Madhayyan (muthu)" <[email-masked]>
Date: Thu, 27 Sep 2012 17:58:14 +0000

>user the ability to move entires without renaming/renumbering them.

Sure.. That will work if the key for the ACE list is a string. In this
case, the key is an integer.
Lets say, an existing list has ACE entries with keys 1, 2, 3, 4 and 5.
Now, we want to add an entry between 3 and 4.
How can we use ordered-by-user in this situation ?

>to take the configuration datastore as argument (candidate, running).

Agree.
>>          ACE entries would be assigned increasing sequence numbers
>>'interval'
>>          apart. ";
>> 
>>          input {
>>              leaf acl-name {
>>                  type string;
>>                  mandatory true;
>>                      "Gap between sequence number assigned to
>>consecutive ACE
>>                      entries";
>> 
>>              }
>> 
>> } }
>> 
>> Thanks,
>> 
>> - muthu
>> 
>>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 27 Sep 2012 20:02:06 +0200 (CEST)

> How can we use ordered-by-user in this situation ?

Technically it works just fine.  The keys don't mean anything - the
order of an ordered-by user is the order the user defines.  But it
would be pretty confusing, so I agree that it is probably better to
use a name as key.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Sep 2012 11:21:48 -0700

> would be pretty confusing, so I agree that it is probably better to
Yes -- the key is just a unique identifier.  It should
not be an integer.

The YANG insert operation determines the creation order,
if it is not the default (last).

Andy

---

From: "Muthumayan Madhayyan (muthu)" <[email-masked]>
Date: Fri, 28 Sep 2012 21:01:47 +0000

Yes, we can avoid the need for a re-sequencing RPC, if the ACE list is
made ordered-by-user in which case the key should be a name (i.e. A
string) instead of an integer (sequence-number).

The sequence number is a CLI construct that imposes implicit ordering. But
then, if an agent is to support both CLI and Netconf, then we have to
resort to a common denominator and that happens to be the sequence number.

- muthu

---

From: "Lisa Huang (yihuan)" <[email-masked]>
Date: Fri, 28 Sep 2012 21:15:00 +0000

There is a different of changing the sequence or changing the key value. The ACL resequence is really changing the value of the key instead of change order. For example:

The original acl instance

<ipv4-ace>
<sequence-num>1</sequence-num>
   ….
<ipv4-ace>
<ipv4-ace>
<sequence-num>2</sequence-num>
   ….
<ipv4-ace>
<ipv4-ace>
<sequence-num>3</sequence-num>
   ….
<ipv4-ace>

After resequence with start=10 interval=10, it will change to:

<ipv4-ace>
<sequence-num>10</sequence-num>
   ….
<ipv4-ace>
<ipv4-ace>
<sequence-num>20</sequence-num>
   ….
<ipv4-ace>
<ipv4-ace>
<sequence-num>30</sequence-num>
   ….
<ipv4-ace>

The sequence is not changed but the key value is changed. The name of RPC resequence-acl brings confusion of reordering. My question is: what is a recommended way in YANG community to change the key value without delete the instance and recreate the instance again? I see there was some discussion going for interface keying which is a little bit different from rekey in acl.

Thanks,

Lisa

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 27, 2012 11:21 AM
To: Martin Bjorklund <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netmod] YANG module for ACL configuration

On Thu, Sep 27, 2012 at 11:02 AM, Martin Bjorklund <[email-masked]<mailto:[email-masked]>> wrote:
"Muthumayan Madhayyan (muthu)" <[email-masked]<mailto:[email-masked]>> wrote:
>
>
> On 9/27/12 12:00 AM, "Martin Bjorklund" <[email-masked]<mailto:[email-masked]>> wrote:
>
> >"Muthumayan Madhayyan (muthu)" <[email-masked]<mailto:[email-masked]>> wrote:

/martin

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Sep 2012 14:21:28 -0700

But this is kind of like line numbers in BASIC.
It might have been OK for the 80s but not now.

The relative order of the sibling nodes captures the ordering.
The sequence names can be meaningful or arbitrary (even 10, 20, 30).
They just have to be unique keys.

Andy

On Fri, Sep 28, 2012 at 2:15 PM, Lisa Huang (yihuan) <[email-masked]>wrote:

>  There is a different of changing the sequence or changing the key value.
> The ACL resequence is really changing the value of the key instead of
> change order. For example:
>
>  The sequence is not changed but the key value is changed. The name of
> RPC resequence-acl brings confusion of reordering. My question is: what is
> a recommended way in YANG community to change the key value without delete
> the instance and recreate the instance again? I see there was some
> discussion going for interface keying which is a little bit different from
> rekey in acl.
>
>  Thanks,
>
>  Lisa
>
>
>   From: Andy Bierman <[email-masked]>
> To: Martin Bjorklund <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>