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

[David Bannister <[e-mail]>]

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]> 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]> 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]> 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] on behalf of [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]
>
> *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]>, "Kiran Koushik" <[e-mail]>,
> "Lisa Huang" <[e-mail]>, "Dean Bogdanovic" <[e-mail]>,
> "Dana Blair" <[e-mail]>, "Kiran Agrahara Sreenivasa" <
> [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.
>
> The IETF Secretariat
>
>
>
>
>