Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14
Eliot Lear <lear@cisco.com> Wed, 10 January 2018 07: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 8F734124319 for <netmod@ietfa.amsl.com>; Tue, 9 Jan 2018 23:35:56 -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 0K4Um0Np2X0T for <netmod@ietfa.amsl.com>; Tue, 9 Jan 2018 23:35:52 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D67F12025C for <netmod@ietf.org>; Tue, 9 Jan 2018 23:35:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=139283; q=dns/txt; s=iport; t=1515569751; x=1516779351; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=5oPcs3JjdXobwTh9icbvA60ufqEhiB1EPg6Ivjh1UHk=; b=NxDsA1oA9J/UB2elhsgJRNJGTRUQlvNgDov2xLPh601vdabe3DhQOvXv jnu9hbMJsgmBgvZa5nMRFhguF73rAON6/OiknBNtpQhy7OPcMWzb6Jold MgJk0cjmXFgOPGz8euIvTzn1RS7v80ZEeow0OrJbZQwn+LfvOqHbq3vnI g=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CkAQAGwVVa/xbLJq1UCRkBAQEBAQEBAQEBAQEHAQEBAQGDEYEWdCeEB4sYj0UniQuOJBSBfwMHAxgBCoRJTwIahGIWAQEBAQEBAQEBayiFJAEBAQMBARgBCARHGwkCDgogAQYDAgICHwYfEQYBDAYCAQGKFwMVEJE1nW6BbTomhxgNgnABAQEBAQEBAQEBAQEBAQEBAQEBAQEOCgWEIIVUASkMgnmCa0QBgUQSLx+CYYJlBZInh0qJMz2EVoIvgQWIOIUBgheGGINvh2qNNkCJJYE8JQEygVAyGggbFT2CKoIbORyBaEA3i2ABAQE
X-IronPort-AV: E=Sophos;i="5.46,339,1511827200"; d="asc'?scan'208,217";a="1370125"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2018 07:35:48 +0000
Received: from [10.61.225.122] ([10.61.225.122]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w0A7ZlHt007125; Wed, 10 Jan 2018 07:35:48 GMT
To: Mahesh Jethanandani <mjethanandani@gmail.com>, "netmod@ietf.org" <netmod@ietf.org>
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>
From: Eliot Lear <lear@cisco.com>
Message-ID: <bbe624c1-0766-9519-56d6-835ee305274d@cisco.com>
Date: Wed, 10 Jan 2018 08:35:47 +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: <3490D0AB-B7F0-4048-83F1-8151AA034E20@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="6Pr28Ab55iRndvQuU15frpObkLGriIb57"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/nj_Ha49VFWRGUWgwPcJ5W6OH6II>
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: Wed, 10 Jan 2018 07:35:57 -0000
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
- [netmod] WG Last Call: draft-ietf-netmod-acl-mode… Kent Watsen
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kent Watsen
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Sonal Agarwal
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Acee Lindem (acee)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Acee Lindem (acee)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Martin Bjorklund
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Juergen Schoenwaelder
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Juergen Schoenwaelder
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Dean Bogdanovic
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Robert Wilton
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Martin Bjorklund
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Robert Wilton
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Robert Wilton
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Robert Wilton
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Robert Wilton
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Sonal Agarwal
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Sonal Agarwal
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kent Watsen
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Kristian Larsson
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Thomas Nadeau
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Sonal Agarwal
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Juergen Schoenwaelder
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Juergen Schoenwaelder
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Einar Nilsen-Nygaard (einarnn)
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Eliot Lear
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Mahesh Jethanandani
- Re: [netmod] WG Last Call: draft-ietf-netmod-acl-… Sonal Agarwal