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

Mahesh Jethanandani <mjethanandani@gmail.com> Thu, 11 January 2018 01:21 UTC

Return-Path: <mjethanandani@gmail.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 3C059126BFD for <netmod@ietfa.amsl.com>; Wed, 10 Jan 2018 17:21:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 5ThoS4JHbwax for <netmod@ietfa.amsl.com>; Wed, 10 Jan 2018 17:21:18 -0800 (PST)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78366120454 for <netmod@ietf.org>; Wed, 10 Jan 2018 17:21:18 -0800 (PST)
Received: by mail-oi0-x236.google.com with SMTP id w135so639895oie.3 for <netmod@ietf.org>; Wed, 10 Jan 2018 17:21:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qjUXtnAfFeP8y+GqaP0dl2jdtOpn0QZAGLZHQ0GK4PI=; b=EHl3FIPSLe0dIC76IiYRGDUz9xOycuzms4+EJ2KK9YMycOOg6suo56DOokgPzmn0fh BJOw0o+9DW0LMXN1dqdVdEnPZFo5DIvM3LLHAx8s6eVi+bAzbNn/kE40RrTexXlrPlkk p5/kI8UtDzWQxKI5fJrHMpC9D9gKfbWXfuYwGmMvjTCBU9L4wDftzZt3onYRuhTi8Owf TFUskuMczgwOgYJvWVcRHuhZyT7hz5xo+5sCgQAQLm1mjxzBSl98htsxOeso/4Qkvh8U LzWL0UIEJCq2P5BuUcxNDS2b6R+JSmIgdu4Q9vF3gKAVZTWyxN5YEvVTfKFDy+I5GBy6 f9IA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=qjUXtnAfFeP8y+GqaP0dl2jdtOpn0QZAGLZHQ0GK4PI=; b=JfeOTsWhQq4h7/2NivP+Jd4KqfEV0XsjDAmK73xPPC29QpHSy+02Ojhn7LHSQ7EUlm i8kn4G3+sytbFKFMHveMKEaWPy8ewOObneZAdDUzOGCe4jGZYjR35UdDC7B/+BMygMKf 5BlLcYDCxylh0ki1v8uyniDiT4q8bzwJrWHLDMOwXxooWnU4VGr3LrXLEhGYdzhy78LE s5yWehv/L+vw86VIkC9bkq3DGVPN4CjzSVOiG0jvHnmekSdgZiyc1Zcd/clxLHbeosZ3 T6WfXh5JhVWDoglSCMdZzogtMkBBoR9/X9za84Rhr8CTESWU30HBd2HcnlaWu6ocpk9A Sk0A==
X-Gm-Message-State: AKGB3mKyMeSaDmCJVHh8A0FhkpEbuXlvqZEl1g4zZtOODbvjI0hx6SbF jpEKgGoEf6NEkRbqJnDYU8c=
X-Google-Smtp-Source: ACJfBosVrZOT7bONTep4zB+L9AB5W9q50RYsYlaVPbkca82GVTm3fcKkIbgUw5YlvRftz8U0tOoFnQ==
X-Received: by 10.202.75.80 with SMTP id y77mr11176261oia.328.1515633677500; Wed, 10 Jan 2018 17:21:17 -0800 (PST)
Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:cde:2fd2:87ac:1a5f]) by smtp.gmail.com with ESMTPSA id t36sm961800otc.40.2018.01.10.17.21.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jan 2018 17:21:16 -0800 (PST)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <FE3FE735-65FF-4206-A672-54CD4BF7AF56@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1ED93493-BAB4-464D-8B1C-8DDF661A4D7D"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Wed, 10 Jan 2018 17:21:13 -0800
In-Reply-To: <bbe624c1-0766-9519-56d6-835ee305274d@cisco.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
To: Eliot Lear <lear@cisco.com>
References: <20171102074318.GC12688@spritelink.se> <6359CD50-0F0D-4315-A58B-1D4CF0583475@gmail.com> <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>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/X-h8V1MmLak5rFEBEgqJGRV_Q2w>
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: Thu, 11 Jan 2018 01:21:23 -0000

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>; 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 <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 <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:
>>>>> 
>>>>> Separate out the augment into a separate module (same doc is fine); or
>>>>> 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 <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 <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 <https://www.ietf.org/mailman/listinfo/netmod>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 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 <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>
> 

Mahesh Jethanandani
mjethanandani@gmail.com