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

[Kent Watsen <[e-mail]>]

All,

I know that it's been a long delay since the last update to the ACL draft, but here's
the current status, prefaced with some history:

  * The LC for draft-ietf-netmod-acl-model-09 ended on Oct 28, but then was
     extended to Dec 14
  * draft-ietf-netmod-acl-model-10 was posted Mar 13, but David Bannister still
     had some concerns (see emails from March 28th)
  * In Chicago, some folks supporting various ACL implementations met to discuss
     and came to agree that the draft didn't meet some use cases.
  * At this point, Dean said that he didn't have the bandwidth to make the changes,
     and so the proverbial pen was transferred to others (thanks Mahesh and Sonal!)
  * The hope was that simple fixes could be made and an updated draft pushed out
     shortly (never works out the way we hope!)
  * There were 4-5 calls (and some PTOs) which have taken up the time until now.
  * David B. joined a call earlier this week and stated that the new model addresses
     his concerns (albeit with a couple tweaks that were agreed to)
  * A draft-ietf-netmod-acl-model-11 is expected to be posted eminently
  * Given the substantive changes made, this draft will need to go back to the WG
     for a full review of changes and then, once ready, it will need go through another
     IPR call and then another Last Call.

Thanks,
Kent  // shepherd


On 4/7/17, 7:33 PM, "netmod on behalf of Kent Watsen" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:


I received some additional off-list comments regarding the concerns David
raised below.  There is a small group of folks that are formulating a response.
I was hoping to send the response itself to the list by now, but it's not ready
yet.  So, instead, I'm just sending this message to let you know that a response
is forthcoming.

Thanks,
Kent  // shepherd


On 3/28/17, 2:59 PM, "David Bannister" <[e-mail]<mailto:[e-mail]>> wrote:

I would agree that the mix of L2 and L3 in the same operational ACL is a bit out of the ordinary.  I could see where a combined approach may be appealing to some.  As a network operator I do not see this as a negative.  It would be nice to give the vendor the option to defer the L2/3 combination but it does not look attainable in the current model.

"augmented by each vendor"  There are many things missing in IETF models and some things which are not under the IETF umbrella.  In this discussion the first that comes to mind is an 802.x model.  It is good to see there is currently an IEEE effort to develop one.  However, it does not exist today.  The various ether types are covered in some of the vendor models I have seen.  We take the Newco example in the draft which typedefs an enum of 'known-ether-type.'  Meanwhile Oldco is using a typedef of 'ethertype.'  Both New and Old co both augment this draft. In this scenario the network operator is stuck sorting out the logic in which vendor model to use and having to deal with two data structures for the same entity (ether-type).   Using models this way does nothing to simplify network coding and management.  I am against augmentation from vendor models for common items but it is ok for vendor unique items.  Ether-type is not vendor unique.  Augmentation has its place but it appears to be overused even within the context of IETF only models.

Not sure if pointing out ietf-routing was a good idea. Five years in the making and 42 augmenting models. :-)

If we can get the well known IETF standardized missing bits from L3, L4 for v4 and v6 into this it would work for me but I think the IETF may have missed the boat on this one.




On Sun, Mar 26, 2017 at 1:17 PM, Kent Watsen <[e-mail]<mailto:[e-mail]>> wrote:
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" <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> 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: [e-mail]<mailto:[e-mail]>
Subject: New Version Notification for draft-ietf-netmod-acl-model-10.txt
Date: March 13, 2017 at 10:52:38 AM GMT+1
To: <[e-mail]<mailto:[e-mail]>>, "Kiran Koushik" <[e-mail]<mailto:[e-mail]>>, "Lisa Huang" <[e-mail]<mailto:[e-mail]>>, "Dean Bogdanovic" <[e-mail]<mailto:[e-mail]>>, "Dana Blair" <[e-mail]<mailto:[e-mail]>>, "Kiran Agrahara Sreenivasa" <[e-mail]<mailto:[e-mail]>>


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