Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-acl-model-10.txt

Kent Watsen <> Sun, 26 March 2017 17:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23E68129650 for <>; Sun, 26 Mar 2017 10:17:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zWVtxwSHGTDi for <>; Sun, 26 Mar 2017 10:17:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9FB421270A7 for <>; Sun, 26 Mar 2017 10:17:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=S7RYdnF/Uo/3HLeNsQRtV8RgLqB/0kzHBtwogP7I+3k=; b=dBhmRbyOmEAyUoX3meSkuNzDzu8UchRvU+1kXUeCM4SQkrisHLjlPIVjz8s3qCMA8qUcJu4s0SdSNkEXNDBKwSU51Mgjj4kPZPsh/EvMiEkjIRnn9Xiz9zqeZSmczDMqGk7UnXF9aDOt1lmgd+lLlRKqoD5crfaXpiSwY4ew5hM=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Sun, 26 Mar 2017 17:17:29 +0000
Received: from ([]) by ([]) with mapi id 15.01.1005.007; Sun, 26 Mar 2017 17:17:29 +0000
From: Kent Watsen <>
To: David Bannister <>
CC: Dean Bogdanovic <>, NetMod WG <>
Thread-Topic: [netmod] Fwd: New Version Notification for draft-ietf-netmod-acl-model-10.txt
Thread-Index: AQHSnSlHwAqIi04elk+0OsiclimezKGaqssAgAyBg4A=
Date: Sun, 26 Mar 2017 17:17:29 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:a87nE7mhmaUMuPnjCK8iXiAuiK0FpaTHPrVyZ6R44LRx3Ombr7Py/KEKu54E2QX7Bs2QLXJaitNtdCHU73fCt3EeDdH0QWknAFxE+12bYsFDY6W++b9KtuNekZd7vyMsQJMjwE5kRCMSZCRS36Fs2TbiG+PpT0lffhQRQ2JodzgmpsPx9wnZekA94IIN+Ia5gvWQ+wJTGqaiLA8G3fE66MnbhK4OnXDUZhO6omKNyeb2zyyZNhjygjBUmz9QsN+GQa7t15aVCVxB23rrjT6rlBNGCHbDU/BHTL/W3xqnRs07NCJL9zobH8ripZFSBaHLUJhQVhbU2TWXarfyL9z9ew==
x-ms-office365-filtering-correlation-id: 2ce1de03-8e84-405d-796b-08d4746bfb76
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:BN3PR0501MB1441;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(120809045254105)(138986009662008)(95692535739014)(177428888720325)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123558025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441;
x-forefront-prvs: 0258E7CCD4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39410400002)(39840400002)(39450400003)(39850400002)(39860400002)(377454003)(76104003)(78124002)(53824002)(377424004)(24454002)(229853002)(6916009)(2950100002)(81166006)(33656002)(8676002)(8936002)(76176999)(5660300001)(7906003)(36756003)(7736002)(54906002)(606005)(6306002)(6436002)(6512007)(54896002)(50986999)(99286003)(110136004)(236005)(54356999)(25786009)(53936002)(53546009)(39060400002)(6246003)(4326008)(86362001)(6506006)(38730400002)(53386004)(2906002)(6486002)(77096006)(10710500007)(7110500001)(189998001)(3280700002)(4001350100001)(3660700001)(93886004)(230783001)(122556002)(66066001)(3846002)(102836003)(6116002)(15650500001)(2900100001)(14971765001)(2420400007)(83716003)(82746002)(83506001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441;; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_86AA35DF0D2245E7A954E766133ED49Djunipernet_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2017 17:17:29.3688 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441
Archived-At: <>
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-acl-model-10.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 26 Mar 2017 17:17:37 -0000

HI David,

I believe an analogy to the ietf-routing module can and should be made here.  In both cases, the module provides a minimal skeleton that is intended to be extended by augmentations.   If anything, I could argue that the acl module doesn't go far enough, in that there is no feature statement on the "ace-ip" and "ace-eth" case statements, as if it's assuming that all servers implement L3 and L2 ACLs, which I find suspicious...

You write below "augmented by each vendor", but I don't believe that this is the intent, so much as (just like with the ietf-routing) that future IETF modules will be defined to flesh it out.  In particular, the existing "ace-ip" and "ace-eth" case statements can be augmented, as well as brand new case statements added.   I agree that, in its current form, this draft is of limited use, but keep in my that the ietf-routing module now has 42 other modules augmenting it, so there's hope that the ietf-access-control-list module will similarly be fleshed out in short order.

What do you think?  Do you think we should put feature statements on the two case statements, or even move these into other modules (in the same draft) so that there is no specialness imparted on them?

What about others?  I'm concerned that we may not have sufficient domain expertise in the NETMOD WG - similar to the routing-cfg draft, until the rtgwg started to focus on it.

Kent  // shepherd

On 3/18/17, 9:18 AM, "David Bannister" <<>> wrote:

(second try)
There were no changes to the model so my concerns remain the same.  Augmentation is not a scalable solution when dealing with a mutli-vendor or in some instances a multi-business-unit environment.  The 'newco' example in the draft illustrates this problem.  The IETF produces a 'standard' for an ACL draft which is so sparse in nature that it must be augmented by each vendor.  In the best case this gives me a unique model per vendor because we know the vendors are not going to get together to define the missing pieces.  The vendors will use a variety of mechanisms to complete the model from using a script to build their models from source code, handling the missing pieces as arbitrary code (anyxml), or everything as a string.  Then there is the worse case where a vendor has no internal standardization (you know who you are) and their own product lines will not align into a common model.  The object here, for me, is to get to a single model for all vendors barring a unique feature that belongs to one vendor in which case augmentation is acceptable.

Could you add to this in the future and rev up the RFC?  Sure.  However, I am not sure what value that brings to the community.  In its current form I would not ask any of my vendors to implement this draft.  Instead I would push them towards the OpenConfig ACL model.

On Tue, Mar 14, 2017 at 9:12 PM, Kent Watsen <<>> wrote:
Hi David,

Can you please confirm that the additional examples address your concern?  And, if not, please
explain if there is any reason why what you're looking for couldn't be added or augmented in
in the future.

Kent // shepherd

On 3/13/17, 5:57 AM, "netmod on behalf of Dean Bogdanovic" <<> on behalf of<>> wrote:

Here is the new version of the ACL draft. Since December and some additional comments about the ACL model, I spoke with many operators and how they use ACLs. I have also received lot of detailed ACL configurations. In most cases, the model is easily adapted to the current use cases in operations. But to answer the comments, the authors have added a detailed example in the addendum section how the model can be extended and how this model can be used.



Begin forwarded message:

Subject: New Version Notification for draft-ietf-netmod-acl-model-10.txt
Date: March 13, 2017 at 10:52:38 AM GMT+1
To: <<>>, "Kiran Koushik" <<>>, "Lisa Huang" <<>>, "Dean Bogdanovic" <<>>, "Dana Blair" <<>>, "Kiran Agrahara Sreenivasa" <<>>

A new version of I-D, draft-ietf-netmod-acl-model-10.txt
has been successfully submitted by Dean Bogdanovic and posted to the
IETF repository.

Name: draft-ietf-netmod-acl-model
Revision: 10
Title: Network Access Control List (ACL) YANG Data Model
Document date: 2017-03-13
Group: netmod
Pages: 32

  This document describes a data model of Access Control List (ACL)
  basic building blocks.

  Editorial Note (To be removed by RFC Editor)

  This draft contains many placeholder values that need to be replaced
  with finalized values at the time of publication.  This note
  summarizes all of the substitutions that are needed.  Please note
  that no other RFC Editor instructions are specified anywhere else in
  this document.

  Artwork in this document contains shorthand references to drafts in
  progress.  Please apply the following replacements

  o  "XXXX" --> the assigned RFC value for this draft.

  o  Revision date in model (Oct 12, 2016) needs to get updated with
     the date the draft gets approved.  The date also needs to get
     reflected on the line with <CODE BEGINS>.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at<>.

The IETF Secretariat