Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

Eliot Lear <lear@cisco.com> Fri, 12 January 2018 15:35 UTC

Return-Path: <lear@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D38812E89A for <netmod@ietfa.amsl.com>; Fri, 12 Jan 2018 07:35:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qt_Ws55eL01 for <netmod@ietfa.amsl.com>; Fri, 12 Jan 2018 07:35:42 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E62F1270AE for <netmod@ietf.org>; Fri, 12 Jan 2018 07:35:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=174268; q=dns/txt; s=iport; t=1515771341; x=1516980941; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=vL/KURld5G6Pz7mVbWaOsckXJm1MBT2JjXKErlqoBR4=; b=N+cSP4VkUElwFUQrodzW8gD6TJl2G1D0Rd28gSj2PCg2XLFxGAHal8ov ZjKjHZNdTewHmKTjt5N87ZRdEX+NrjnU61hMh7xPvv14CeAKPdIByFCkz rUvcccmKre2NCmZ6ibqN2CC9SBmpn6wEmXGHpNN9PQil6xA2p0RmnTd8Z M=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQAi1Vha/xbLJq1VCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDEYEWdCeEB4sYj26JC44mFIICBwMYAQqESU8CGoRnFwEBAQE?= =?us-ascii?q?BAQEBAWsohSQBAQQBARgBCARHCxAJAg4KIAEGAwICAh8GHxEGDQYCAQGKFwMVE?= =?us-ascii?q?JBnnXCBbTomhxUNgnABAQEBAQEBAQEBAQEBAQEBAQEBAQEOCgWEPIVUASmDBYJ?= =?us-ascii?q?rRAEBAoFFEi8fgmGCZQWSJ4dLiTU9hFeCMIEFiD2FAoIZhh2Db4drjT5AiSeBP?= =?us-ascii?q?CABN4FQMhoIGxU9giqCGzkcgWhAN4w1AQEB?=
X-IronPort-AV: E=Sophos;i="5.46,349,1511827200"; d="asc'?scan'208,217";a="1368831"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2018 15:35:38 +0000
Received: from [10.61.225.122] ([10.61.225.122]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w0CFZbmg023136; Fri, 12 Jan 2018 15:35:38 GMT
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
References: <20171102074318.GC12688@spritelink.se> <ac9fc676-80f7-723d-9a85-c99fbb122476@cisco.com> <20171102.132634.1363976895007772742.mbj@tail-f.com> <c90aa6c1-340e-2225-f960-73c1395041c5@cisco.com> <20171102164149.GD12688@spritelink.se> <6d6a1b2a-23f8-8bff-a01e-6d13cc73d92f@cisco.com> <20171103084231.GE12688@spritelink.se> <B63D5700-C13B-4D2D-9439-0E4471906374@gmail.com> <a75cf59c-7f5e-0b3b-0ace-ec9be9f67116@cisco.com> <37FA28D8-6799-491C-94CB-04237766E4D3@cisco.com> <2C381B09-15D6-417D-A70D-7C6818306FFC@gmail.com> <CAMMHi8ge4cbrVgRK8=xtJLNYCG1+p+Jh6pFeCy9sEMZP674FHQ@mail.gmail.com> <2826EF6B-A6A6-4FDA-9F30-21830D748C51@cisco.com> <0F43CDE9-21D2-4ED7-AE7C-9A2B9F854101@cisco.com> <fe8b601a-2a02-8011-b913-a49f2f486971@cisco.com> <5299E333-F1F3-4781-B467-0BFB271A4915@cisco.com> <5dd3a635-61ce-8dee-3472-589cda19fcbb@cisco.com> <3490D0AB-B7F0-4048-83F1-8151AA034E20@gmail.com> <bbe624c1-0766-9519-56d6-835ee305274d@cisco.com> <FE3FE735-65FF-4206-A672-54CD4BF7AF56@gmail.com>
From: Eliot Lear <lear@cisco.com>
Message-ID: <7ba191c8-d03d-ad2f-d9c1-2a035b0bb336@cisco.com>
Date: Fri, 12 Jan 2018 16:35:37 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <FE3FE735-65FF-4206-A672-54CD4BF7AF56@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NDjgprMq7aMndfRVLV9dHQ9l6kHeXjgH4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Aj6X4Tj6CNZz5ojYvzJyh0jMXxI>
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jan 2018 15:35:48 -0000

Ok.  What is left to agree on at this point?

Thanks Mahesh,

Eliot


On 11.01.18 02:21, Mahesh Jethanandani wrote:
> Hi Einar,
>
> I can work on updating the draft as soon as we agree on the changes.
> Should take only a couple of days to turn around and publish the draft.
>
>> On Jan 9, 2018, at 11:35 PM, Eliot Lear <lear@cisco.com
>> <mailto:lear@cisco.com>> wrote:
>>
>> Hi Mahesh,
>>
>> Thanks for this work.  I think this is okay.  In the case of MUD we
>> simply won't have the other container.  Can I please ask that you get
>> the draft out quickly as draft-ietf-opsawg-mud has been waiting quite
>> some time for this work to complete.
>>
>> Eliot
>>
>>
>> On 10.01.18 04:08, Mahesh Jethanandani wrote:
>>> I have pulled in the changes as they relate to:
>>>
>>> - moving “interface-acl” under the container “attachment-points”
>>> making it local to that container.
>>> - reverting “acl-type” to “type”
>>> - removed “interface-all-aggregate” feature
>>> - simplified source port and destination port definition
>>>
>>> The pull request for the changes can be found here.
>>>
>>> https://github.com/netmod-wg/acl-model/pull/20
>>>
>>> After discussing with some of the original contributors, decided not
>>> to include the change as it relates to augmenting ietf-interfaces.
>>> We did not find that the change had a particular advantage over the
>>> current implementation. Even if we do not completely understand how
>>> ACLs might be attached “globally” or on something that is not an
>>> interface, having the flexibility to attach them to other attachment
>>> points is important. Keeping it as interface-ref gives us that
>>> flexibility.
>>>
>>> Cheers.
>>>
>>>> On Dec 18, 2017, at 4:31 AM, Eliot Lear <lear@cisco.com
>>>> <mailto:lear@cisco.com>> wrote:
>>>>
>>>> So long as nobody expects an interface construct in a MUD file, I'm
>>>> happy.
>>>>
>>>>
>>>> On 17.12.17 15:34, Einar Nilsen-Nygaard (einarnn) wrote:
>>>>> Eliot,
>>>>>
>>>>> Nothing can force an implementation to have to implement either
>>>>> the ietf-interfaces model or the augmentation in the
>>>>> ietf-access-control-list model. I appreciate your desire for
>>>>> modularity and cohesiveness, but I would resist #1, because I feel
>>>>> that the majority of users will be targeting interface-based
>>>>> attachment over time. I’ve adde back in use of the
>>>>> “interface-attachment” feature (which I took out as part of
>>>>> refactoring interface attachment). Part of:
>>>>>
>>>>>     https://github.com/netmod-wg/acl-model/pull/21
>>>>>
>>>>>
>>>>> The augments part of the tree now looks like:
>>>>>
>>>>>   augment /if:interfaces/if:interface:
>>>>>     +--rw acls *{interface-attachment}*?
>>>>>        +--rw ingress
>>>>>        |  +--rw acl-sets
>>>>>        |     +--rw acl-set* [name]
>>>>>        |        +--rw name              -> /access-lists/acl/name
>>>>>        |        +--rw type?             -> /access-lists/acl/type
>>>>>        |        +--ro ace-statistics* [name] {interface-stats}?
>>>>>        |           +--ro name               ->
>>>>> /access-lists/acl/aces/ace/name
>>>>>        |           +--ro matched-packets?   yang:counter64
>>>>>        |           +--ro matched-octets?    yang:counter64
>>>>>        +--rw egress
>>>>>           +--rw acl-sets
>>>>>              +--rw acl-set* [name]
>>>>>                 +--rw name              -> /access-lists/acl/name
>>>>>                 +--rw type?             -> /access-lists/acl/type
>>>>>                 +--ro ace-statistics* [name] {interface-stats}?
>>>>>                    +--ro name               ->
>>>>> /access-lists/acl/aces/ace/name
>>>>>                    +--ro matched-packets?   yang:counter64
>>>>>                    +--ro matched-octets?    yang:counter64
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Einar
>>>>>
>>>>>
>>>>>> On 17 Dec 2017, at 11:29, Eliot Lear <lear@cisco.com
>>>>>> <mailto:lear@cisco.com>> wrote:
>>>>>>
>>>>>> Einar,
>>>>>>
>>>>>> I think this change is fine, with one exception.  I would rather
>>>>>> the augment to the interface not be required for implementations
>>>>>> that don't actually have interfaces.  I understand that there may
>>>>>> be two ways to go about this:
>>>>>>
>>>>>>  1. Separate out the augment into a separate module (same doc is
>>>>>>     fine); or
>>>>>>  2. Somehow "feature-ize" the augment.
>>>>>>
>>>>>> I don't know how to do (2) but if you do, that's okay by me.
>>>>>>
>>>>>> Eliot
>>>>>>
>>>>>>
>>>>>> On 16.12.17 14:19, Einar Nilsen-Nygaard (einarnn) wrote:
>>>>>>> All,
>>>>>>>
>>>>>>> After a series of discussions on- and off-list, I have a
>>>>>>> candidate PR that includes the changes in the PR Mahesh sent out
>>>>>>> plus some more edits. Please see consolidated PR here:
>>>>>>>
>>>>>>>     https://github.com/netmod-wg/acl-model/pull/21
>>>>>>>
>>>>>>>
>>>>>>> Main changes in addition to Mahesh’s PR are:
>>>>>>>
>>>>>>>   * Moved interface attachment to be via an interface augmentation.
>>>>>>>   * Restructured port matches slightly under both IPv4 and IPv6
>>>>>>>     containers.
>>>>>>>   * Removed unnecessary identity 'interface-acl-aggregate’.
>>>>>>>   * Removed action ‘icmp-off’, can be augmented later.
>>>>>>>
>>>>>>>
>>>>>>> For reference, here is the current YANG tree plus “--ietf” logs:
>>>>>>>
>>>>>>> 13:12 $ pyang --ietf --lint -f tree ietf-access-control-list.yang
>>>>>>> ietf-access-control-list.yang:51: error: bad value "YYYY-MM-DD"
>>>>>>> (should be date)
>>>>>>> module: ietf-access-control-list
>>>>>>>     +--rw access-lists
>>>>>>>        +--rw acl* [name]
>>>>>>>           +--rw name    string
>>>>>>>           +--rw type?   acl-type
>>>>>>>           +--rw aces
>>>>>>>              +--rw ace* [name]
>>>>>>>                 +--rw name          string
>>>>>>>                 +--rw matches
>>>>>>>                 |  +--rw (l2)?
>>>>>>>                 |  |  +--:(eth)
>>>>>>>                 |  |     +--rw eth {match-on-eth}?
>>>>>>>                 |  |        +--rw destination-mac-address?      
>>>>>>>  yang:mac-address
>>>>>>>                 |  |        +--rw destination-mac-address-mask?
>>>>>>>   yang:mac-address
>>>>>>>                 |  |        +--rw source-mac-address?          
>>>>>>>   yang:mac-address
>>>>>>>                 |  |        +--rw source-mac-address-mask?      
>>>>>>>  yang:mac-address
>>>>>>>                 |  |        +--rw ethertype?                    
>>>>>>>  eth:ethertype
>>>>>>>                 |  +--rw (l3)?
>>>>>>>                 |  |  +--:(ipv4)
>>>>>>>                 |  |  |  +--rw ipv4 {match-on-ipv4}?
>>>>>>>                 |  |  |     +--rw dscp?                      
>>>>>>> inet:dscp
>>>>>>>                 |  |  |     +--rw ecn?                        uint8
>>>>>>>                 |  |  |     +--rw length?                     uint16
>>>>>>>                 |  |  |     +--rw ttl?                        uint8
>>>>>>>                 |  |  |     +--rw protocol?                   uint8
>>>>>>>                 |  |  |     +--rw (source-port-range-or-operator)?
>>>>>>>                 |  |  |     |  +--:(range)
>>>>>>>                 |  |  |     |  |  +--rw source-port-lower      
>>>>>>>     inet:port-number
>>>>>>>                 |  |  |     |  |  +--rw source-port-upper      
>>>>>>>     inet:port-number
>>>>>>>                 |  |  |     |  +--:(operator)
>>>>>>>                 |  |  |     |     +--rw source-operator        
>>>>>>>     operator
>>>>>>>                 |  |  |     |     +--rw source-port            
>>>>>>>     inet:port-number
>>>>>>>                 |  |  |     +--rw
>>>>>>> (destination-port-range-or-operator)?
>>>>>>>                 |  |  |     |  +--:(range)
>>>>>>>                 |  |  |     |  |  +--rw destination-port-lower  
>>>>>>>    inet:port-number
>>>>>>>                 |  |  |     |  |  +--rw destination-port-upper  
>>>>>>>    inet:port-number
>>>>>>>                 |  |  |     |  +--:(operator)
>>>>>>>                 |  |  |     |     +--rw destination-operator    
>>>>>>>    operator
>>>>>>>                 |  |  |     |     +--rw destination-port        
>>>>>>>    inet:port-number
>>>>>>>                 |  |  |     +--rw ihl?                        uint8
>>>>>>>                 |  |  |     +--rw flags?                      bits
>>>>>>>                 |  |  |     +--rw offset?                     uint16
>>>>>>>                 |  |  |     +--rw identification?             uint16
>>>>>>>                 |  |  |     +--rw destination-ipv4-network?  
>>>>>>> inet:ipv4-prefix
>>>>>>>                 |  |  |     +--rw source-ipv4-network?      
>>>>>>>  inet:ipv4-prefix
>>>>>>>                 |  |  +--:(ipv6)
>>>>>>>                 |  |     +--rw ipv6 {match-on-ipv6}?
>>>>>>>                 |  |        +--rw dscp?                      
>>>>>>> inet:dscp
>>>>>>>                 |  |        +--rw ecn?                        uint8
>>>>>>>                 |  |        +--rw length?                     uint16
>>>>>>>                 |  |        +--rw ttl?                        uint8
>>>>>>>                 |  |        +--rw protocol?                   uint8
>>>>>>>                 |  |        +--rw (source-port-range-or-operator)?
>>>>>>>                 |  |        |  +--:(range)
>>>>>>>                 |  |        |  |  +--rw source-port-lower      
>>>>>>>     inet:port-number
>>>>>>>                 |  |        |  |  +--rw source-port-upper      
>>>>>>>     inet:port-number
>>>>>>>                 |  |        |  +--:(operator)
>>>>>>>                 |  |        |     +--rw source-operator        
>>>>>>>     operator
>>>>>>>                 |  |        |     +--rw source-port            
>>>>>>>     inet:port-number
>>>>>>>                 |  |        +--rw
>>>>>>> (destination-port-range-or-operator)?
>>>>>>>                 |  |        |  +--:(range)
>>>>>>>                 |  |        |  |  +--rw destination-port-lower  
>>>>>>>    inet:port-number
>>>>>>>                 |  |        |  |  +--rw destination-port-upper  
>>>>>>>    inet:port-number
>>>>>>>                 |  |        |  +--:(operator)
>>>>>>>                 |  |        |     +--rw destination-operator    
>>>>>>>    operator
>>>>>>>                 |  |        |     +--rw destination-port        
>>>>>>>    inet:port-number
>>>>>>>                 |  |        +--rw destination-ipv6-network?  
>>>>>>> inet:ipv6-prefix
>>>>>>>                 |  |        +--rw source-ipv6-network?      
>>>>>>>  inet:ipv6-prefix
>>>>>>>                 |  |        +--rw flow-label?                
>>>>>>> inet:ipv6-flow-label
>>>>>>>                 |  +--rw (l4)?
>>>>>>>                 |  |  +--:(tcp)
>>>>>>>                 |  |  |  +--rw tcp {match-on-tcp}?
>>>>>>>                 |  |  |     +--rw sequence-number?          uint32
>>>>>>>                 |  |  |     +--rw acknowledgement-number?   uint32
>>>>>>>                 |  |  |     +--rw data-offset?              uint8
>>>>>>>                 |  |  |     +--rw reserved?                 uint8
>>>>>>>                 |  |  |     +--rw flags?                    bits
>>>>>>>                 |  |  |     +--rw window-size?              uint16
>>>>>>>                 |  |  |     +--rw urgent-pointer?           uint16
>>>>>>>                 |  |  |     +--rw options?                  uint32
>>>>>>>                 |  |  +--:(udp)
>>>>>>>                 |  |  |  +--rw udp {match-on-udp}?
>>>>>>>                 |  |  |     +--rw length?   uint16
>>>>>>>                 |  |  +--:(icmp)
>>>>>>>                 |  |     +--rw icmp {match-on-icmp}?
>>>>>>>                 |  |        +--rw type?             uint8
>>>>>>>                 |  |        +--rw code?             uint8
>>>>>>>                 |  |        +--rw rest-of-header?   uint32
>>>>>>>                 |  +--rw egress-interface?    if:interface-ref
>>>>>>>                 |  +--rw ingress-interface?   if:interface-ref
>>>>>>>                 +--rw actions
>>>>>>>                 |  +--rw forwarding    identityref
>>>>>>>                 |  +--rw logging?      identityref
>>>>>>>                 +--ro statistics {acl-aggregate-stats}?
>>>>>>>                    +--ro matched-packets?   yang:counter64
>>>>>>>                    +--ro matched-octets?    yang:counter64
>>>>>>>
>>>>>>>   augment /if:interfaces/if:interface:
>>>>>>>     +--rw acls
>>>>>>>        +--rw ingress
>>>>>>>        |  +--rw acl-sets
>>>>>>>        |     +--rw acl-set* [name]
>>>>>>>        |        +--rw name              -> /access-lists/acl/name
>>>>>>>        |        +--rw type?             -> /access-lists/acl/type
>>>>>>>        |        +--ro ace-statistics* [name] {interface-stats}?
>>>>>>>        |           +--ro name               ->
>>>>>>> /access-lists/acl/aces/ace/name
>>>>>>>        |           +--ro matched-packets?   yang:counter64
>>>>>>>        |           +--ro matched-octets?    yang:counter64
>>>>>>>        +--rw egress
>>>>>>>           +--rw acl-sets
>>>>>>>              +--rw acl-set* [name]
>>>>>>>                 +--rw name              -> /access-lists/acl/name
>>>>>>>                 +--rw type?             -> /access-lists/acl/type
>>>>>>>                 +--ro ace-statistics* [name] {interface-stats}?
>>>>>>>                    +--ro name               ->
>>>>>>> /access-lists/acl/aces/ace/name
>>>>>>>                    +--ro matched-packets?   yang:counter64
>>>>>>>                    +--ro matched-octets?    yang:counter64
>>>>>>>
>>>>>>> Comments welcome!
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Einar
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 14 Dec 2017, at 18:50, Einar Nilsen-Nygaard (einarnn)
>>>>>>>> <einarnn@cisco.com <mailto:einarnn@cisco.com>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 14 Dec 2017, at 08:21, Sonal Agarwal <sagarwal12@gmail.com
>>>>>>>>> <mailto:sagarwal12@gmail.com>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Einar,
>>>>>>>>>
>>>>>>>>> You had 3 questions for me on all the several e-mail threads. 
>>>>>>>>> 1. Global attachment point
>>>>>>>>> 2. icmp-off
>>>>>>>>> 3. acl-aggregate-interface stats.
>>>>>>>>>
>>>>>>>>> For (1), my first preference is to have the model define
>>>>>>>>> attachment point for interfaces only.
>>>>>>>>
>>>>>>>> einarnn> I have some diffs, layered on top of Mahesh’s PR to
>>>>>>>> netmod-wg/acl-model that do this. Nearly like the augmentation
>>>>>>>> I have below. Feel free to take a look at:
>>>>>>>>
>>>>>>>>     https://github.com/mjethanandani/acl-model/pull/3
>>>>>>>>
>>>>>>>>
>>>>>>>>> However, Kristian wants the global attachment point as well so
>>>>>>>>> that he can add the ACL to the linux tables.
>>>>>>>>
>>>>>>>> einarnn> I think Kristian doesn’t feel a global attachment
>>>>>>>> point needs to be in this first revision. But he can confirm.
>>>>>>>>
>>>>>>>>> If an ACL is attached globally, does this mean it is per
>>>>>>>>> direction or does it mean it is across directions?
>>>>>>>>
>>>>>>>> einarnn> I don’t know right now :-)
>>>>>>>>
>>>>>>>>> This global ACL may not be applicable to any of Cisco's
>>>>>>>>> service provider routers as I don't see any platform actually
>>>>>>>>> replicating the ACL to all line cards and attaching it in
>>>>>>>>> ingress and egress directions across all interfaces.
>>>>>>>>
>>>>>>>> einarnn> Per other emails, I don’t think we understand this
>>>>>>>> enough yet to specify it, so I suggest we just leave it out for
>>>>>>>> now. Nothing in the model prevents a “global attachment point”
>>>>>>>> being added later once we understand what it really means.
>>>>>>>>
>>>>>>>>> For (2), I am ok with removing icmp-off.
>>>>>>>>
>>>>>>>> einarnn> Done in my PR above.
>>>>>>>>
>>>>>>>>> For (3), this would have to be a combination of ACL stats
>>>>>>>>> across all interfaces for all ACL's. Something like this is
>>>>>>>>> possible on an XR box where ACES have counter names associated
>>>>>>>>> with it. Let's chat about this offline tomorrow.
>>>>>>>>
>>>>>>>> einarnn> I’ll ping you to clarify, and we can bring any
>>>>>>>> conclusion back to the list.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Einar
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Sonal.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Dec 13, 2017 at 12:10 PM, Mahesh Jethanandani
>>>>>>>>> <mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>> wrote:
>>>>>>>>>
>>>>>>>>>     We want to support “global” attachment point down the
>>>>>>>>>     line, and that “global” attachment point will be one of
>>>>>>>>>     the choices (the other being the interface), what would
>>>>>>>>>     this augment look like. Note, as far as I know, you cannot
>>>>>>>>>     augment inside a choice node.
>>>>>>>>>
>>>>>>>>>>     On Dec 13, 2017, at 6:57 AM, Einar Nilsen-Nygaard
>>>>>>>>>>     (einarnn) <einarnn@cisco.com <mailto:einarnn@cisco.com>>
>>>>>>>>>>     wrote:
>>>>>>>>>>
>>>>>>>>>>     Perhaps like this, as an augmentation to the interface:
>>>>>>>>>>
>>>>>>>>>>           augment /if:interfaces/if:interface:
>>>>>>>>>>             +--rw ingress-acls
>>>>>>>>>>             |  +--rw acl-sets
>>>>>>>>>>             |     +--rw acl-set* [name]
>>>>>>>>>>             |        +--rw name              ->
>>>>>>>>>>         /access-lists/acl/name
>>>>>>>>>>             |        +--rw type?             ->
>>>>>>>>>>         /access-lists/acl/type
>>>>>>>>>>             |        +--ro ace-statistics* [name]
>>>>>>>>>>         {interface-stats}?
>>>>>>>>>>             |           +--ro name               ->
>>>>>>>>>>         /access-lists/acl/aces/ace/name
>>>>>>>>>>             |           +--ro matched-packets?   yang:counter64
>>>>>>>>>>             |           +--ro matched-octets?    yang:counter64
>>>>>>>>>>             +--rw egress-acls
>>>>>>>>>>                +--rw acl-sets
>>>>>>>>>>                   +--rw acl-set* [name]
>>>>>>>>>>                      +--rw name              ->
>>>>>>>>>>         /access-lists/acl/name
>>>>>>>>>>                      +--rw type?             ->
>>>>>>>>>>         /access-lists/acl/type
>>>>>>>>>>                      +--ro ace-statistics* [name]
>>>>>>>>>>         {interface-stats}?
>>>>>>>>>>                         +--ro name               ->
>>>>>>>>>>         /access-lists/acl/aces/ace/name
>>>>>>>>>>                         +--ro matched-packets?   yang:counter64
>>>>>>>>>>                         +--ro matched-octets?    yang:counter64
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>     Could also put an “aces” container above both these &
>>>>>>>>>>     rename “ingress-acls" to “ingress”, etc. to give a single
>>>>>>>>>>     root for the augmentation if preferred.
>>>>>>>>>>
>>>>>>>>>>     Cheers,
>>>>>>>>>>
>>>>>>>>>>     Einar
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>     On 6 Dec 2017, at 19:43, Eliot Lear <lear@cisco.com
>>>>>>>>>>>     <mailto:lear@cisco.com>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>     On 12/6/17 7:23 PM, Mahesh Jethanandani wrote:
>>>>>>>>>>>>     How does one move the interface attachment point,
>>>>>>>>>>>>     currently an
>>>>>>>>>>>>     'interface-ref', to an augmentation of the
>>>>>>>>>>>>     if:interfaces/interface,
>>>>>>>>>>>>     inside of the ‘acl’  container? Down the line we might
>>>>>>>>>>>>     need to have an
>>>>>>>>>>>>     container for "attachment points" to accommodate the
>>>>>>>>>>>>     possibility of
>>>>>>>>>>>>     attaching an ACL either to an interface or “globally”.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>     Keeping in mind that one use is that an ACL doesn't
>>>>>>>>>>>     attach to an
>>>>>>>>>>>     interface at all.
>>>>>>>>>>>
>>>>>>>>>>>     _______________________________________________
>>>>>>>>>>>     netmod mailing list
>>>>>>>>>>>     netmod@ietf.org <mailto:netmod@ietf.org>
>>>>>>>>>>>     https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>>>>>     <https://www.ietf.org/mailman/listinfo/netmod>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     Mahesh Jethanandani
>>>>>>>>>     mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>     _______________________________________________
>>>>>>>>>     netmod mailing list
>>>>>>>>>     netmod@ietf.org <mailto:netmod@ietf.org>
>>>>>>>>>     https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>>>     <https://www.ietf.org/mailman/listinfo/netmod>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> netmod mailing list
>>>>>>>> netmod@ietf.org <mailto:netmod@ietf.org>
>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> netmod mailing list
>>>>>>> netmod@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org <mailto:netmod@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>> Mahesh Jethanandani
>>> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
> Mahesh Jethanandani
> mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>
>