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" <d...@netflix.com<mailto:d...@netflix.com>> 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 <kwat...@juniper.net<mailto:kwat...@juniper.net>> 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. Thanks, Kent // shepherd On 3/13/17, 5:57 AM, "netmod on behalf of Dean Bogdanovic" <netmod-boun...@ietf.org<mailto:netmod-boun...@ietf.org> on behalf of ivand...@gmail.com<mailto:ivand...@gmail.com>> 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. Cheers, Dean Begin forwarded message: From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> Subject: New Version Notification for draft-ietf-netmod-acl-model-10.txt Date: March 13, 2017 at 10:52:38 AM GMT+1 To: <netmod-cha...@ietf.org<mailto:netmod-cha...@ietf.org>>, "Kiran Koushik" <kkous...@cisco.com<mailto:kkous...@cisco.com>>, "Lisa Huang" <lyihuan...@gmail.com<mailto:lyihuan...@gmail.com>>, "Dean Bogdanovic" <ivand...@gmail.com<mailto:ivand...@gmail.com>>, "Dana Blair" <dbl...@cisco.com<mailto:dbl...@cisco.com>>, "Kiran Agrahara Sreenivasa" <kkous...@cisco.com<mailto:kkous...@cisco.com>> 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 URL: https://www.ietf.org/internet-drafts/draft-ietf-netmod-acl-model-10.txt Status: https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ Htmlized: https://tools.ietf.org/html/draft-ietf-netmod-acl-model-10 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-10 Abstract: 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 tools.ietf.org<http://tools.ietf.org>. The IETF Secretariat
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
