Re: [netmod] WG adoption call: draft-dbb-netmod-acl-03

[Dean Bogdanovic]

Support the adoption

Dean

On 19 Dec 2022, at 18:00, Lou Berger wrote:

> Hello,
>
> This email begins a 3-week adoption poll for: 
> https://datatracker.ietf.org/doc/draft-dbb-netmod-acl/
>
> Please voice your support or technical objections to adoption on the
> list by the end of the day (any time zone) January 9.
>
> This is an extended call due to the holiday/New Year.
>
> Thank you,
> Lou (as Co-chair)
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] IPR call draft-ietf-netmod-module-tags-02

[Dean Bogdanovic]

> On Sep 27, 2018, at 12:26 AM, joel jaeggli  wrote:
> 
> Authors, Contributors, WG,
> 
> Regarding the document
> draft-ietf-netmod-module-tags-02
> https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02
> Are you aware of any IPR that applies to draft identified above?
> 

No, I'm not aware of any IPR that applies to this draft

Dean

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Correction, date It ends Feb 20th Re: Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

[Dean Bogdanovic]

yes/support

no, I'm not aware of any IPR that applies to this document...

Dean
> On Feb 6, 2018, at 18:57, joel jaeggli  wrote:
> 
> Sorry, Feb 20th is the end date for the adoption call.
> 
> regards
> 
> joel
> 
>> On 2/6/18 3:47 PM, joel jaeggli wrote:
>> Hi, 
>> 
>> This is the start of a *two* week poll on making 
>> draft-rtgyangdt-netmod-module-tags-02 a working group document.  
>> 
>> https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02
>> This document was most recently discussed at IETF 100.
>> 
>> Please send email to the list indicating "yes/support" or "no/do not 
>> support".  If indicating no, please state your reservations with the 
>> document.  If yes, please also feel free to provide comments you'd like to 
>> see addressed once the document is a WG document. 
>> 
>> This poll ends on February 8. 
>> 
>> Thank you! 
>> Joel Jaeggli and IETF NETMOD Co-Chairs
>> 
>> 
>> ___
>> netmod mailing list
>> 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
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Live meeting? and my opinion. [Re: moving forward with schema mount]

[Dean Bogdanovic]

I will ask a different question

How many people have implemented the draft? And are they talking from 
experience implementing the model? I have implemented LNE and NI and to be 
honest, when customers ask about IETF compatibility, i reference a draft and 
tell them it will take long time until IETF finalizes the RFC. When it does, we 
will update the implementation if needed. Within WG are hearing very little 
about implementation and operational experience and feedback during the 
process. 
If any company had to wait two or more years to release software, they would 
find themselves out of customers.

Dean

> On Jan 26, 2018, at 10:22 AM, Juergen Schoenwaelder 
>  wrote:
> 
> OK, I accept that you do not care. Please also accept that others do
> care. And these people believe YANG library bis is needed.
> 
> Since you do not want to read emails and involve yourself in
> discussions of technical details, I assume this is where our
> conversation stops.
> 
> I tought you wanted to start a constructive conversation towards a
> resolution of the problem but it seems I misunderstood.
> 
> /js
> 
> On Fri, Jan 26, 2018 at 10:06:06AM -0500, Christian Hopps wrote:
>> 
>> In the context of holding up this work, I don't care one iota about YANG
>> library bis, and it works just fine with NMDA AFAICT.
>> 
>> We need models to get work done.
>> 
>> Thanks,
>> Chris.
>> 
>> Juergen Schoenwaelder  writes:
>> 
>>> On Fri, Jan 26, 2018 at 09:18:55AM -0500, Christian Hopps wrote:
 
 Now it seems we are supposed to wait a bunch longer on yet other works
 in progress for as near as I can tell (could be wrong here as I just
 don't have time to read the very long email threads that netmod
 generates) capturing meta-data in a cleaner way than another. This does
 *not* seem like a reason to stall this work any further.
 
>>> 
>>> What is your interpretation of 'a bunch longer'? Or said differently,
>>> how much time do you think it will take to get the current schema
>>> mount approved (which has pending WG last call issues) and how much
>>> time would you find acceptable for a solution that also complies with
>>> NMDA and YANG library bis? I believe people are willing to give the
>>> later high priority.
>>> 
>>> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] schema mount and YANG library

[Dean Bogdanovic]

As Lou mentioned, schema mount can be used with or without YANG library. As 
author who uses the schema mount in a draft and in product, don’t want to hold 
back the publication. We, IETF, are too slow. Getting data model RFCs published 
takes too much time and we are not getting experience from implementation and 
operational usage. Things have to move much faster or the industry will move 
away from this organization. At the end, if we need to we can revise to support 
future publications. 

Dean

> On Jan 19, 2018, at 2:00 PM, Lou Berger  wrote:
> 
> Rob,
> 
> 
> On January 19, 2018 1:05:46 PM Robert Wilton  wrote:
> 
>> 
>> 
>> On 17/01/2018 16:40, Martin Bjorklund wrote:
>>> Ladislav Lhotka  wrote:
>> 
>> 
>> 
> Ok.  I'm ok with keeping the inline case as it is.  However, I think
 I don't agree. The metadata annotation solves real issues.
>>> One issue with the annotation is that since the schema might be
>>> different in different datastores, it means that the client needs to
>>> read the annotation in all datastores, and then fetch the schemas.  So
>>> it is a bit more difficult to work with for a client.
>> I'm still not convinced that I really understand all the arguments here:
>> 
>> Using YLbis over YL seems to have obvious benefits to me, in that I
>> perceive that it gives a cleaner data model. 
> 
> It is worth noting that the current scheme amount document can be used either 
> with young library or Young Library BIS.
> 
>> But I also understand
>> Lou's concerns - although its not clear to me whether Lou's primary
>> concern is timing, or the fact that implementations are forced to use YLbis.
>> 
> 
> My concern is the delay required to reach consensus  on an unspecified 
> solution that has not been discussed and may contain unknown implications. 
> Keep in mind that where we are today has required compromises. Just because 
> we have one party that understands what they think they're going to write 
> doesn't mean that there will be changes as details are worked out, and as 
> consensus is obtained.
> 
> 
>> I also agree with Juergen that from an YLbis authors perspective YLbis
>> is quite close.  I believe that the YANG model itself has been agreed
>> (at the interim meeting in Nov/Dec), and hence really what is left is
>> just tidying/enhancing the descriptive text in the document.
>> 
>> I don't really understand the benefits of the metadata annotations. It
>> feels like this is going to be more hassle because a client will have to
>> query each datastore separately rather than getting the information in a
>> single operation.
>> 
>> A regular (without SM) NMDA NC/YANG server supports multiple datastores,
>> but that information is only exposed via one so them (i.e.
>> ).  So, in a server supporting inline SM, it seems quite
>> natural to me for the mounted schema information to also only be
>> available via the mounted . 
> 
> It also enables and implementation of the current SM document to support nmda 
> data stores under a inline Mount point.
> 
>> This seems to mirror the
>> standard NC/YANG+YL behavior, and also seems to naturally recurse if
>> required.
>> 
>> Hence, for me, I see the choice as:
>> 1) do we publish the existing model now (perhaps also mark the draft as
>> experimental) followed by an updated draft with the NMDA compatible module?
>> 2) do we publish both models in a single draft (e.g. with the existing
>> model in an appendix)?
>> 3) do we only publish a single version of the draft with an NMDA
>> compliant solution.
>> 
> 
> There are certainly a few variants possible, but the fundamental choice is to 
> go ahead with basically what passed last call or not.
> 
> Lou
> 
>> Thanks,
>> Rob
>> 
>> 
>> 
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

[Dean Bogdanovic]

I agree with points raised by Juergen and Kristian. Because of design changes I 
have stepped down as co-author of the draft.

> On Nov 2, 2017, at 4:50 AM, Mahesh Jethanandani  
> wrote:
> 
> Kristian,
> 
> I hear you. What I am providing is the rational for the current design. 
> 
> I would like to hear from others in the WG. We have been reviewing this draft 
> for the last couple of years, and we are now at the tail end of the LC. I 
> would really like to see this draft move forward, particularly since it is 
> not broken.
> 
> Thanks.
> 
>> On Nov 2, 2017, at 2:13 PM, Kristian Larsson  wrote:
>> 
>>> On Thu, Nov 02, 2017 at 06:13:04AM +0630, Mahesh Jethanandani wrote:
>>>   On Nov 1, 2017, at 5:52 PM, Juergen Schoenwaelder <
>>>   j.schoenwael...@jacobs-university.de> wrote:
>>> 
>>>   Mahesh,
>>> 
>>>   I think the question is why we need to have different match containers
>>>   for each possible feature set combination instead of having a single
>>>   match container with groups of leafs in it marked as features. This
>>>   would seem to cut down the size of the module and the tree diagram
>>>   significantly. I think this will also make clients simpler sicne they
>>>   do not have to select a certain container based on the feature set
>>>   announced. 
>>> 
>>> 
>>> The current design of match containers was chosen to allow platforms to 
>>> select
>>> one container that matched what the hardware supported from a l2, l3 and ipv
>>> {4,6} perspective.
>> 
>> Sure, but you are conflating the structure of the model with the
>> feature-wraps. Without changing the features of the model, we can
>> structure it in a different way where there is not a 1:1 mapping
>> between features and containers under the matches container.
>> 
>> 
>>> I would argue that even though the overall diagram is bigger
>>> with this design, once the platform selects the container of choice, the 
>>> tree
>>> and the configuration itself would be a little simpler/smaller.
>> 
>> I am arguing the opposite. It's really awkward to place the same
>> type of data, like IPv4 match conditions, under different paths
>> based on a feature.
>> 
>> If the system model had done the same we would have:
>> /system
>> /system-with-ntp
>> /system-with-ntp-and-radius
>> 
>> How do you augment in new leaves? While you are using groupings
>> which allows for a reuse of data across all these containers,
>> someone who is augmenting can't, since you can't augment a
>> container, only where it is used. Someone wishing to add a leaf
>> to the model needs to augment in three different locations to
>> support a new match condition for IPv4 (let's say some meta-data
>> attribute).
>> 
>> 
>>> Take the case where the desired selection is l2,-l3, ipv4 and ipv6. The 
>>> current
>>> tree looks like this:
>>> 
>>> 
>>>   ||  +--rw l2-l3-ipv4-ipv6-acl {l2-l3-ipv4-ipv6-acl}?
>>>   ||  |  +--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 dscp?   inet:dscp
>>>   ||  |  +--rw ecn?uint8
>>>   ||  |  +--rw length? uint16
>>>   ||  |  +--rw ttl?uint8
>>>   ||  |  +--rw protocol?   uint8
>>>   ||  |  +--rw source-port-range!
>>>   ||  |  |  +--rw lower-portinet:port-number
>>>   ||  |  |  +--rw upper-port?   inet:port-number
>>>   ||  |  |  +--rw operation?operator
>>>   ||  |  +--rw destination-port-range!
>>>   ||  |  |  +--rw lower-portinet:port-number
>>>   ||  |  |  +--rw upper-port?   inet:port-number
>>>   ||  |  |  +--rw operations?   operator
>>>   ||  |  +--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
>>>   ||  |  +--rw next-header?uint8
>>>   ||  |  +--rw destination-ipv6-network?   inet:ipv6-prefix
>>>   ||  |  +--rw source-ipv6-network?inet:ipv6-prefix
>>> 
>>>   ||  |  +--rw flow-label?
>>>   ||  |  inet:ipv6-flow-label
>>> 
>>> 
>>> 
>>> whereas, if the design went with one match container with each group of 
>>> leafs
>>> in their own 

Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07

[Dean Bogdanovic]

Kent,

As other work I have authored depends on it, I have read the document and think 
it's ready for publication. 

Dean

> On Oct 20, 2017, at 5:37 PM, Kent Watsen  wrote:
> 
> All,
> 
> This starts a two-week working group last call on
> draft-ietf-netmod-schema-mount-07.
> 
> The working group last call ends on November 3.
> Please send your comments to the netmod mailing list.
> 
> Positive comments, e.g., "I've reviewed this document 
> and believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
> 
> Could the authors, explicitly CC-ed on this email, 
> please also confirm one more time that they are 
> unaware of any IPR related to this draft.
> 
> Thank you,
> Netmod Chairs
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-yang-model-classification-06.txt

[Dean Bogdanovic]

Hi WG

I have updated the draft to 06 based on comments from Adrian. There are no 
outstanding issues with this draft that are known to me.


> On Apr 27, 2017, at 11:36 AM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the NETCONF Data Modeling Language of the IETF.
> 
>Title   : YANG Module Classification
>    Authors : Dean Bogdanovic
>  Benoit Claise
>  Carl Moberg
>   Filename: draft-ietf-netmod-yang-model-classification-06.txt
>   Pages   : 11
>   Date: 2017-04-27
> 
> Abstract:
>   The YANG data modeling language is currently being considered for a
>   wide variety of applications throughout the networking industry at
>   large.  Many standards-defining organizations (SDOs), open source
>   software projects, vendors and users are using YANG to develop and
>   publish YANG modules for a wide variety of applications.  At the same
>   time, there is currently no well-known terminology to categorize
>   various types of YANG modules.
> 
>   A consistent terminology would help with the categorization of YANG
>   modules, assist in the analysis of the YANG data modeling efforts in
>   the IETF and other organizations, and bring clarity to the YANG-
>   related discussions between the different groups.
> 
>   This document describes a set of concepts and associated terms to
>   support consistent classification of YANG modules.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-netmod-yang-model-classification-06
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-model-classification-06
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-model-classification-06
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Question on draft-ietf-netmod-yang-model-classification

[Dean Bogdanovic]

Adrian,

I just want to clarify one issue on BSS. Order management is part of the BSS 
and when external customer is ordering a new service, it talks to the order 
management system (either through a sales person or directly via self ordering 
application). The BSS then sends request to the provisioning system to create 
the service, essentially the service orchestrator. So I would argue that BSS is 
exposed to the external consumers of the service, but those systems are 
developed by internal teams.

I will update the draft according to some of your comments, but will leave this 
for the moment in the draft and we can have a discussion on this at the WG 
session or offline before or after.

Dean

> On Feb 14, 2017, at 11:23 AM, Adrian Farrel  wrote:
> 
> Hi Tianran,
> 
> Nice summary.
> 
> I think some of the confusion may be that 
> draft-ietf-netmod-yang-model-classification shows "Network Service YANG 
> Modules" on the interface between OSS/BSS and the network. But the "customer 
> service model" is at a different place in the hierarchy as shown in Figure 4 
> of draft-wu-opsawg-service-model-explained.
> 
> To attend to your specific questions:
>> 1. Whether it's necessary to further classify the "Network Service YANG
>> Module"?
> 
> I'm not particularly interested in doing that except so far as is necessary 
> to avoid conflict between the two I-Ds. In 
> draft-wu-opsawg-service-model-explained we introduced "customer service 
> module" and "service delivery module" because it seemed (to us) that there 
> were two different groups of people using the term "service model" to 
> describe very different modules.
> 
>> 2. What's the well definition of "Network Service YANG Module", "customer
>> service module", "service delivery module"?
> 
> Since draft-wu-opsawg-service-model-explained introduces the terms "customer 
> service module" and "service delivery module" I am going to say that I am 
> happy with the definitions in that document. I can say that "customer service 
> module" is used consistently with the L3SM and L2SM work and so it is 
> probably a stable definition. "Service delivery module" is a term we invented 
> to match the definition in draft-wu-opsawg-service-model-explained: I don't 
> think the term is used anywhere else, so maybe a better question is "is this 
> a useful/meaningful term?"
> 
> If the answer to Q1 is that draft-wu-opsawg-service-model-explained should 
> not try to resolve any overlap with 
> draft-ietf-netmod-yang-model-classification, then I think the definition of 
> "Network Service YANG Module" in draft-ietf-netmod-yang-model-classification 
> is fine (with the few tweaks Dean and I discussed on the list).
> 
>> 3. What's the well position of the above terms in the management 
>> architecture?
> 
> Ah, I like that question. But it makes me ask: where should I look for the 
> definitive, state-of-the art management architecture?
> 
> Thanks for continuing to drive this issue.
> 
> Adrian
> 
>> -Original Message-
>> From: Tianran Zhou [mailto:zhoutian...@huawei.com]
>> Sent: 14 February 2017 09:54
>> To: Carl Moberg (camoberg); adr...@olddog.co.uk
>> Cc: ops...@ietf.org; draft-ietf-netmod-yang-model-classificat...@ietf.org;
>> netmod@ietf.org; Dean Bogdanovic
>> Subject: RE: Question on draft-ietf-netmod-yang-model-classification
>> 
>> Hi,
>> 
>> Based on the discussion, here I try to clean up the confusion of the two 
>> I-Ds.
>> 
>> [draft-ietf-netmod-yang-model-classification] classifies the yang modules 
>> into
>> "Network Service YANG Module" and the "Network Element YANG Module".
>> And usually, it uses "service module" to imply the "Network Service YANG
>> Module", i.e., "Network" here only want to limit the scope to network related
>> modules. One example of "Network Service YANG Module" is [draft-ietf-l3sm-
>> l3vpn-service-model].
>> The authors do not want to further classify the service module into more 
>> layers,
>> until more operational practice comes.
>> 
>> [draft-wu-opsawg-service-model-explained] further classifies the service 
>> module
>> into "customer service module" and the "service delivery module". I think 
>> this is
>> based on the chair work on L3SM and L2SM WG and discussion with operators.
>> But the document think the "Network Service YANG Module" defined in [draft-
>> ietf-netmod-yang-model-classifi

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

[Dean Bogdanovic]

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
> 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
> 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  "" --> 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 .
> 
> 
> 
> 
> 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
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Question on draft-ietf-netmod-yang-model-classification

[Dean Bogdanovic]

Hi Adrian and Tianran,
> On Feb 14, 2017, at 5:23 AM, Adrian Farrel  wrote:
> 
> Hi Tianran,
> 
> Nice summary.
> 
> I think some of the confusion may be that 
> draft-ietf-netmod-yang-model-classification shows "Network Service YANG 
> Modules" on the interface between OSS/BSS and the network. But the "customer 
> service model" is at a different place in the hierarchy as shown in Figure 4 
> of draft-wu-opsawg-service-model-explained.

As Carl mentioned, there are can be multiple network service classifications, 
example technical and business models, but we decided to leave it as single 
model. In early versions of private draft 
(draft-bogdanovic-netmod-yang-model-classification-00)
there were 3 different services models,

business service model was connected to OSS/BSS and then there was network 
service model (technical) and service component models.

After discussions and from our experiences talking to operators we decided  to 
collapse that into single classification name.

> 
> To attend to your specific questions:
>> 1. Whether it's necessary to further classify the "Network Service YANG
>> Module"?
> 
> I'm not particularly interested in doing that except so far as is necessary 
> to avoid conflict between the two I-Ds. In 
> draft-wu-opsawg-service-model-explained we introduced "customer service 
> module" and "service delivery module" because it seemed (to us) that there 
> were two different groups of people using the term "service model" to 
> describe very different modules.
Authors of draft-ietf-netmod-yang-model-classification would be against, as we 
decided that way early in our work
> 
>> 2. What's the well definition of "Network Service YANG Module", "customer
>> service module", "service delivery module"?
> 
> Since draft-wu-opsawg-service-model-explained introduces the terms "customer 
> service module" and "service delivery module" I am going to say that I am 
> happy with the definitions in that document. I can say that "customer service 
> module" is used consistently with the L3SM and L2SM work and so it is 
> probably a stable definition. "Service delivery module" is a term we invented 
> to match the definition in draft-wu-opsawg-service-model-explained: I don't 
> think the term is used anywhere else, so maybe a better question is "is this 
> a useful/meaningful term?"
> 
> If the answer to Q1 is that draft-wu-opsawg-service-model-explained should 
> not try to resolve any overlap with 
> draft-ietf-netmod-yang-model-classification, then I think the definition of 
> "Network Service YANG Module" in draft-ietf-netmod-yang-model-classification 
> is fine (with the few tweaks Dean and I discussed on the list).

I agree with Adrian’s tweaks and will update the draft accordingly.
> 
>> 3. What's the well position of the above terms in the management 
>> architecture?
> 
> Ah, I like that question. But it makes me ask: where should I look for the 
> definitive, state-of-the art management architecture?

As few years ago, would be willing to put something forward on this topic, but 
today the management architecture is in such a flux, that Adrian’s question 
needs an answer first.

Dean

> 
> Thanks for continuing to drive this issue.
> 
> Adrian
> 
>> -Original Message-
>> From: Tianran Zhou [mailto:zhoutian...@huawei.com]
>> Sent: 14 February 2017 09:54
>> To: Carl Moberg (camoberg); adr...@olddog.co.uk
>> Cc: ops...@ietf.org; draft-ietf-netmod-yang-model-classificat...@ietf.org;
>> netmod@ietf.org; Dean Bogdanovic
>> Subject: RE: Question on draft-ietf-netmod-yang-model-classification
>> 
>> Hi,
>> 
>> Based on the discussion, here I try to clean up the confusion of the two 
>> I-Ds.
>> 
>> [draft-ietf-netmod-yang-model-classification] classifies the yang modules 
>> into
>> "Network Service YANG Module" and the "Network Element YANG Module".
>> And usually, it uses "service module" to imply the "Network Service YANG
>> Module", i.e., "Network" here only want to limit the scope to network related
>> modules. One example of "Network Service YANG Module" is [draft-ietf-l3sm-
>> l3vpn-service-model].
>> The authors do not want to further classify the service module into more 
>> layers,
>> until more operational practice comes.
>> 
>> [draft-wu-opsawg-service-model-explained] further classifies the service 
>> module
>> into "customer service module" and the "service delivery module". I think 
&g

Re: [netmod] [OPSAWG] Question on draft-ietf-netmod-yang-model-classification

[Dean Bogdanovic]

> On Feb 7, 2017, at 8:45 PM, Tianran Zhou  wrote:
> 
> Hi Dean,
> 
> 
>> -Original Message-
>> From: Dean Bogdanovic [mailto:ivand...@gmail.com]
>> Sent: Monday, January 30, 2017 7:53 PM
>> To: Tianran Zhou
>> Cc: adr...@olddog.co.uk; netmod@ietf.org; ops...@ietf.org;
>> draft-ietf-netmod-yang-model-classificat...@ietf.org
>> Subject: Re: [netmod] [OPSAWG] Question on
>> draft-ietf-netmod-yang-model-classification
>> 
>> 
>>> On Jan 23, 2017, at 9:32 AM, Tianran Zhou  wrote:
>>> 
>>> To add more comments:
>>> 
>>> On the L2SM meeting, several people (4 or more) believed the 3 service
>> delivery model examples ([I-D.dhjain-bess-bgp-l3vpn-yang],
>> [I-D.ietf-bess-l2vpn-yang] and [I-D.ietf-bess-evpn-yang]) are actually
>> device models.
>>> 
>>> I think both of the two I-Ds
>> ([draft-ietf-netmod-yang-model-classification] and
>> [draft-wu-opsawg-service-model-explained]) can check if those YANG models
>> are device models or service models.
>> 
>> The idea is that the classification drafts will provide guidelines for the
>> authors to do their own classification. As mentioned in my previous email,
>> the only people who will be able to do the right classification, are the
>> module authors.
> 
> But you list some examples in each category. If those example modules are 
> actually not fit in, I think it will mislead and confuse the readers.

Good point.
> 
>> 
>> Please see I’m using distinction between module and model. Model can consist
>> of multiple modules and in models you can get classification ambiguity.
>> Modules are much more clear to classify.
> 
> Do you mean usually it's hard to classify the "model"? Because it may contain 
> many "modules" for different use.

Yes.

Dean

> 
>> Dean
>> 
>>> 
>>> Regards,
>>> Tianran
>>> 
>>>> -Original Message-
>>>> From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Adrian
>>>> Farrel
>>>> Sent: Friday, January 20, 2017 12:25 AM
>>>> To: netmod@ietf.org
>>>> Cc: ops...@ietf.org;
>>>> draft-ietf-netmod-yang-model-classificat...@ietf.org
>>>> Subject: [OPSAWG] Question on
>>>> draft-ietf-netmod-yang-model-classification
>>>> 
>>>> Hi,
>>>> 
>>>> We've been trying to ensure that
>>>> draft-wu-opsawg-service-model-explained
>>>> is consistent with the latest version of
>>>> draft-ietf-netmod-yang-model-classification. In discussions with
>>>> Tianran a question has come up.
>>>> 
>>>> In section 2 you have a nice definition of Network Service YANG
>>>> Modules and this definition maps nicely to our definition of "service
>>>> delivery models".
>>>> Furthermore, your figure 1 shows Network Service YANG Modules on the
>>>> interface between OSS/BSS and the various network services.
>>>> 
>>>> We have further defined "customer service models" at a higher layer still.
>>>> That is, on the interface to the customer. This (of course?) assumes
>>>> that the OSS/BSS is not customer code :-)
>>>> 
>>>> However, your discussion of Network Service YANG Modules in section
>>>> 2.1 seems slightly at odds, although this may be just ambiguity.
>>>> 
>>>> For example, when you say, "Network Service YANG Modules describe the
>>>> characteristics of a service, as agreed upon with consumers of that
>> service,"
>>>> this is not the same as, "This model is used in the discussion
>>>> between a customer and a service provide to describe the characteristics
>> of a service."
>>>> That is, the former case could be arrived at after processing based
>>>> on the latter case - processing that we have called "service
>>>> orchestration" but might (of course) be what leads to the operator poking
>> the OSS/BSS.
>>>> 
>>>> This might all be fine and good, but later in the same section you
>>>> say "Network Service YANG Modules define service models to be
>>>> consumed by external systems.
>>>> These modules are commonly designed, developed and deployed by
>>>> network infrastructure teams." And there you introduce two terms that
>>>> are previously undefined and only server to add ambiguity. Specifically
>> "external to what?&

Re: [netmod] [OPSAWG] Question on draft-ietf-netmod-yang-model-classification

[Dean Bogdanovic]

> On Jan 23, 2017, at 9:32 AM, Tianran Zhou  wrote:
> 
> To add more comments: 
> 
> On the L2SM meeting, several people (4 or more) believed the 3 service 
> delivery model examples ([I-D.dhjain-bess-bgp-l3vpn-yang], 
> [I-D.ietf-bess-l2vpn-yang] and [I-D.ietf-bess-evpn-yang]) are actually device 
> models.
> 
> I think both of the two I-Ds ([draft-ietf-netmod-yang-model-classification] 
> and [draft-wu-opsawg-service-model-explained]) can check if those YANG models 
> are device models or service models.

The idea is that the classification drafts will provide guidelines for the 
authors to do their own classification. As mentioned in my previous email, the 
only people who will be able to do the right classification, are the module 
authors.

Please see I’m using distinction between module and model. Model can consist of 
multiple modules and in models you can get classification ambiguity. Modules 
are much more clear to classify.

Dean

> 
> Regards,
> Tianran
> 
>> -Original Message-
>> From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Adrian Farrel
>> Sent: Friday, January 20, 2017 12:25 AM
>> To: netmod@ietf.org
>> Cc: ops...@ietf.org;
>> draft-ietf-netmod-yang-model-classificat...@ietf.org
>> Subject: [OPSAWG] Question on draft-ietf-netmod-yang-model-classification
>> 
>> Hi,
>> 
>> We've been trying to ensure that draft-wu-opsawg-service-model-explained
>> is consistent with the latest version of
>> draft-ietf-netmod-yang-model-classification. In discussions with Tianran
>> a question has come up.
>> 
>> In section 2 you have a nice definition of Network Service YANG Modules
>> and this definition maps nicely to our definition of "service delivery
>> models".
>> Furthermore, your figure 1 shows Network Service YANG Modules on the
>> interface between OSS/BSS and the various network services.
>> 
>> We have further defined "customer service models" at a higher layer still.
>> That is, on the interface to the customer. This (of course?) assumes that
>> the OSS/BSS is not customer code :-)
>> 
>> However, your discussion of Network Service YANG Modules in section 2.1
>> seems slightly at odds, although this may be just ambiguity.
>> 
>> For example, when you say, "Network Service YANG Modules describe the
>> characteristics of a service, as agreed upon with consumers of that service,"
>> this is not the same as, "This model is used in the discussion between a
>> customer and a service provide to describe the characteristics of a service."
>> That is, the former case could be arrived at after processing based on the
>> latter case - processing that we have called "service orchestration" but
>> might (of course) be what leads to the operator poking the OSS/BSS.
>> 
>> This might all be fine and good, but later in the same section you say 
>> "Network
>> Service YANG Modules define service models to be consumed by external
>> systems.
>> These modules are commonly designed, developed and deployed by network
>> infrastructure teams." And there you introduce two terms that are previously
>> undefined and only server to add ambiguity. Specifically "external to what?"
>> I could make and argument that the OSS is developed and deployed by network
>> infrastructure teams, ad also that the OSS is external to the network itself.
>> 
>> And, in between these two quoted pieces of text, you have...
>> 
>>   As an example, the Network Service YANG Module defined in
>>   [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract
>>   model for Layer 3 IP VPN service configuration.
>> 
>> Per my other email, this reference needs to be fixed. But I struggle to
>> see the L3SM module as consistent with your figure. It may or may not be
>> consistent with your text dependent on the interpretation.
>> 
>> In draft-wu-opsawg-service-model-explained Figure 4 we have tried to show
>> how we (the authors) think L3SM fits into your classification. Here we place
>> L3SM further up the layering stack.
>> 
>> [Apologies for not spotting this sooner. The citation
>> "YANG-Data-Model-for-L3VPN-service-delivery" includes the term "service
>> delivery" which I took to imply a different module.]
>> 
>> Thanks,
>> Adrian
>> 
>> ___
>> OPSAWG mailing list
>> ops...@ietf.org
>> https://www.ietf.org/mailman/listinfo/opsawg
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Question on draft-ietf-netmod-yang-model-classification

[Dean Bogdanovic]

> On Jan 19, 2017, at 4:25 PM, Adrian Farrel  wrote:
> 
> Hi,
> 
> We've been trying to ensure that draft-wu-opsawg-service-model-explained is
> consistent with the latest version of
> draft-ietf-netmod-yang-model-classification. In discussions with Tianran a
> question has come up.
> 
> In section 2 you have a nice definition of Network Service YANG Modules and 
> this
> definition maps nicely to our definition of "service delivery models".
> Furthermore, your figure 1 shows Network Service YANG Modules on the interface
> between OSS/BSS and the various network services.
> 
> We have further defined "customer service models" at a higher layer still. 
> That
> is, on the interface to the customer. This (of course?) assumes that the 
> OSS/BSS
> is not customer code :-)
> 
> However, your discussion of Network Service YANG Modules in section 2.1 seems
> slightly at odds, although this may be just ambiguity.
> 
> For example, when you say, "Network Service YANG Modules describe the
> characteristics of a service, as agreed upon with consumers of that service,"
> this is not the same as, "This model is used in the discussion between a
> customer and a service provide to describe the characteristics of a service."
> That is, the former case could be arrived at after processing based on the
> latter case - processing that we have called "service orchestration" but might
> (of course) be what leads to the operator poking the OSS/BSS.

Adrian, I can see the ambiguity. The point of service module is to be consumed 
by the customer and there can be some modifications of the service module to 
adapt to the customer specifics.
> 
> This might all be fine and good, but later in the same section you say 
> "Network
> Service YANG Modules define service models to be consumed by external systems.
> These modules are commonly designed, developed and deployed by network
> infrastructure teams." And there you introduce two terms that are previously
> undefined and only server to add ambiguity. Specifically "external to what?" I
> could make and argument that the OSS is developed and deployed by network
> infrastructure teams, ad also that the OSS is external to the network itself.

Agree that external systems are not defined and this text has to be clarified. 
The external systems can be OSS and BSS.
> 
> And, in between these two quoted pieces of text, you have...
> 
>   As an example, the Network Service YANG Module defined in
>   [YANG-Data-Model-for-L3VPN-service-delivery] provides an abstract
>   model for Layer 3 IP VPN service configuration.

My question is where do you see the L3SM model 

above or below OSS?

Because there are some nuances in the service module, but at the end we decided 
not to do sub classification

one is the business and one technical service.

When i read the YANG-Data-Model-for-L3VPN-service-delivery, it looked to me 
much more like a technical model, then the business model, as didn’t see SLA 
definitions to track the business parameters of the service use.

> 
> Per my other email, this reference needs to be fixed. But I struggle to see 
> the
> L3SM module as consistent with your figure. It may or may not be consistent 
> with
> your text dependent on the interpretation.

Sure, we can fix that reference, but the authors of L3SM module should do their 
own module classification, as they are the only ones that know the intent of 
the module.

> 
> In draft-wu-opsawg-service-model-explained Figure 4 we have tried to show how 
> we
> (the authors) think L3SM fits into your classification. Here we place L3SM
> further up the layering stack.
> 
> [Apologies for not spotting this sooner. The citation
> "YANG-Data-Model-for-L3VPN-service-delivery" includes the term "service
> delivery" which I took to imply a different module.]
> 

No worries and sorry for late reply

Dean

> Thanks,
> Adrian
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Applied data store clarification in draft-nmdsdt-netmod-revised-datastores-00

[Dean Bogdanovic]

> On Dec 15, 2016, at 10:24 AM, Martin Bjorklund  wrote:
> 
> Hi,
> 
> Dean Bogdanovic mailto:ivand...@gmail.com>> wrote:
>> Authors,
>> 
>> Need some clarification about applied data store
>> 
>> In the draft, applied data store can contain data from 
>> 
>> This data can come from several sources; from , from dynamic
>> configuration protocols (e.g., DHCP), or from control-plane datastore.
>> 
>> The control-plane stores are not well clarified in my opinion
>> 
>> The model foresees control-plane datastores that are by definition
>>   not part of the persistent configuration of a device.  In some
>>   contexts, these have been termed ephemeral datastores since the
>>   information is ephemeral, i.e., lost upon reboot.  The control-plane
>>   datastores interact with the rest of the system through the 
>>   or  datastores, depending on the type of data they
>>   contain.  Note that the ephemeral datastore discussed in I2RS
>>   documents maps to a control-plane datastore in the revised datastore
>>   model described here.
>> 
>> The other issue I have is with that control-plane data stores are
>> shown connected to applied and operational-state. Which control plane
>> data stores are directly influencing operational-state?
> 
> We wanted to allow for other to-be-defined data stores by showing
> where they can fit into the architecture.  When/if such a data store
> is defined, it can relate to this architecture and explain exactly how
> it fits in and how it affects applied config and/or operational state.
> 
>> Also, in the diagram control-plane protocols are connected only to
>> operational-state data store. But isn’t the previous state exchanged
>> via control plane protocols taken into account when validating data
>> that is copied into applied data store?
> 
> When you say "data that is copied into applied", are you referring to
> the arrow between intended and applied?

Yes, correct
> 
> The answer is that the arrows show data flow.  The mechanism that
> copies data from intended to applied will surely have to check
> operational state and maybe physical resources in roder to do its job.

But from the same diagram, it states that control protocols are not impacting 
applied data store, except the operational state. This is something I have to 
wrap my mind around it, as when the applied state is computed, it is taking 
into account data exchanged via control protocols.

Dean


> 
> 
> /martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Applied data store clarification in draft-nmdsdt-netmod-revised-datastores-00

[Dean Bogdanovic]

Authors,

Need some clarification about applied data store

In the draft, applied data store can contain data from 

This data can come from several sources; from  , from dynamic 
configuration protocols (e.g., DHCP), or from control-plane datastore.

The control-plane stores are not well clarified in my opinion

 The model foresees control-plane datastores that are by definition
   not part of the persistent configuration of a device.  In some
   contexts, these have been termed ephemeral datastores since the
   information is ephemeral, i.e., lost upon reboot.  The control-plane
   datastores interact with the rest of the system through the 
   or  datastores, depending on the type of data they
   contain.  Note that the ephemeral datastore discussed in I2RS
   documents maps to a control-plane datastore in the revised datastore
   model described here.

The other issue I have is with that control-plane data stores are shown 
connected to applied and operational-state. Which control plane data stores are 
directly influencing operational-state? 

Also, in the diagram control-plane protocols are connected only to 
operational-state data store. But isn’t the previous state exchanged via 
control plane protocols taken into account when validating data that is copied 
into applied data store?

Thx

Dean___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Regarding IPR on draft-ietf-netmod-yang-model-classification

[Dean Bogdanovic]

Chairs,

No, I'm not aware of any IPR that applies to this draft

Dean

> On Nov 28, 2016, at 11:48 PM, Lou Berger  wrote:
> 
> 
> Authors, Contributors, WG,
> 
> As part of the preparation for WG Last Call
> 
> Are you aware of any IPR that applies to drafts identified above?
> 
> [NOTE: Adoption poll will be on the first draft, but authors have agreed
> that -01 WG revision will be based on both.]
> 
> Please state either:
> 
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3979, 4879, 3669 and 5378 for more details)?
> 
> If yes to the above, please state either:
> 
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think
> appropriate.
> 
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
> 
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
> 
> Thank you,
> NETMOD WG Chairs
> 
> PS Please include all listed in the headers of this message in your
> response.
> 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Dean Bogdanovic]

As draft author, the model was designed to be easily augmented for matches and 
actions, so that each vendor and user can adapt it to their needs.

Dean

> On Nov 23, 2016, at 6:05 PM, Andy Bierman  wrote:
> 
> Hi,
> 
> I have a general comment, related to Benoit's request to get YANG modules 
> done.
> 
> Augment is your friend.  Use it.
> YANG 1.1 even allows conditionally mandatory nodes to be added, so there are
> no excuses for not publishing base modules that can be augmented later.
> 
> IMO, adding new features in WGLC should not even be considered.
> 
> 
> Andy
> 
> 
> On Wed, Nov 23, 2016 at 2:55 PM, Acee Lindem (acee)  <mailto:a...@cisco.com>> wrote:
> If you could just point out the general features you are using in your 
> configs that are not present in the base model. I know you mentioned TCP 
> options matching. With respect to the augmentations, they don’t have to be 
> vendor specific. Some advanced ACL functions such as conditional ACLs could 
> be provided in standard model augmentations in future modules. 
> 
> Thanks,
> Acee 
> 
> From: David Bannister mailto:d...@netflix.com>>
> Date: Wednesday, November 23, 2016 at 1:54 PM
> To: Acee Lindem mailto:a...@cisco.com>>
> Cc: Kent Watsen mailto:kwat...@juniper.net>>, Eliot 
> Lear mailto:l...@cisco.com>>, Dean Bogdanovic 
> mailto:ivand...@gmail.com>>, "netmod@ietf.org 
> <mailto:netmod@ietf.org>" mailto:netmod@ietf.org>>
> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
> Oct 27, 2016)
> 
> I'm open to the idea given ample time.
> 
> On Wed, Nov 23, 2016 at 12:53 PM, Acee Lindem (acee)  <mailto:a...@cisco.com>> wrote:
> Hi David, 
> 
> From: David Bannister mailto:d...@netflix.com>>
> Date: Wednesday, November 23, 2016 at 12:28 PM
> To: Kent Watsen mailto:kwat...@juniper.net>>
> Cc: Eliot Lear mailto:l...@cisco.com>>, Acee Lindem 
> mailto:a...@cisco.com>>, Dean Bogdanovic  <mailto:ivand...@gmail.com>>, "netmod@ietf.org <mailto:netmod@ietf.org>" 
> mailto:netmod@ietf.org>>
> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
> Oct 27, 2016)
> 
> Here are my issues with the ACL draft as it stands today from a high level, 
> vs. calling out every missing field. 
> 
> Although I’m not an author of this YANG model, I’m the author of others and I 
> can say from experience that it would be infinitely more productive for you 
> to list the specific fields and corresponding use cases as opposed to a 
> subjective high-level critique. That way, these can be incorporated or, at 
> least, we can have the discussion as whether or not they belong in the base 
> model. 
> 
> Thanks,
> Acee 
> 
> 
> ___
> 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
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Dean Bogdanovic]

I have something that might delay WGLC, but found out an optimization which 
would help in the future

In ietf-packet-fields.yang, example below

grouping acl-ipv4-header-fields {
   description
 "Fields in IPv4 header.";
   leaf destination-ipv4-network {
 type inet:ipv4-prefix;
 description
   "Destination IPv4 address prefix.";
   }
   leaf source-ipv4-network {
 type inet:ipv4-prefix;
 description
   "Source IPv4 address prefix.";
   }
 }

Instead of using "leaf" for "destination-ipv4-network" and 
"source-ipv4-network", "leaf-list" reduces the number of terms/ace needed.

If we would agree with this change, then would propose one more 

for mac-addresses, having the mask under the address itself look better in the 
data itself:

  
01:01:01:00:00:00
ff:ff:ff:00:00:00
  

  Or create a new type 'mac-address-prefix'.

  This allows having matching multiple destinations to 1 source, or multiple 
sources to 1 destination, if they cannot be easily combined into 1 entry.

  
01:01:01:00:00:00
ff:ff:ff:00:00:00
  
  
01:04:01:00:00:00
ff:ff:ff:00:00:00
  
  

  
> On Nov 14, 2016, at 7:35 AM, Dean Bogdanovic  wrote:
> 
> Kent,
> 
> Thank you for the answer
>> On Nov 13, 2016, at 1:20 PM, Kent Watsen > <mailto:kwat...@juniper.net>> wrote:
>> 
>> Hi Dean,
>>  
>> > Don’t understand your question. What is the difference between system and 
>> > user generated acls?
>>  
>> User-generated would be, for instance, configured via NETCONF or RESTCONF, 
>> whereas system-generated would be ACLs that get created by default.  For 
>> example, RFC 7223 has the top-level /interfaces-state to support 
>> system-generated interfaces (e.g., lo) so, when running `shows interfaces`, 
>> the result includes both configured and system-generated interfaces.   Makes 
>> sense?
> 
> I understand now what you meant. Where I can see for the interfaces the use 
> case you describe (for loopback and physical interfaces), for ACLs have much 
> harder time to find an example use case where a system would generate an ACL. 
> Maybe for a highly secure system would generate an ACL to deny all traffic to 
> and from, except to access it via console when it comes up. Can you come with 
> some other use cases? If we can find viable use cases, then yes, would say 
> that reporting opstate for system generated ACLs is useful.
> 
> Dean
> 
>>  
>> Thanks,
>> Kent
>>  
>> From: Dean Bogdanovic mailto:ivand...@gmail.com>>
>> Date: Friday, November 11, 2016 at 3:45 PM
>> To: Kent Watsen mailto:kwat...@juniper.net>>
>> Cc: "netmod@ietf.org <mailto:netmod@ietf.org>" > <mailto:netmod@ietf.org>>
>> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
>> Oct 27, 2016)
>>  
>>  
>>> On Oct 29, 2016, at 4:01 AM, Kent Watsen >> <mailto:kwat...@juniper.net>> wrote:
>>>  
>>> The last call period for this draft has ended.   Thank you to all that 
>>> responded.  Given the responses received, my co-chair and I believe that 
>>> the draft is ready to move forward.  I will begin the shepherd write-up 
>>> shortly.
>>> In parallel, prompted by a conversation I had this morning, I’m wondering 
>>> about the YANG module’s use of the config false nodes ‘acl-oper-data’ and 
>>> ‘ace-oper-data’.  In particular, are the lifetimes of these nodes always 
>>> the same as the configured nodes? 
>>  
>> Yes, they are. When the nodes are created, they are don’t have to be 
>> attached to an another object, like interface or RIB, etc, but they get 
>> operational state. Once attached, (to continue with the example) operational 
>> status of counters is changing. When detached from the interface, the last 
>> know counter is kept, until the ace is deleted. Same is for acl-oper-data.
>>  
>>> - is there any need to support reporting opstate for system-generated acts?
>>  
>> Don’t understand your question. What is the difference between system and 
>> user generated acls?
>>  
>> Dean
>>  
>>>  
>>> Thanks,
>>> Kent (as shepherd)
>>>  
>>>  
>>> From: netmod mailto:netmod-boun...@ietf.org>> on 
>>> behalf of Kent Watsen mailto:kwat...@juniper.net>>
>>> Date: Thursday, October 13, 2016 at 5:05 PM
>>> To: "netmod@ietf.org <mailto:netmod@ietf.org>" >> <mailto:netmod@ietf.org>>
>>> Subject: [netmod] WG Last Call for draft-ietf-netmod-acl-

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Dean Bogdanovic]

Kent,

Thank you for the answer
> On Nov 13, 2016, at 1:20 PM, Kent Watsen  wrote:
> 
> Hi Dean,
>  
> > Don’t understand your question. What is the difference between system and 
> > user generated acls?
>  
> User-generated would be, for instance, configured via NETCONF or RESTCONF, 
> whereas system-generated would be ACLs that get created by default.  For 
> example, RFC 7223 has the top-level /interfaces-state to support 
> system-generated interfaces (e.g., lo) so, when running `shows interfaces`, 
> the result includes both configured and system-generated interfaces.   Makes 
> sense?

I understand now what you meant. Where I can see for the interfaces the use 
case you describe (for loopback and physical interfaces), for ACLs have much 
harder time to find an example use case where a system would generate an ACL. 
Maybe for a highly secure system would generate an ACL to deny all traffic to 
and from, except to access it via console when it comes up. Can you come with 
some other use cases? If we can find viable use cases, then yes, would say that 
reporting opstate for system generated ACLs is useful.

Dean

>  
> Thanks,
> Kent
>  
> From: Dean Bogdanovic 
> Date: Friday, November 11, 2016 at 3:45 PM
> To: Kent Watsen 
> Cc: "netmod@ietf.org" 
> Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until 
> Oct 27, 2016)
>  
>  
>> On Oct 29, 2016, at 4:01 AM, Kent Watsen > <mailto:kwat...@juniper.net>> wrote:
>>  
>> The last call period for this draft has ended.   Thank you to all that 
>> responded.  Given the responses received, my co-chair and I believe that the 
>> draft is ready to move forward.  I will begin the shepherd write-up shortly.
>> In parallel, prompted by a conversation I had this morning, I’m wondering 
>> about the YANG module’s use of the config false nodes ‘acl-oper-data’ and 
>> ‘ace-oper-data’.  In particular, are the lifetimes of these nodes always the 
>> same as the configured nodes? 
>  
> Yes, they are. When the nodes are created, they are don’t have to be attached 
> to an another object, like interface or RIB, etc, but they get operational 
> state. Once attached, (to continue with the example) operational status of 
> counters is changing. When detached from the interface, the last know counter 
> is kept, until the ace is deleted. Same is for acl-oper-data.
>  
>> - is there any need to support reporting opstate for system-generated acts?
>  
> Don’t understand your question. What is the difference between system and 
> user generated acls?
>  
> Dean
>  
>>  
>> Thanks,
>> Kent (as shepherd)
>>  
>>  
>> From: netmod mailto:netmod-boun...@ietf.org>> on 
>> behalf of Kent Watsen mailto:kwat...@juniper.net>>
>> Date: Thursday, October 13, 2016 at 5:05 PM
>> To: "netmod@ietf.org <mailto:netmod@ietf.org>" > <mailto:netmod@ietf.org>>
>> Subject: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 
>> 27, 2016)
>>  
>>  
>> This is a notice to start a two-week NETMOD WG last call for the document:
>>  
>>Network Access Control List (ACL) YANG Data Model
>>https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 
>> <https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09>
>>  
>> Please indicate your support or concerns by Thursday, October 27, 2016.
>>  
>> We are particularly interested in statements of the form:
>>   * I have reviewed draft-ietf-netmod-acl-model-09 and found no issues.
>>   * I have reviewed draft-ietf-netmod-acl-model-09 and found the following 
>> issues: ...
>>  
>> As well as:
>>  * I have implemented the data model in draft-ietf-netmod-acl-model-09.
>>   * I am implementing the data model in draft-ietf-netmod-acl-model-09.
>>   * I am considering to implement the data model in 
>> draft-ietf-netmod-acl-model-09.
>>   * I am not considering to implement the data model in 
>> draft-ietf-netmod-acl-model-09.
>>  
>> Thank you,
>> NETMOD WG Chairs
>>  
>>  
>> ___
>> 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
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-08 (until Oct 5, 2016)

[Dean Bogdanovic]

Adrian,

Sorry for not replying earlier. Your email fell through the cracks. 

> On Sep 21, 2016, at 5:55 PM, Adrian Pan  wrote:
> 
> I have reviewed draft-ietf-netmod-acl-model-08 and I am considering to 
> implement the data model in the draft, while I found below issue:
> - Operator is able to configure the matches of ace different from the 
> acl-type, i.e ace configured with ipv6 matches while the “acl-type” is 
> configured as ipv4 in the acl, this is not aligned with the model design 
> intention.

The acl-type provides implicit specification of the match criteria. Authors 
wanted to enable support for mixed type acl (example mac and ip) in the same 
list. And let the vendors determine based on their platform and what is 
supported how to implement the model.

Dean

>  
> Thanks
> Adrian
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
> Sent: Wednesday, September 21, 2016 4:46 AM
> To: netmod@ietf.org
> Subject: [netmod] WG Last Call for draft-ietf-netmod-acl-model-08 (until Oct 
> 5, 2016)
>  
>  
> This is a notice to start a two-week NETMOD WG last call for the document:
>  
>Network Access Control List (ACL) YANG Data Model
>https://tools.ietf.org/html/draft-ietf-netmod-acl-model-08 
> 
>  
> Please indicate your support or concerns by Wednesday, October 5, 2016.
>  
> We are particularly interested in statements of the form:
>   * I have reviewed draft-ietf-netmod-acl-model-08 and found no issues.
>   * I have reviewed draft-ietf-netmod-acl-model-08 and found the following 
> issues: ...
>  
> As well as:
>  * I have implemented the data model in draft-ietf-netmod-acl-model-08.
>   * I am implementing the data model in draft-ietf-netmod-acl-model-08.
>   * I am considering to implement the data model in 
> draft-ietf-netmod-acl-model-08.
>   * I am not considering to implement the data model in 
> draft-ietf-netmod-acl-model-08.
>  
> Thank you,
> NETMOD WG Chairs
>  
>  
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Dean Bogdanovic]

> On Oct 29, 2016, at 4:01 AM, Kent Watsen  wrote:
> 
> The last call period for this draft has ended.   Thank you to all that 
> responded.  Given the responses received, my co-chair and I believe that the 
> draft is ready to move forward.  I will begin the shepherd write-up shortly.
> In parallel, prompted by a conversation I had this morning, I’m wondering 
> about the YANG module’s use of the config false nodes ‘acl-oper-data’ and 
> ‘ace-oper-data’.  In particular, are the lifetimes of these nodes always the 
> same as the configured nodes? 

Yes, they are. When the nodes are created, they are don’t have to be attached 
to an another object, like interface or RIB, etc, but they get operational 
state. Once attached, (to continue with the example) operational status of 
counters is changing. When detached from the interface, the last know counter 
is kept, until the ace is deleted. Same is for acl-oper-data.

> - is there any need to support reporting opstate for system-generated acts?

Don’t understand your question. What is the difference between system and user 
generated acls?

Dean

> 
> Thanks,
> Kent (as shepherd)
>  
>  
> From: netmod mailto:netmod-boun...@ietf.org>> on 
> behalf of Kent Watsen mailto:kwat...@juniper.net>>
> Date: Thursday, October 13, 2016 at 5:05 PM
> To: "netmod@ietf.org "  >
> Subject: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 
> 27, 2016)
>  
>  
> This is a notice to start a two-week NETMOD WG last call for the document:
>  
>Network Access Control List (ACL) YANG Data Model
>https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 
> 
>  
> Please indicate your support or concerns by Thursday, October 27, 2016.
>  
> We are particularly interested in statements of the form:
>   * I have reviewed draft-ietf-netmod-acl-model-09 and found no issues.
>   * I have reviewed draft-ietf-netmod-acl-model-09 and found the following 
> issues: ...
>  
> As well as:
>  * I have implemented the data model in draft-ietf-netmod-acl-model-09.
>   * I am implementing the data model in draft-ietf-netmod-acl-model-09.
>   * I am considering to implement the data model in 
> draft-ietf-netmod-acl-model-09.
>   * I am not considering to implement the data model in 
> draft-ietf-netmod-acl-model-09.
>  
> Thank you,
> NETMOD WG Chairs
>  
>  
> ___
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 8022 on A YANG Data Model for Routing Management

[Dean Bogdanovic]

Congrats Lada!

This was a great marathon to pull of with Acee coming down the road and helping 
out.

Again, congrats to both of you

Dean

> On Nov 9, 2016, at 11:18 PM, rfc-edi...@rfc-editor.org wrote:
> 
> A new Request for Comments is now available in online RFC libraries.
> 
> 
>RFC 8022
> 
>Title:  A YANG Data Model for 
>Routing Management 
>Author: L. Lhotka, A. Lindem
>Status: Standards Track
>Stream: IETF
>Date:   November 2016
>Mailbox:lho...@nic.cz, 
>a...@cisco.com
>Pages:  64
>Characters: 115083
>Updates/Obsoletes/SeeAlso:   None
> 
>I-D Tag:draft-ietf-netmod-routing-cfg-25.txt
> 
>URL:https://www.rfc-editor.org/info/rfc8022
> 
>DOI:http://dx.doi.org/10.17487/RFC8022
> 
> This document contains a specification of three YANG modules and one
> submodule.  Together they form the core routing data model that
> serves as a framework for configuring and managing a routing
> subsystem.  It is expected that these modules will be augmented by
> additional YANG modules defining data models for control-plane
> protocols, route filters, and other functions.  The core routing data
> model provides common building blocks for such extensions -- routes,
> Routing Information Bases (RIBs), and control-plane protocols.
> 
> This document is a product of the NETCONF Data Modeling Language Working 
> Group of the IETF.
> 
> This is now a Proposed Standard.
> 
> STANDARDS TRACK: This document specifies an Internet Standards Track
> protocol for the Internet community, and requests discussion and suggestions
> for improvements.  Please refer to the current edition of the Official
> Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
> standardization state and status of this protocol.  Distribution of this 
> memo is unlimited.
> 
> This announcement is sent to the IETF-Announce and rfc-dist lists.
> To subscribe or unsubscribe, see
>  https://www.ietf.org/mailman/listinfo/ietf-announce
>  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
> 
> For searching the RFC series, see https://www.rfc-editor.org/search
> For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> 
> The RFC Editor Team
> Association Management Solutions, LLC
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Dean Bogdanovic]

Paul,

I apologize. Volta Networks implemented the draft.

Dean

> On Oct 27, 2016, at 9:52 AM, Doolan, Paul (Coriant - US/Irving) 
>  wrote:
> 
> Not sure if there's explicit IETF rules on this and I know we're all 
> individual contributors but, as a courtesy, will people claiming 
> implementations and using a non company email domain (e.g @gmail.com 
> <http://gmail.com/>)  indicate which organization it is that's done the 
> implementing. 
> 
> thanks,
> pd
> 
> On Oct 27, 2016, at 9:13 AM, Dean Bogdanovic  <mailto:ivand...@gmail.com>>
>  wrote:
> 
>> I support this draft publication and we have implemented this draft, so 
>> there is another vendor implementation.
>> 
>> Dean
>> 
>>> On Oct 14, 2016, at 11:13 PM, Mahesh Jethanandani >> <mailto:mjethanand...@gmail.com>> wrote:
>>> 
>>> I have reviewed this draft and support its publication. We have implemented 
>>> the model.
>>> 
>>> Mahesh Jethanandani
>>> mjethanand...@gmail.com <mailto:mjethanand...@gmail.com>
>>> 
>>> On Oct 13, 2016, at 5:05 PM, Kent Watsen >> <mailto:kwat...@juniper.net>> wrote:
>>> 
>>>>  
>>>> This is a notice to start a two-week NETMOD WG last call for the document:
>>>>  
>>>>Network Access Control List (ACL) YANG Data Model
>>>>https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 
>>>> <https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09>
>>>>  
>>>> Please indicate your support or concerns by Thursday, October 27, 2016.
>>>>  
>>>> We are particularly interested in statements of the form:
>>>>   * I have reviewed draft-ietf-netmod-acl-model-09 and found no issues.
>>>>   * I have reviewed draft-ietf-netmod-acl-model-09 and found the following 
>>>> issues: ...
>>>>  
>>>> As well as:
>>>>  * I have implemented the data model in draft-ietf-netmod-acl-model-09.
>>>>   * I am implementing the data model in draft-ietf-netmod-acl-model-09.
>>>>   * I am considering to implement the data model in 
>>>> draft-ietf-netmod-acl-model-09.
>>>>   * I am not considering to implement the data model in 
>>>> draft-ietf-netmod-acl-model-09.
>>>>  
>>>> Thank you,
>>>> NETMOD WG Chairs
>>>>  
>>>>  
>>>> ___
>>>> 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 
>>> <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

Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-09 (until Oct 27, 2016)

[Dean Bogdanovic]

I support this draft publication and we have implemented this draft, so there 
is another vendor implementation.

Dean

> On Oct 14, 2016, at 11:13 PM, Mahesh Jethanandani  
> wrote:
> 
> I have reviewed this draft and support its publication. We have implemented 
> the model.
> 
> Mahesh Jethanandani
> mjethanand...@gmail.com 
> 
> On Oct 13, 2016, at 5:05 PM, Kent Watsen  > wrote:
> 
>>  
>> This is a notice to start a two-week NETMOD WG last call for the document:
>>  
>>Network Access Control List (ACL) YANG Data Model
>>https://tools.ietf.org/html/draft-ietf-netmod-acl-model-09 
>> 
>>  
>> Please indicate your support or concerns by Thursday, October 27, 2016.
>>  
>> We are particularly interested in statements of the form:
>>   * I have reviewed draft-ietf-netmod-acl-model-09 and found no issues.
>>   * I have reviewed draft-ietf-netmod-acl-model-09 and found the following 
>> issues: ...
>>  
>> As well as:
>>  * I have implemented the data model in draft-ietf-netmod-acl-model-09.
>>   * I am implementing the data model in draft-ietf-netmod-acl-model-09.
>>   * I am considering to implement the data model in 
>> draft-ietf-netmod-acl-model-09.
>>   * I am not considering to implement the data model in 
>> draft-ietf-netmod-acl-model-09.
>>  
>> Thank you,
>> NETMOD WG Chairs
>>  
>>  
>> ___
>> netmod mailing list
>> 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
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] I-D Action: draft-ietf-netmod-yang-model-classification-04.txt

[Dean Bogdanovic]

We have submitted new version of the draft. In authors view this draft 
describes a set of concepts and associated terms to support consistent 
classification of YANG modules. It should provide guidelines to other document 
authors in the IETF and other places to decide how to use encode information 
from this draft. Hence encoding suggestion in section 4, adding classification 
type to YANG module catalogs, has been removed.

Chairs,

Please make WGLC on this document.

Cheers,

Dean

> On Oct 26, 2016, at 8:22 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the NETCONF Data Modeling Language of the IETF.
> 
>Title   : YANG Module Classification
>    Authors : Dean Bogdanovic
>  Benoit Claise
>  Carl Moberg
>   Filename: draft-ietf-netmod-yang-model-classification-04.txt
>   Pages   : 11
>   Date: 2016-10-26
> 
> Abstract:
>   The YANG [RFC6020] data modeling language is currently being
>   considered for a wide variety of applications throughout the
>   networking industry at large.  Many standards-defining organizations
>   (SDOs), open source software projects, vendors and users are using
>   YANG to develop and publish YANG modules for a wide variety of
>   applications.  At the same time, there is currently no well-known
>   terminology to categorize various types of YANG modules.
> 
>   A consistent terminology would help with the categorization of YANG
>   modules, assist in the analysis of the YANG data modeling efforts in
>   the IETF and other organizations, and bring clarity to the YANG-
>   related discussions between the different groups.
> 
>   This document describes a set of concepts and associated terms to
>   support consistent classification of YANG modules.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-yang-model-classification-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-model-classification-04
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] review of draft-ietf-pim-yang-03.txt

[Dean Bogdanovic]

Authors,

I don’t have deep knowledge of PIM, so if some protocol specifics haven’t been 
modeled right, I missed them. For application comparison, was looking at  
Juniper PIM configuration. The modules are using draft-ietf-netmod-routing-cfg 
as base, and follows the routing-instance-centric model, hence didn’t have 
problems mapping it to Junos PIM config style. The model design by using base 
module and build for each specific variant a separate module is a good 
approach, as it enables simpler application of the modules by vendors and users.

Throughout the draft authors are using abbreviations (many of them not widely 
known) and the terminology section is not complete for PIM.  It would be good 
to write them out when first time used in the text

example,

the configuration for PIM-SM that is not relevant for an SSM-only 
implementation is collected in an ASM container.

Same thing is in the YANG module descriptions

enum new-dr {
   description
 "A new DR was elected on the connected network.";
 }
 enum new-df {
   description
 "A new DF was elected on the connected network.";
 }

DR and DF should be spelled out in the description

Make the descriptions in the code consistent, like in following example
typedef pim-mode {
   type enumeration {
 enum none {
   description
 "PIM is not operating.";
 }
 enum ssm {
   description
 "Source-Specific Multicast (SSM) with PIM Sparse Mode.";
 }
 enum asm {
   description
"Any Source Multicast (ASM) with PIM Sparse Mode.";
 }


Why are the PIM related RFC not listed in the introduction section, as there 
are clearly relations between the model and PIM related RFCs

In chapter 2.2, why are you stating vendors will augment with required 
restrictions, but features might be added

It is expected that vendors
   will augment the model with any specific restrictions that might be
   required.  Vendors may also extend the features list with proprietary
   extensions.

It is expected that vendors will augment the model with any specific extensions 
and restrictions needed to adapt it to their vendor specific implementation. 

In chapter 3.1 bullet 2, the chapter finishes with statement

which does not make sense for PIM.

It would be nice to explain why does it not make sense for PIM. Why is there 
only 1 instances of PIM per VRF

From YANG perspective, the authors followed recommendations in the 
draft-ietf-netmod-rfc6087-bis-08

Hope this helps

Dean

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Regarding IPR on draft-ietf-netmod-routing-cfg-23

[Dean Bogdanovic]

Speaker as a contributor

No, I’m not aware of any IPR that applies to this draft

Dean
 
> On Aug 26, 2016, at 9:35 PM, Acee Lindem (acee)  wrote:
> 
> Speaker as an author,
> 
> No, I am not aware of an IPR that applies to this draft. 
> 
> Thanks,
> Acee
> 
> From: Kent Watsen mailto:kwat...@juniper.net>>
> Date: Friday, August 26, 2016 at 1:58 PM
> To: Ladislav Lhotka mailto:lho...@nic.cz>>, Acee Lindem 
> mailto:a...@cisco.com>>
> Cc: "netmod@ietf.org "  >, "netmod-cha...@ietf.org 
> "  >
> Subject: Regarding IPR on draft-ietf-netmod-routing-cfg-23
> 
> Authors, Contributors, WG,
>  
> As part of the WG Last Call, are you aware of any IPR that applies to draft 
> identified above?  Please state either:
>   * "No, I'm not aware of any IPR that applies to this draft"
>   * "Yes, I'm aware of IPR that applies to this draft"
>  
> If “yes”, has this IPR been disclosed in compliance with IETF IPR rules (see 
> RFCs 3979, 4879, 3669 and 5378 for more details)?   Please state either:
>   * "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
>   * "No, the IPR has not been disclosed"
>  
> If you answer “no”, please provide any additional details you think 
> appropriate.
>  
> If you are listed as a document author or contributor, please answer the 
> above by responding to this email regardless of whether or not you are aware 
> of any relevant IPR. This document will not advance to the next stage until a 
> response has been received from each author and listed contributor. NOTE: 
> THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.
>  
> If you are on the WG email list or attend WG meetings but are not listed as 
> an author or contributor, we remind you of your obligations under the IETF 
> IPR rules which encourages you to notify the IETF if you are aware of IPR of 
> others on an IETF contribution, or to refrain from participating in any 
> contribution or discussion related to your undisclosed IPR. For more 
> information, please see the RFCs listed above and 
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty 
> .
>  
> PS: Please include all listed in the headers of this message in your response.
>  
> Thank you,
> NETMOD WG Chairs
>  
>  
>  
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Question about acl-type in draft-ietf-netmod-acl-model-08

[Dean Bogdanovic]

(+netmod mailing list)
Adrian,

Please see inline
> On Aug 22, 2016, at 2:27 AM, Adrian Pan  wrote:
> 
> Dear authors,
>  
> I have some questions about ietf acl model as below, your reply is 
> appreciated.
>  
> 1)   In the model definition acl-type is one key of the acl, also in the 
> description it says that the acl-type could be ethernet, IPv4, IPv6, mixed, 
> in case the acl-type is mixed, what’s the identifier should be?
> Should it be augmented by different vendor? Since I don’t see the definition 
> about it.

As mixed ACLs are not supported by all vendors, those are not part of the 
standard model. Iit is up to the vendor to augment the ace-type and select an 
identifier to their liking. 

> 2)   In the “mix” case, the “matches” the ace list can be the combination of 
> Ethernet,ipv4,ipv6 for different ace, right?

Or another combination, again depends on what that particular vendor supports.
> 3)   With the model definition, even the acl-type is configured as Ethernet, 
> the operator still can configure the matches of ace under the acl as ipv4 or 
> ipv6, right?

No, if ACL type is ethernet, then all ACEs are expected to be ethernet. 
> is this the model design intention?

If acl-type is of one family, then only ace with match condition from that 
family are expected to be in the acl. If you want to combine them, please use 
mixed type.

Dean

> module: ietf-access-control-list
>+--rw access-lists
>   +--rw acl* [acl-type acl-name]
>  +--rw acl-name   string
>  +--rw acl-type   acl-type
>  +--ro acl-oper-data
>  +--rw access-list-entries
> +--rw ace* [rule-name]
>+--rw rule-namestring
>+--rw matches
>|  +--rw (ace-type)?
>  
>  leaf acl-type {
> 
>type acl-type;
> 
>description
> 
>  "Type of access control list. Indicates the primary intended
> 
>  type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, etc)
> 
>  used in the list instance.";
> 
>  }
> 
>  

> Thanks
> Adrian

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] ACL YANG Data Model and

[Dean Bogdanovic]

Dmytro,

We had those discussions and as those are not widely supported, we decided not 
to add it to the base model. The point is that additional match conditions are 
easily added via augmentation. An example is shown in module efxample-newco-acl

Dean

> On Jun 24, 2016, at 11:18 AM, Dmytro Gassanov 
>  wrote:
> 
> Hello Everybody,
>  
> I read the latest revision of “Network Access Control List (ACL) YANG Data 
> Model” and paid attention to +--rw matches leaf.
>  
> As far as I understood, currently it does not have matches regarding:
> · Type of application
> · TOS - IP Precedence (RFC 791)
> · COS - 802.1q 
> · Time (time based ACL)
>  
> What do you think, is it make sense to add these attributes to the leaf?
>  
> Thank you.
>  
> Best regards,
>  
> Dmytro Gassanov, 
> Netcracker Technology 
> 
> +380 44 238-8727 | ext. 6825 | office
> +380 67 441-5834 | mobile
> 
> We are Netcracker, and we are focused forward
>  
>  
> 
> 
> The information transmitted herein is intended only for the person or entity 
> to which it is addressed and may contain confidential, proprietary and/or 
> privileged material. Any review, retransmission, dissemination or other use 
> of, or taking of any action in reliance upon, this information by persons or 
> entities other than the intended recipient is prohibited. If you received 
> this in error, please contact the sender and delete the material from any 
> computer.  
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod 
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] yang model classification

[Dean Bogdanovic]

WG, 

Joel and I had an offline discussion and in order to make it more clear, a text 
clarification should be added to the document in which is stated that this 
document proposes initial elements for a taxonomy, rather than an initial 
taxonomy.

Dean

> On May 24, 2016, at 11:09 AM, Joel M. Halpern  wrote:
> 
> I had real trouble mapping the taxonomy to the models I am familair with.
> 
> ODL uses YANG models to define the persistent data and interface APIs to any 
> and all of its internal services.  These include controlling anything and 
> everything the controller does.  But the results of the YANG operations are 
> operations internal to ODL, although many result after processing in actions 
> applied to the network.
> 
> Yours,
> Joel
> 
> On 5/24/16 11:07 AM, Dean Bogdanovic wrote:
>> Joel,
>> 
>> 
>>> On Apr 24, 2016, at 9:31 PM, Joel M. Halpern  wrote:
>>> 
>>> What is the relationship between this taxonomy and the many models that do 
>>> not fit its cateogrization?
>>> 
>>> Three examples:
>>> Models used in ODL to generate results which may be neither network 
>>> services nor network elements.  They may be in between, or in some other 
>>> dimension?
>> 
>> When you say generate results, those models generate results based on what? 
>> Can you give some examples?
>> 
>>> 
>>> Also, models used to describe things in other aspects of environments, such 
>>> as Policy models?
>> 
>> Policy will describe an action on device or on a network service, as in 
>> general policy is defined as a set of match condition(s) followed by an 
>> action. I would even say that most policies are for network service models.
>>> 
>>> And models of things which are not conventional network elements, such as 
>>> models of compute platforms, models of applications, even models of control 
>>> systems.
>> 
>> We haven’t created device as generic network element, but with networking in 
>> mind. You can view it as generic. Device should always provide what it is 
>> capable of and it is a superset into which all other models must fit.
>> 
>> Dean
>> 
>>> 
>>> Yours,
>>> Joel
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] input Interface match

[Dean Bogdanovic]

Jason,


> On Apr 29, 2016, at 3:33 PM, Sterne, Jason (Nokia - CA) 
>  wrote:
> 
> Hi guys,
> 
> I agree that we may want to consider other metadata items and also agree they 
> will tend to be more implementation-specific.  But rather than hold up this 
> base ACL model for metadata why don't we treat metadata in either a follow up 
> extension draft or leave them to vendor-specific augmentations (if there 
> isn't enough commonality).

I believe that we have to add text that metadata can be match conditions in an 
ACL. In this case, I would add an example at the end of the document to show 
how it can be done through augmentation.

> 
> I don't think this model should have ingress vs egress as an attribute of an 
> ACL. An ACL is directionless on its own and direction can be part of how it 
> is applied to an object (e.g. maybe an augmentation to the interfaces module 
> to add "ingress-acl" and "egress-acl" leaf refs).

I think that would be a good example to show how to augment model.

Dean

> 
> Jason
> 
> -Original Message-
> From: EXT Ladislav Lhotka [mailto:lho...@nic.cz] 
> Sent: Friday, April 22, 2016 9:49
> To: Dean Bogdanovic; Sterne, Jason (Nokia - CA)
> Cc: netmod WG
> Subject: Re: [netmod] input Interface match
> 
> Dean Bogdanovic  writes:
> 
>> Any other opinions on this issue? There were quite a few hands in the 
>> air during the WG meeting
> 
> Unlike packet header fields, metadata are very much implementation-specific, 
> and may also depend on the context - e.g. whether packet filtering is ingress 
> or egress.
> 
> The draft cites nftables but in fact nftables includes several metadata 
> items, not only input-interface:
> 
> http://wiki.nftables.org/wiki-nftables/index.php/Matching_packet_metainformation
> 
> I would suggest to think about other aspects of ACL type, such as 
> "ingress-acl" versus "egress-acl", and either define additional leafs for 
> these aspects or utilize multiple inheritance of identities that is possible 
> in YANG 1.1.
> 
> Then, I would extend the "metadata" grouping with other reasonably common 
> metadata items (for example, output-interface or packet-length), and make 
> each item conditional via "when" and/or "if-feature".
> 
> Lada
> 
>> 
>> Dean
>> 
>>> On Apr 8, 2016, at 8:25 AM, Sterne, Jason (Nokia - CA) 
>>>  wrote:
>>> 
>>> Hi Dean,
>>> 
>>> We should remove the metadata grouping from the base model.  It is out of 
>>> place with the rest of the model and a fairly clean line to draw as a 
>>> boundary for future extension/augmentation.
>>> 
>>> Regards,
>>> Jason
>>> 
>>> From: EXT Dean Bogdanovic [mailto:ivand...@gmail.com]
>>> Sent: Friday, April 08, 2016 9:25
>>> To: Sterne, Jason (Nokia - CA)
>>> Cc: netmod WG
>>> Subject: Re: [netmod] input Interface match
>>> 
>>> Jason,
>>> 
>>> After looking at the document and the model, it is also about having 
>>> metadata grouping in the model. If you want to have metadata grouping in 
>>> the model, then you have to have something inside and then input-interface 
>>> questions comes up. If you don’t have to have metadata grouping in the base 
>>> model, everything is easy.
>>> 
>>> I believe this is the right question
>>> 
>>> Dean
>>> 
>>> On Apr 8, 2016, at 9:20 AM, Sterne, Jason (Nokia - CA) 
>>> mailto:jason.ste...@nokia.com>> wrote:
>>> 
>>> Hi Dean,
>>> 
>>> Just to clarify -> the main question posed in the WG meeting was about the 
>>> input-interface match criteria.  From the meeting minutes:
>>> 
>>> Chairs: call for if interface should be in base:
>>>6 prefer NOT having it in the doc at all
>>>5 prefer having it in, but as a feature
>>>2 prefer having it in the doc as required
>>> 
>>> Maybe we should get agreement on what to do about input-interface (on the 
>>> list) first and then we can figure out what to do about the metadata 
>>> grouping.
>>> 
>>> Matching on basic IPv4/IPv4/MAC header fields is common functionality.  But 
>>> having that input-interface match on metadata in the core model is out of 
>>> place.  It should be left to further extension drafts or vendor specific 
>>> augmentations (along with whatever other metadata might be useful or 
>>> vendor-specific). Many major implementations do not support matching on 
>>>

Re: [netmod] yang model classification

[Dean Bogdanovic]

Joel,


> On Apr 24, 2016, at 9:31 PM, Joel M. Halpern  wrote:
> 
> What is the relationship between this taxonomy and the many models that do 
> not fit its cateogrization?
> 
> Three examples:
> Models used in ODL to generate results which may be neither network services 
> nor network elements.  They may be in between, or in some other dimension?

When you say generate results, those models generate results based on what? Can 
you give some examples?

> 
> Also, models used to describe things in other aspects of environments, such 
> as Policy models?

Policy will describe an action on device or on a network service, as in general 
policy is defined as a set of match condition(s) followed by an action. I would 
even say that most policies are for network service models.
> 
> And models of things which are not conventional network elements, such as 
> models of compute platforms, models of applications, even models of control 
> systems.

We haven’t created device as generic network element, but with networking in 
mind. You can view it as generic. Device should always provide what it is 
capable of and it is a superset into which all other models must fit.

Dean

> 
> Yours,
> Joel
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Can you remove the "Identity acl-base" defined in draft-ietf-netmod-acl-model-07

[Dean Bogdanovic]

Tom,

It is how YANG does strong typing for  identities. Please see Andy’s email

Dean

> On May 10, 2016, at 2:17 PM, Nadeau Thomas  wrote:
> 
> 
>   Yea, I agree that its probably worth giving a little more latitude when 
> helping people with models. 8)
> 
>   —Tom
> 
> 
>> On May 10, 2016:12:55 PM, at 12:55 PM, Linda Dunbar 
>>  wrote:
>> 
>> Juergen, 
>> 
>> Of course, it is not confusing to you because you are in the box (vs. many 
>> of us are outside the box looking in). 
>> 
>> RFC 6020 doesn't say all identities have to have a sub-identity. 
>> 
>> 
>> My opinion only. 
>> 
>> 
>> Linda 
>> 
>> 
>> -Original Message-
>> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
>> Sent: Tuesday, May 10, 2016 10:38 AM
>> To: Linda Dunbar
>> Cc: draft-ietf-netmod-acl-mo...@ietf.org; 'netmod@ietf.org'; Thomas D. Nadeau
>> Subject: Re: Can you remove the "Identity acl-base" defined in 
>> draft-ietf-netmod-acl-model-07
>> 
>> On Tue, May 10, 2016 at 03:07:30PM +, Linda Dunbar wrote:
>>> Juergen,
>>> 
>>> If "acl-base" has some content more than the comment (i.e. the 
>>> description), then it makes sense.  
>>> 
>>> The comments in the "identity ipv4-acl" is enough to describe the identity. 
>>> Same with the identity ipv6-acl. 
>>> 
>>> I find it is very confusing to have the recursive reference of identity 
>>> (all of them are simply the description). 
>>> 
>> 
>> I fail to see anything confusing here. Did you read the relevant sections of 
>> RFC 6020? What is unclear about identities and how they work?
>> 
>> /js
>> 
>> -- 
>> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Is there any common module (like library module) for matching all IPv4 or IPv6 header fields?

[Dean Bogdanovic]

Linda,

If you need additional fields in ACL, it is easy to extend the existing base 
model. The intention of the draft authors was to create base common model that 
can be then extended for different uses. 

Saying that, there is nothing out there that could be used for your purposes, 
but using the ACL model, you should be able to augment it for your use case.

Dean

> On May 5, 2016, at 11:48 PM, Linda Dunbar  wrote:
> 
> Dear YANG Model experts: 
>  
> Draft-ietf-netmod-acl-model-07 has matching criteria for Destination Address 
> and Source for IPv4 and IPv6 respectively, like:
>  
> 
>  
> IDR FlowSpec also has  defined YANG model for matching criteria for IPv6/ 
> IPv4-prefix plus other header fields. I2RS Filter Based RIB also define 
> various header matching.
>  
> Is there a common library module that can be called when any IP header fields 
> need to be used as matching criteria?
>  
> Thanks, Linda Dunbar

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] input Interface match

[Dean Bogdanovic]

Any other opinions on this issue? There were quite a few hands in the air 
during the WG meeting

Dean

> On Apr 8, 2016, at 8:25 AM, Sterne, Jason (Nokia - CA) 
>  wrote:
> 
> Hi Dean,
>  
> We should remove the metadata grouping from the base model.  It is out of 
> place with the rest of the model and a fairly clean line to draw as a 
> boundary for future extension/augmentation.
>  
> Regards,
> Jason
>  
> From: EXT Dean Bogdanovic [mailto:ivand...@gmail.com] 
> Sent: Friday, April 08, 2016 9:25
> To: Sterne, Jason (Nokia - CA)
> Cc: netmod WG
> Subject: Re: [netmod] input Interface match
>  
> Jason,
>  
> After looking at the document and the model, it is also about having metadata 
> grouping in the model. If you want to have metadata grouping in the model, 
> then you have to have something inside and then input-interface questions 
> comes up. If you don’t have to have metadata grouping in the base model, 
> everything is easy.
>  
> I believe this is the right question
>  
> Dean
>  
> On Apr 8, 2016, at 9:20 AM, Sterne, Jason (Nokia - CA) 
> mailto:jason.ste...@nokia.com>> wrote:
>  
> Hi Dean,
>  
> Just to clarify -> the main question posed in the WG meeting was about the 
> input-interface match criteria.  From the meeting minutes:
>  
> Chairs: call for if interface should be in base:
> 6 prefer NOT having it in the doc at all
> 5 prefer having it in, but as a feature
> 2 prefer having it in the doc as required
>  
> Maybe we should get agreement on what to do about input-interface (on the 
> list) first and then we can figure out what to do about the metadata grouping.
>  
> Matching on basic IPv4/IPv4/MAC header fields is common functionality.  But 
> having that input-interface match on metadata in the core model is out of 
> place.  It should be left to further extension drafts or vendor specific 
> augmentations (along with whatever other metadata might be useful or 
> vendor-specific). Many major implementations do not support matching on 
> input-interface (Cisco IOS-XR, Nokia SR OS, Brocade, others).  The typical 
> way to associate ACLs and Interfaces is by assigning an ACL to an interface 
> as shown in section A.3. of the ACL draft.   There is some discussion of this 
> on the NETMOD thread “Remove input-interface (metadata) from 
> netmod-acl-model-07 ?”.
>  
> Regards,
> Jason
>  
> From: netmod [mailto:netmod-boun...@ietf.org 
> <mailto:netmod-boun...@ietf.org>] On Behalf Of EXT Dean Bogdanovic
> Sent: Thursday, April 07, 2016 11:12
> To: netmod WG
> Subject: [netmod] input Interface match
>  
> As the action item from the netmod WG and, hopefully, last open item in the 
> ACL draft is the leaf input interface in the metadata grouping 
>  
> grouping metadata {
> description
>   "Fields associated with a packet which are not in
>   the header.";
> leaf input-interface {
>   type if:interface-ref {
> require-instance false;
>   }
>   description
> "Packet was received on this interface.";
> }
>   }
> }
>  
>  
> Here are two questions:
> One
> Do want to have a metadata grouping in the basic ACL model? If yes, we have 
> to put in some leafs in there. There are implementations which use metadata 
> as match condition
>  
> If we agree that metadata grouping is not needed in the basic model, then the 
> authors would remove the grouping from the model and I believe that no more 
> discussion is needed on this point
>  
> Dean

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] input Interface match

[Dean Bogdanovic]

Jason,

After looking at the document and the model, it is also about having metadata 
grouping in the model. If you want to have metadata grouping in the model, then 
you have to have something inside and then input-interface questions comes up. 
If you don’t have to have metadata grouping in the base model, everything is 
easy.

I believe this is the right question

Dean

> On Apr 8, 2016, at 9:20 AM, Sterne, Jason (Nokia - CA) 
>  wrote:
> 
> Hi Dean,
>  
> Just to clarify -> the main question posed in the WG meeting was about the 
> input-interface match criteria.  From the meeting minutes:
>  
> Chairs: call for if interface should be in base:
> 6 prefer NOT having it in the doc at all
> 5 prefer having it in, but as a feature
> 2 prefer having it in the doc as required
>  
> Maybe we should get agreement on what to do about input-interface (on the 
> list) first and then we can figure out what to do about the metadata grouping.
>  
> Matching on basic IPv4/IPv4/MAC header fields is common functionality.  But 
> having that input-interface match on metadata in the core model is out of 
> place.  It should be left to further extension drafts or vendor specific 
> augmentations (along with whatever other metadata might be useful or 
> vendor-specific). Many major implementations do not support matching on 
> input-interface (Cisco IOS-XR, Nokia SR OS, Brocade, others).  The typical 
> way to associate ACLs and Interfaces is by assigning an ACL to an interface 
> as shown in section A.3. of the ACL draft.   There is some discussion of this 
> on the NETMOD thread “Remove input-interface (metadata) from 
> netmod-acl-model-07 ?”.
>  
> Regards,
> Jason
>  
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of EXT Dean Bogdanovic
> Sent: Thursday, April 07, 2016 11:12
> To: netmod WG
> Subject: [netmod] input Interface match
>  
> As the action item from the netmod WG and, hopefully, last open item in the 
> ACL draft is the leaf input interface in the metadata grouping 
>  
> grouping metadata {
> description
>   "Fields associated with a packet which are not in
>   the header.";
> leaf input-interface {
>   type if:interface-ref {
> require-instance false;
>   }
>   description
> "Packet was received on this interface.";
> }
>   }
> }
>  
>  
> Here are two questions:
> One
> Do want to have a metadata grouping in the basic ACL model? If yes, we have 
> to put in some leafs in there. There are implementations which use metadata 
> as match condition
>  
> If we agree that metadata grouping is not needed in the basic model, then the 
> authors would remove the grouping from the model and I believe that no more 
> discussion is needed on this point
>  
> Dean

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] input Interface match

[Dean Bogdanovic]

As the action item from the netmod WG and, hopefully, last open item in the ACL 
draft is the leaf input interface in the metadata grouping 

grouping metadata {
description
  "Fields associated with a packet which are not in
  the header.";
leaf input-interface {
  type if:interface-ref {
require-instance false;
  }
  description
"Packet was received on this interface.";
}
  }
}


Here are two questions:
One
Do want to have a metadata grouping in the basic ACL model? If yes, we have to 
put in some leafs in there. There are implementations which use metadata as 
match condition

If we agree that metadata grouping is not needed in the basic model, then the 
authors would remove the grouping from the model and I believe that no more 
discussion is needed on this point

Dean

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG model classification?

[Dean Bogdanovic]

> On Apr 7, 2016, at 7:45 AM, Juergen Schoenwaelder 
>  wrote:
> 
> On Thu, Apr 07, 2016 at 08:55:19AM +, Scharf, Michael (Nokia - DE) wrote:
>>> I come at this from the classification angle, so my interest is if the 
>>> assumption that
>>> a YANG model can only be classified as a network service model XOR a 
>>> network device model
>>> according to the definitions in draft-ietf-netmod-yang-model-classification 
>>> (sections 2.1
>>> and 2.2). Based on this discussion I take it that some models are intended 
>>> to be able to
>>> serve in both roles. And we should make sure that it’s supported in our 
>>> catalog structure.
>> 
>> Regarding the XOR assumption for classification:
>> 
>> You may also want to think about YANG models that are NEITHER device NOR 
>> service models. For instance, what about RFC 6991? And I think other, more 
>> technical models presented this week may fall into a similar category 
>> ("generic"?).
>> 
> 
> RFC 6991 is not really defining a data model, while ietf-yang-types
> and ietf-inet-types are both YANG modules they do not define any data
> nodes that can be implemented. Lets look at RFC 6020bis:
> 
>   o  data model: A data model describes how data is represented and
>  accessed.
> 
> Anyway, the point is that RFC 6991 do not define any data nodes and
> hence nothing that can be accessed. Perhaps it helps to import
> terminology into the model classification document and to be explicit
> that not all YANG modules define YANG data models.

This is a good definition to be added, as in the draft we are talking about 
classifying data models and we have to go through the document and make sure 
that we use data model instead of model consistently.

Dean

> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ?

[Dean Bogdanovic]

Hi Jason,

> On Apr 1, 2016, at 6:54 PM, Sterne, Jason (Nokia - CA) 
>  wrote:
> 
> Hi Dean,
>  
> From what Acee mentions it doesn’t seem that IOS-XR supports matching on 
> interface for ACLs.

I replied to Acee’s comment in separate email, as I found some examples on the 
web, but it looks as older versions of software.
>  
> When I look at Brocade I don’t see it either.  Maybe someone from Brocade 
> could provide an example of the config if it is supported ?
> https://github.com/YangModels/yang/blob/master/vendor/brocade/brocade-ip-access-list.yang
>  
> <https://github.com/YangModels/yang/blob/master/vendor/brocade/brocade-ip-access-list.yang>
> (I also checked their user guides)

Brocade gives examples of using ACLs in route-maps and provide examples
http://www.brocade.com/content/html/en/configuration-guide/netiron-05900-routingguide/GUID-83F457B7-4CFB-4852-AC08-59BCD9E2AF7C.html
>  
> I think it is more relevant to look at ACL functionality for this (not log 
> filtering or other misc. filtering capabilities in areas outside of ACLs).  I 
> really don’t think this has widespread support and it isn’t core 
> functionality -> assigning an ACL to an interface is how it is normally done.

I’ll add this item to the open issue and will ask WG at the meeting for opinion.

>  
> Regards,
> Jason
>  
> From: EXT Dean Bogdanovic [mailto:ivand...@gmail.com 
> <mailto:ivand...@gmail.com>] 
> Sent: Thursday, March 31, 2016 2:26
> To: Sterne, Jason (Nokia - CA)
> Cc: netmod WG
> Subject: Re: [netmod] Remove input-interface (metadata) from 
> netmod-acl-model-07 ?
>  
>  
> On Mar 30, 2016, at 9:36 PM, Sterne, Jason (Nokia - CA) 
> mailto:jason.ste...@nokia.com>> wrote:
>  
> Hi all,
>  
> The ACL model is converging on a small core set of functionality that is 
> fairly common.
>  
> But I think the matching on input-interface should be removed from the model 
> (or at the least put inside a feature flag).
>  
> Matching on basic IPv4/IPv4/MAC header fields is common functionality.  But 
> having that input-interface match on metadata in the core model is out of 
> place.  It should be left to further extension drafts or vendor specific 
> augmentations (along with whatever other metadata might be useful or 
> vendor-specific).
>  
> ACLs are typically assigned to interfaces as shown in section A.3. of the ACL 
> draft.   That is the most common use case.
>  
> Actually matching on input-interface in the ACL rules themselves is not basic 
> core ACL functionality.  Nokia SR OS does not have that capability.  Does 
> IOS-XR ?  Brocade ?  others ?
>  
> Cisco and Juniper support matching on input interface. It is useful when you 
> want to filter on general traffic coming from interface.
>  
> Cisco
> match input-interface
> match input-vlan
>  
>  
> Junos
> family any {
> filter L2_filter {
> term t1 {
> from {
> interface fe-0/0/0.0;
> }
> then {
> policer p1;
> count c1;
> }
> }
> }
> }
>  
> Brocade supports matching based on interface, Dell supports VLAN matching, 
> Arista supports input interface matching, Redback supports matching against 
> input interface for logging, so it is pretty standard across multiple vendors
>  
> Dean
>  
>  If some major implementations don’t do it, and it isn’t necessary for 
> typical basic ACL use, then it should be removed (or feature flagged).
>  
> Regards,
> Jason 
>  
> ___
> 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
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ?

[Dean Bogdanovic]

Hi Acee,

> On Mar 31, 2016, at 8:17 AM, Acee Lindem (acee)  wrote:
> 
> Hi Dean, 
> 
> From: netmod mailto:netmod-boun...@ietf.org>> on 
> behalf of Dean Bogdanovic mailto:ivand...@gmail.com>>
> Date: Thursday, March 31, 2016 at 5:26 AM
> To: "Sterne, Jason (Nokia - CA)"  <mailto:jason.ste...@nokia.com>>
> Cc: netmod WG mailto:netmod@ietf.org>>
> Subject: Re: [netmod] Remove input-interface (metadata) from 
> netmod-acl-model-07 ?
> 
> 
>> On Mar 30, 2016, at 9:36 PM, Sterne, Jason (Nokia - CA) 
>> mailto:jason.ste...@nokia.com>> wrote:
>> 
>> Hi all,
>>  
>> The ACL model is converging on a small core set of functionality that is 
>> fairly common.
>>  
>> But I think the matching on input-interface should be removed from the model 
>> (or at the least put inside a feature flag).
>>  
>> Matching on basic IPv4/IPv4/MAC header fields is common functionality.  But 
>> having that input-interface match on metadata in the core model is out of 
>> place.  It should be left to further extension drafts or vendor specific 
>> augmentations (along with whatever other metadata might be useful or 
>> vendor-specific).
>>  
>> ACLs are typically assigned to interfaces as shown in section A.3. of the 
>> ACL draft.   That is the most common use case.
>>  
>> Actually matching on input-interface in the ACL rules themselves is not 
>> basic core ACL functionality.  Nokia SR OS does not have that capability.  
>> Does IOS-XR ?  Brocade ?  others ?
> 
> Cisco and Juniper support matching on input interface. It is useful when you 
> want to filter on general traffic coming from interface.
> 
> Cisco
> match input-interface
> match input-vlan
> 
> These are “class-map”  sub-commands - not “access-list" sub-commands. So you 
> are referring to the general functionality rather than specifically 
> functionality supported by access-list? 

According to the Cisco website 
(http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750x_3560x/software/release/12-2_55_se/configuration/guide/3750xscg/swacl.html)

Note The ACL must be an extended named ACL.

 <>– match input-interface interface-id-list

 <>– match ip dscp dscp-list

 <>– match ip precedence ip-precedence-list


> 
> 
> 
> Junos
> family any {
> filter L2_filter {
> term t1 {
> from {
> interface fe-0/0/0.0;
> }
> then {
> policer p1;
> count c1;
> }
> }
> }
> }
> 
> Brocade supports matching based on interface, Dell supports VLAN matching, 
> Arista supports input interface matching, Redback supports matching against 
> input interface for logging,
> 
> If you are referring to “log-input”, this indicates to include the 
> input-interface in the log message. Cisco supports this as well. 
> 
> Thanks,
> Acee 
> 
> 
> so it is pretty standard across multiple vendors
> 
> Dean
> 
>>  If some major implementations don’t do it, and it isn’t necessary for 
>> typical basic ACL use, then it should be removed (or feature flagged).
>>  
>> Regards,
>> Jason 
>>  
>> ___
>> 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
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Remove input-interface (metadata) from netmod-acl-model-07 ?

[Dean Bogdanovic]

> On Mar 30, 2016, at 9:36 PM, Sterne, Jason (Nokia - CA) 
>  wrote:
> 
> Hi all,
>  
> The ACL model is converging on a small core set of functionality that is 
> fairly common.
>  
> But I think the matching on input-interface should be removed from the model 
> (or at the least put inside a feature flag).
>  
> Matching on basic IPv4/IPv4/MAC header fields is common functionality.  But 
> having that input-interface match on metadata in the core model is out of 
> place.  It should be left to further extension drafts or vendor specific 
> augmentations (along with whatever other metadata might be useful or 
> vendor-specific).
>  
> ACLs are typically assigned to interfaces as shown in section A.3. of the ACL 
> draft.   That is the most common use case.
>  
> Actually matching on input-interface in the ACL rules themselves is not basic 
> core ACL functionality.  Nokia SR OS does not have that capability.  Does 
> IOS-XR ?  Brocade ?  others ?

Cisco and Juniper support matching on input interface. It is useful when you 
want to filter on general traffic coming from interface.

Cisco
match input-interface
match input-vlan


Junos
family any {
filter L2_filter {
term t1 {
from {
interface fe-0/0/0.0;
}
then {
policer p1;
count c1;
}
}
}
}

Brocade supports matching based on interface, Dell supports VLAN matching, 
Arista supports input interface matching, Redback supports matching against 
input interface for logging, so it is pretty standard across multiple vendors

Dean

>  If some major implementations don’t do it, and it isn’t necessary for 
> typical basic ACL use, then it should be removed (or feature flagged).
>  
> Regards,
> Jason 
>  
> ___
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod 
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Fwd: I-D Action: draft-ietf-netmod-acl-model-07.txt

[Dean Bogdanovic]

The ver 07 has incorporated comments from the WG LC and it has been moved to 
YANG 1.1

Dean

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: [netmod] I-D Action: draft-ietf-netmod-acl-model-07.txt
> Date: March 11, 2016 at 12:59:30 PM EST
> To: 
> Cc: netmod@ietf.org
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the NETCONF Data Modeling Language of the IETF.
> 
>Title   : Network Access Control List (ACL) YANG Data Model
>Authors : Dean Bogdanovic
>  Kiran Agrahara Sreenivasa
>  Lisa Huang
>  Dana Blair
>   Filename: draft-ietf-netmod-acl-model-07.txt
>   Pages   : 27
>   Date: 2016-03-11
> 
> Abstract:
>   This document describes a data model of Access Control List (ACL)
>   basic building blocks.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-acl-model-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-07
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-acl-model status

[Dean Bogdanovic]

Tom,

One mailing list suggestion was using yang 1.1 construct. If we do it without 
that suggestion, then the model doesn’t require update, but it is better with 
this suggestion

Dean

> On Feb 3, 2016, at 7:52 PM, Nadeau Thomas  wrote:
> 
> 
>   Will your model require any updates once 1.1 is ratified?  We don’t 
> want to predicate having a bunch of models move forward on the 1.1 work 
> moving forward. 
> 
>   —Tom
> 
> 
>> On Feb 3, 2016:11:45 AM, at 11:45 AM, Dean Bogdanovic  
>> wrote:
>> 
>> Tom,
>> 
>> We will publish ACL model requiring YANG 1.1 as per discussion on the list
>> 
>> Dean
>> 
>>> On Feb 3, 2016, at 4:35 PM, Lisa (Yi) Huang  wrote:
>>> 
>>> Tom,
>>> 
>>> We discussed the review comments in the working group in offline meeting.
>>> Will publish a new draft to address comments. Thanks,
>>> 
>>> Lisa
>>> 
>>> On 2/1/16, 8:01 AM, "netmod on behalf of Nadeau Thomas"
>>>  wrote:
>>> 
>>>> 
>>>>ACL Doc Authors:
>>>> 
>>>>What is your status and plan to address the numerous technical comments
>>>> that have arisen since the WG LC?
>>>> I know there are for example, numerous detailed comments from Juergen and
>>>> I think Elliot Lear posted some too.
>>>> 
>>>>‹Tom
>>>> 
>>>> ___
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> 
>> 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-acl-model status

[Dean Bogdanovic]

Tom,

We will publish ACL model requiring YANG 1.1 as per discussion on the list

Dean

> On Feb 3, 2016, at 4:35 PM, Lisa (Yi) Huang  wrote:
> 
> Tom,
> 
> We discussed the review comments in the working group in offline meeting.
> Will publish a new draft to address comments. Thanks,
> 
> Lisa
> 
> On 2/1/16, 8:01 AM, "netmod on behalf of Nadeau Thomas"
>  wrote:
> 
>> 
>>  ACL Doc Authors:
>> 
>>  What is your status and plan to address the numerous technical comments
>> that have arisen since the WG LC?
>> I know there are for example, numerous detailed comments from Juergen and
>> I think Elliot Lear posted some too.
>> 
>>  ‹Tom
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06

[Dean Bogdanovic]

> On Jan 21, 2016, at 9:56 PM, Ebben Aries  wrote:
> 
> 
> On 01/21/2016 12:45 AM, Qin Wu wrote:
>> 1. This draft defines two module, one is IETF-PACKET-FIELDS, the other is 
>> ietf-access-control-list module,
>> I am wondering whether ietf-packet-fields module can be defined in more 
>> generic way that can be applied to other modules defined somewhere else?
>> e.g., in ietf-packet-fields module, acl-ip-header-fields grouping is 
>> defined, I am wondering whether prefix "acl-" can be removed to make it more 
>> generic?
> 
> What you'll likely run into here is that the header fields defined in
> acl-*-header-fields are more or less the lowest common denominators for
> the application of "acl" - Not all header fields are defined here.

Correct, it was lowest common denominator.
> 
> I suppose an approach could be to define generic groupings of all header
> fields and create per application groupings, referencing what is
> supported with appropriate constraints, etc…
>  Not sure what that buys
> here since you're likely to have overlap but not complete parity between
> the different consumers of these packet fields.

The ietf-packet-fields could be reused in QoS for matching and in some vendors 
case, they are using access list for matching. So it is consistent naming for 
match conditions. The QoS design team mapped out there own match conditions. 
> 
> /ebben
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06

[Dean Bogdanovic]

> On Jan 11, 2016, at 7:30 PM, Juergen Schoenwaelder 
>  wrote:
> 
> On Mon, Jan 11, 2016 at 05:58:52PM +0100, Dean Bogdanovic wrote:
>> 
>>> 
>>> For the sake of clarity, I personally would prefer to have a single
>>> term. I think Linux packet filters call things rules. I think BSD
>>> packet filtering calls things rules. Wikipedia seem say that packet
>>> filters consist of filtering rules... So I guess I have a preference
>>> but I will not get a sleepless night over this.
>> 
>> Authors are Cisco/Juniper people, so were using that terminology and I 
>> believe that CSCO and JNPR are more used in networking then Linux :)
>> 
> 
> If I were to have the time, I would even challenge you on
> that. Clearly, when you consider # of devices connected to the
> Internet, I am sure CISCO and JNPR will loose. But even in enterprise
> networks, there are tons of Linux and BSD firewalls. Consider all the
> home routers running openWRT and packet filters. So yes, if I would
> have time, I would challenge you on that argument.

I would definitely take you on this one. As OpenWRT is domain of hobbyist. If I 
may ask you, what device your ISP is sending you as access point? :)

> 
> In some Junos documentation (Junos 14.2), I have seen the terms
> 'filter' and 'term'. But I might be proven wrong…

Juniper is using filter and term, that is correct, from day one. OTH, Cisco is 
using Access Control List (ACL) and ACL Entries (ACE) and several other vendors 
(Brocade, Huawei, ALu, Ericsson Redback) are using those terms too. ACL is well 
established in the industry. 
> 
>>>>> - Should there be features for ace-eth and ace-ipv4 and ace-ipv6 or do
>>>>> we expect that all implementations will always support all three?
>>>>> Another option would be to have the generic model completely without
>>>>> any protocol specific elements and to have separate models to
>>>>> augment in ipv4, ipv6, and ethernet specific ace types. I actually
>>>>> think this would make much more sense since you would not have a
>>>>> module 'packet fields' but instead a clear extension of the
>>>>> ietf-access-control-list module. You could also drop the examples
>>>>> how to extend the core model since the ip and ethernet extensions
>>>>> would already serve the purpose. You also would not need features
>>>>> since an implementation advertises the extension modules.
>>>> 
>>>> We started early with such design, but then the WG feedback moved us to 
>>>> the current  design.
>>> 
>>> Can you provide pointers to minutes etc? I think the routing model
>>> also has a core model where even unicast routing is augmented in. This
>>> seems to make the boundary between the generic infrastructure and the
>>> addins very clear.
>> 
>> I haven’t seen a network device with filters without supporting L2 and L3 
>> types. This is how we started originally, but then comments came in on the 
>> mailing list and wanted exact typing. Please see the thread
>> 
>> http://www.ietf.org/mail-archive/web/netmod/current/msg12144.html
>> 
>> Model was changed for IETF 94 and at the WG meeting nobody raised the issue.
> 
> I am talking about the modularity of the base model, I do not see how
> the cited thread relates to this.

Among the vendors, ace-eth, ace-ipv4 and ace-ipv6 are always supported. I 
appreciate your input, but we did this design choice as design team and went 
forward with it. Also, the YANG models are not set in stone. I definitely see 
models evolving.

> 
>>>>> - The 'uses packet-fields:metadata' resolves to a leaf
>>>>> 'input-interface' which is of type string. Is this the only metadata
>>>>> field we ever envision to be there? If so, why not make it part of
>>>>> the base model? If not, what is the extensibility model here?  
>>>> 
>>>> It can be used for route filtering
>>> 
>>> Yeah, but the questions were:
>>> 
>>> - Is this the only metadata field we ever envision to be there?
>> No, it can be timestamp, RIB, VRF, etc.
>> 
>>> - If so, why not make it part of the base model?
>> 
>> We are early in the modeling and people were asking to remove time range 
>> from the base model and create separate draft, as many other features are 
>> using time-range.
> 
> I agree that the decision is kind of tough to make. One option is to
> make the base model pretty much content free and to add pretty much
> ever

Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06

[Dean Bogdanovic]

> On Dec 21, 2015, at 4:33 PM, Juergen Schoenwaelder 
>  wrote:
> 
> On Sat, Dec 19, 2015 at 07:50:58AM -0500, Dean Bogdanovic wrote:
>> Juergen,
>> 
>> Please see answers inline
>> 
>> Dean
>> 
>>> On Dec 11, 2015, at 12:31 PM, Juergen Schoenwaelder 
>>>  wrote:
>>> 
>>> On Wed, Dec 09, 2015 at 08:27:04AM -0800, Nadeau Thomas wrote:
>>>> 
>>>>This email initiates a NETMOD WG Last call for 
>>>> draft-ietf-netmod-acl-model-06. 
>>>> Please review the draft and make any comments to the list by Wednesday, 16 
>>>> December, 2015
>>>> by 8AM EST.
>>>> 
>>> 
>>> Technical
>>> 
>>> - I am not sure I personally like the acl-oper-data and ace-oper-data
>>> containers in the middle of the config true tree. I understand that
>>> operational state in this case is likely tightly bound to the
>>> lifetime of the config state but I also generally prefer to have a
>>> clean separation of config from state. But since I am not
>>> implementing this, I am happy to leave the decision to those who
>>> write the code.
>>> 
>>> - I would probably have used src-ipv4-prefix and dst-ipv4-prefix
>>> instead of source-ipv4-network and destination-ipv4-network and
>>> I would probably have used src-mac-address and src-mac-address-mask
>>> and dst-mac-address and dst-mac-address-mask. Generally simple
>>> src instead source and dst instead destination - lines up all
>>> much more nicely.
>> 
>> I know that src and dst are pretty standard abbreviations, but have 
>> preference to use full words.
>> 
> 
> My eyes prefer the shorter versions but it might be subjective where
> the line between arconyms and words is drawn. For me, things are not
> done consistently according to my personal preferences. ;-)

As many people, so many different preferences :)

> 
>>> - I would have put the acl-name and acl-type first followed by the
>>> entries list.
>> 
>> Can you please expand on this? Is there any major difference? OR just design 
>> choice?
> 
> Technically you can define key leafs anywhere but I think there are some
> benefits of defining them at the beginning of a list:
> 
> a) I find it nice if the leafs listed in the key statement follow the
>   key statement and not N pages down the document.
> b) If you put them at the end and you have to add additional definitions,
>   you will end up with leafs somewhere in the middle.
> c) The XML encoding requires to ship key leafs first and it might be
>   simpler if the key leafs are also defined first in the data model
>   (so if you use the same order, you actually get things correct).
> 
> Now you tell me what the advantages are to put them at the end…

I think this ended up being an edit oversight. In the draft 02, the stated 
leafs were at the top

module: ietf-acl
+--rw access-lists
+--rw access-list* [access-control-list-name]
+--rw access-control-list-name string
+--rw access-control-list-type?access-control-list-type
+--ro access-control-list-oper-data
|  +--ro (targets)?
| +--:(interface-name)
|+--ro interface-name*   string
+--rw access-list-entries
+--rw access-list-entry* [rule-name]

I don’t remember if there was any specific reason to push the acl-name and 
acl-type to the end. Will bring it back up.
> 
>>> - I also wonder why we use both the term 'entry' and 'rule', why not
>>> pick one of them? You have for example rule-name (which is the key
>>> of the list but again comes last).
>> This is a bit of compromise between Cisco and Juniper terminology. In Cisco 
>> it is ACE and in Juniper term. But in the yang model and in the text we are 
>> using consistently one or the other word.
> 
> For the sake of clarity, I personally would prefer to have a single
> term. I think Linux packet filters call things rules. I think BSD
> packet filtering calls things rules. Wikipedia seem say that packet
> filters consist of filtering rules... So I guess I have a preference
> but I will not get a sleepless night over this.

Authors are Cisco/Juniper people, so were using that terminology and I believe 
that CSCO and JNPR are more used in networking then Linux :)

> 
>>> - Should there be features for ace-eth and ace-ipv4 and ace-ipv6 or do
>>> we expect that all implementations will always support all three?
>>> Another option would be to have the generic model completely without
>>> any protocol specific elements and to have separate models to
>>> augment in ipv4, ipv6, and ethernet specific ace ty

Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06

[Dean Bogdanovic]

Are there any other opinions on switching YANG version for ACL model from 1.0 
to 1.1? Would like to get more opinions on this, besides Martin.

Dean

> On Jan 8, 2016, at 1:26 PM, Martin Bjorklund  wrote:
> 
> Dean Bogdanovic mailto:ivand...@gmail.com>> wrote:
>> 
>>> On Jan 8, 2016, at 1:09 PM, Juergen Schoenwaelder
>>>  wrote:
>>> 
>>> On Fri, Jan 08, 2016 at 12:52:37PM +0100, Martin Bjorklund wrote:
>>>> Juergen Schoenwaelder  wrote:
>>>>> On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund wrote:
>>>>>> 
>>>>>> With YANG 1.1, a leafref can be marked as "require-instance false",
>>>>>> which allows a interface-state-ref to be used in config:
>>>>>> 
>>>>>>  type if:interface-state-ref {
>>>>>>require-instance false;
>>>>>>  }
>>>>>>  // + add description that explains what happens if there is no such
>>>>>>  //   instance
>>>>>> 
>>>>>> 
>>>>>> (NOTE: this doesn't work w/ pyang at the momement, I am working on a
>>>>>> fix)
>>>>>> 
>>>>> 
>>>>> And it would have to be if:interface-ref instead
>>>>> if:interface-state-ref
>>>>> I think.
>>>> 
>>>> No, I meant interface-state-ref.  This way you can put a filter on
>>>> non-configured interfaces.
>>>> 
>>> 
>>> But with require-instance false, this is also true for
>>> if:interface-ref.  If I preconfigure and interface, I might also want
>>> to preconfigure ACLs refering the preconfigure interface. And note
>>> that if:interface-state-ref refers to a config false leaf.
>> 
>> In this case we have to change to yang-version 1.1. The plan was to
>> have it for 1.0. Do we want to move the ACL model to YANG minimum
>> version 1.1?
> 
> I think it is ok.  We're fixing issues like this one in 1.1 so that we
> don't have to rely on various workarounds.  Note that the second WGLC
> for 1.1 just ended, w/ mostly minor proposed edits.
> 
> 
> /martin

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [yang-doctors] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06

[Dean Bogdanovic]

> On Jan 8, 2016, at 1:09 PM, Juergen Schoenwaelder 
>  wrote:
> 
> On Fri, Jan 08, 2016 at 12:52:37PM +0100, Martin Bjorklund wrote:
>> Juergen Schoenwaelder  wrote:
>>> On Thu, Jan 07, 2016 at 04:21:42PM +0100, Martin Bjorklund wrote:
 
 With YANG 1.1, a leafref can be marked as "require-instance false",
 which allows a interface-state-ref to be used in config:
 
   type if:interface-state-ref {
 require-instance false;
   }
   // + add description that explains what happens if there is no such
   //   instance
 
 
 (NOTE: this doesn't work w/ pyang at the momement, I am working on a
 fix)
 
>>> 
>>> And it would have to be if:interface-ref instead if:interface-state-ref
>>> I think.
>> 
>> No, I meant interface-state-ref.  This way you can put a filter on
>> non-configured interfaces.
>> 
> 
> But with require-instance false, this is also true for
> if:interface-ref.  If I preconfigure and interface, I might also want
> to preconfigure ACLs refering the preconfigure interface. And note
> that if:interface-state-ref refers to a config false leaf.

In this case we have to change to yang-version 1.1. The plan was to have it for 
1.0. Do we want to move the ACL model to YANG minimum version 1.1?
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06

[Dean Bogdanovic]

> On Jan 6, 2016, at 10:30 AM, Juergen Schoenwaelder 
>  wrote:
> 
> On Mon, Jan 04, 2016 at 07:23:38PM +0100, Eliot Lear wrote:
>> Hi Juergen,
>> 
>> On this point:
>> 
>> On 12/21/15 4:33 PM, Juergen Schoenwaelder wrote:
>> 
>>> And
>>> should the interface reference not use a more specific type than
>>> 'string’?
 Interface references can be many things, from standard naming we are 
 familiar, e.g. ge-1/0/0.1 to a numerical value like 13276. Leaving it as 
 string gives us most flexibility in that regards.
>>> I disagree that the goal here is most flexibility. We do have an
>>> interfaces data model in the IETF. Why are we avoiding to refer to it
>>> here?
>>> 
>> 
>> I think it would be helpful if you could be specific as to your
>> concern.  It is absolutely the case that the SNMP folk did an awful lot
>> of work on managing interfaces.  While I am not concerned about the form
>> of the name, I wonder if your concern is around some of the semantics,
>> but I can't tell.
>> 
> 
> My question is why the model does not use interface-ref or
> interface-state-ref defined in RFC 7223 but instead an opaque string
> to refer to an interface. Have we thought about the design tradeoffs?
> 
> My question is _not_ about how we deal with interface naming schemes,
> that discussion took place when RFC 7223 was created.

In the example where the ACL is attached to the interface, we are using 
interface-ref, so replacing interface in the metadata, can be easily done.

> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06

[Dean Bogdanovic]

> On Jan 4, 2016, at 10:24 PM, Eliot Lear  wrote:
> 
> Hi,
> 
> I guess what I'm hearing is that we should do a hopefully very short
> augmentation for domain names in the matches clause and standardize that
> separately.  Does that seem reasonable?

Yes, if you think there is a need for such a draft and IPR issue is cleared, WG 
adopts it, why not

Dean

> 
> Eliot
> 
> On 12/19/15 2:05 PM, Dean Bogdanovic wrote:
>> The basic design idea for the base model is structure that all vendors 
>> support. Some of the examples mentioned below, like FQDN, are not supported 
>> by all vendors and are protected by IPR (which I wasn’t aware of it). There 
>> are many possible match conditions that could be added to the base model, 
>> like Auth header in IPSec or IPSec encapsulation security payload to keep it 
>> with security. There are many match conditions in Class of Services as well. 
>> All these match conditions would have created more issues to come to 
>> consensus about the base model, so for that reason we went with the minimal 
>> model that would be easy for all vendors to implement.
>> 
>> Dean
>> 
>>> On Dec 18, 2015, at 5:21 PM, Sterne, Jason (Jason) 
>>>  wrote:
>>> 
>>> I'm not a fan of adding something like that in the base model.  Let's get a 
>>> basic model done and then we can consider an extension draft.  I'd think 
>>> that things like TCP flags, for example, would be a more natural & common 
>>> thing to add to an ACL model than a host name match so I can't see host 
>>> name being in there before TCP flags (which I'm not advocating for in the 
>>> base model).
>>> 
>>> I also don't think the metadata interface match should be in this base 
>>> model either.  That is out of place IMO.  The base model provides an ACL 
>>> that can then get associated with objects like interfaces (as in the 
>>> example in section A.3)
>>> I'd also suggest we consider making the actions 'deny' and 'permit' 
>>> presence containers instead of empty leafs.  That would allow easier 
>>> augmentations (e.g. additional 'permit' parameters for policy based 
>>> forwarding for example).
>>> 
>>> Regards,
>>> Jason
>>> 
>>> -Original Message-
>>> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Nadeau Thomas
>>> Sent: Thursday, December 17, 2015 10:53
>>> To: Lear Eliot
>>> Cc: Benoit Claise; RTG YANG Design Team; netmod WG
>>> Subject: Re: [netmod] Working group Last Call: 
>>> draft-ietf-netmod-acl-model-06
>>> 
>>> 
>>> You raise a good point. Do the contributors/editors have any thoughts 
>>> on this suggestion?
>>> 
>>> —Tom
>>> 
>>> 
>>>> On Dec 17, 2015:9:44 AM, at 9:44 AM, Eliot Lear  wrote:
>>>> 
>>>> 
>>>> 
>>>> On 12/17/15 2:45 PM, Nadeau Thomas wrote:
>>>>>   Do you mean an ASCII DNS name (versus an IP address w a mask)?
>>>> I was thinking of "host" in RFC 6021.
>>>> 
>>>> Eliot
>>>> 
>>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>> ___
>>> Rtg-dt-yang-arch mailing list
>>> rtg-dt-yang-a...@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch
>> 
> 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06

[Dean Bogdanovic]

The basic design idea for the base model is structure that all vendors support. 
Some of the examples mentioned below, like FQDN, are not supported by all 
vendors and are protected by IPR (which I wasn’t aware of it). There are many 
possible match conditions that could be added to the base model, like Auth 
header in IPSec or IPSec encapsulation security payload to keep it with 
security. There are many match conditions in Class of Services as well. All 
these match conditions would have created more issues to come to consensus 
about the base model, so for that reason we went with the minimal model that 
would be easy for all vendors to implement.

Dean

> On Dec 18, 2015, at 5:21 PM, Sterne, Jason (Jason) 
>  wrote:
> 
> I'm not a fan of adding something like that in the base model.  Let's get a 
> basic model done and then we can consider an extension draft.  I'd think that 
> things like TCP flags, for example, would be a more natural & common thing to 
> add to an ACL model than a host name match so I can't see host name being in 
> there before TCP flags (which I'm not advocating for in the base model).
> 
> I also don't think the metadata interface match should be in this base model 
> either.  That is out of place IMO.  The base model provides an ACL that can 
> then get associated with objects like interfaces (as in the example in 
> section A.3)
> I'd also suggest we consider making the actions 'deny' and 'permit' presence 
> containers instead of empty leafs.  That would allow easier augmentations 
> (e.g. additional 'permit' parameters for policy based forwarding for example).
> 
> Regards,
> Jason
> 
> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Nadeau Thomas
> Sent: Thursday, December 17, 2015 10:53
> To: Lear Eliot
> Cc: Benoit Claise; RTG YANG Design Team; netmod WG
> Subject: Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06
> 
> 
>   You raise a good point. Do the contributors/editors have any thoughts 
> on this suggestion?
> 
>   —Tom
> 
> 
>> On Dec 17, 2015:9:44 AM, at 9:44 AM, Eliot Lear  wrote:
>> 
>> 
>> 
>> On 12/17/15 2:45 PM, Nadeau Thomas wrote:
>>> Do you mean an ASCII DNS name (versus an IP address w a mask)?
>> 
>> I was thinking of "host" in RFC 6021.
>> 
>> Eliot
>> 
>> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> ___
> Rtg-dt-yang-arch mailing list
> rtg-dt-yang-a...@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06

[Dean Bogdanovic]

Juergen,

Please see answers inline

Dean

> On Dec 11, 2015, at 12:31 PM, Juergen Schoenwaelder 
>  wrote:
> 
> On Wed, Dec 09, 2015 at 08:27:04AM -0800, Nadeau Thomas wrote:
>> 
>>  This email initiates a NETMOD WG Last call for 
>> draft-ietf-netmod-acl-model-06. 
>> Please review the draft and make any comments to the list by Wednesday, 16 
>> December, 2015
>> by 8AM EST.
>> 
> 
> Technical
> 
> - I am not sure I personally like the acl-oper-data and ace-oper-data
>  containers in the middle of the config true tree. I understand that
>  operational state in this case is likely tightly bound to the
>  lifetime of the config state but I also generally prefer to have a
>  clean separation of config from state. But since I am not
>  implementing this, I am happy to leave the decision to those who
>  write the code.
> 
> - I would probably have used src-ipv4-prefix and dst-ipv4-prefix
>  instead of source-ipv4-network and destination-ipv4-network and
>  I would probably have used src-mac-address and src-mac-address-mask
>  and dst-mac-address and dst-mac-address-mask. Generally simple
>  src instead source and dst instead destination - lines up all
>  much more nicely.

I know that src and dst are pretty standard abbreviations, but have preference 
to use full words.

> 
> - I would have put the acl-name and acl-type first followed by the
>  entries list.

Can you please expand on this? Is there any major difference? OR just design 
choice?
> 
> - I also wonder why we use both the term 'entry' and 'rule', why not
>  pick one of them? You have for example rule-name (which is the key
>  of the list but again comes last).
This is a bit of compromise between Cisco and Juniper terminology. In Cisco it 
is ACE and in Juniper term. But in the yang model and in the text we are using 
consistently one or the other word.

> 
> - Should there be features for ace-eth and ace-ipv4 and ace-ipv6 or do
>  we expect that all implementations will always support all three?
>  Another option would be to have the generic model completely without
>  any protocol specific elements and to have separate models to
>  augment in ipv4, ipv6, and ethernet specific ace types. I actually
>  think this would make much more sense since you would not have a
>  module 'packet fields' but instead a clear extension of the
>  ietf-access-control-list module. You could also drop the examples
>  how to extend the core model since the ip and ethernet extensions
>  would already serve the purpose. You also would not need features
>  since an implementation advertises the extension modules.

We started early with such design, but then the WG feedback moved us to the 
current  design.

> 
> - The 'uses packet-fields:metadata' resolves to a leaf
>  'input-interface' which is of type string. Is this the only metadata
>  field we ever envision to be there? If so, why not make it part of
>  the base model? If not, what is the extensibility model here?  

It can be used for route filtering 

> And
>  should the interface reference not use a more specific type than
>  'string’?

Interface references can be many things, from standard naming we are familiar, 
e.g. ge-1/0/0.1 to a numerical value like 13276. Leaving it as string gives us 
most flexibility in that regards.

> 
> - Some implementations support the action to jump or goto other
>  acls. Is this not common enough to include it as a base action,
>  perhaps protected by a feature?

Yes among vendors, but it can be very specific. Example, in Juniper 
implementation there are two types of filters, classical and Fast Update 
Filters (FUF). Classic filters support (on specific HW platforms) filter as 
action, but FUF does not. Not all terms and not all actions are supported on 
FUFs. So you have to see what filter type and what platform it is, in order to 
such a specific action.
> 
> - In the example in section 4.3, does the CLI shown really help much?
>  The syntax is pretty system specific.

OTH, it is widely understood and self explanatory. 

> In the XML shown, can you not
>  leave out all the fields that are not set? This would remove a lot
>  of noise. I do not understand what having both actions deny and
>  permit at the same time means. Did you validate the example against
>  the data model? (I also find the keys at the end somewhat strange
>  and not that NETCONF XML serialization actually requires the keys to
>  be sent first.)
We used pyang sample xml skeleton to create the xml example.

Leaving both actions in the document is my fault. In the model, action is a 
choice, and it was a bad copy paste job. Didn’t choose :)
> 
> - The clarification whether the boundary port numbers are included in
>  a port range should be in the YANG model. The YANG model should also
>  say what it means if one of the ranges is not present. We should not
>  define the semantics by examples.
I’m loosing you here. We are stating in the model if the boundary port numbers 
are included in a port rang.


   con

Re: [netmod] IPR Check: draft-ietf-netmod-acl-model-06

[Dean Bogdanovic]

I’m not aware of any IPR related to this draft.

Dean

> On Dec 9, 2015, at 5:29 PM, Nadeau Thomas  wrote:
> 
> 
> 
> This mail starts the IPR poll on draft-ietf-netmod-acl-model-06.
> 
> Are you aware of any IPR that applies to draft-ietf-netmod-acl-model-06?
> If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
> 3979, 4879, 3669 and 5378 for more details)?
> 
> If you are listed as a document author or contributor please respond to this
> email explicitly regardless of whether or not you are aware of any relevant 
> IPR.
> The response needs to be sent to the NETMOD WG mailing list.  The document
> will not advance to the next stage until a response has been received from 
> each
> author and contributor.
> 
> If you are on the NETMOD WG email list but are not listed as an author or
> contributor, then please explicitly respond only if you are aware of any IPR 
> that
> has not yet been disclosed in conformance with IETF rules.
> 
> Thank you,
> 
> Kent and Tom, NETMOD WG Chairs
> 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Rtg-dt-yang-arch] draft-ietf-netmod-routing-cfg

[Dean Bogdanovic]

Martin,
> n Nov 24, 2015, at 4:24 AM, Martin Bjorklund  wrote:
> 
> Hi,
> 
> "Acee Lindem (acee)"  wrote:
>> We had a lot of good discussions at IETF 94 with respect to the
>> ietf-routing and how it could be augmented in the future to support I2RS.
>> These discussions are ongoing.
>> 
>> One current change that I would like to propose is to change the base
>> instance container from routing-instance to networking-instance.
> 
> Is the idea to simply rename the "routing-instance" container to
> "networking-instance"?
> 
> Then we would have:
> 
>   +--rw routing
>  +--rw networking-instance
> 
> Would you keep the top-level name "routing”?

Yes, routing is not confined to IP only. TRILL and PBB do routing at MAC layer, 
so routing as top level domain can stay. OTH, routing instance is well defined 
term in the industry, so there is a need to have a term that can encompass L2 
and L3.

Dean

> 
> 
> 
> 
> /martin
> 
> 
> 
> 
>> This
>> would provide an instance definition that could be augmented for L2
>> protocols and service functionality as well as L3. It is also consistent
>> with the term used in both
>> https://www.ietf.org/id/draft-rtgyangdt-rtgwg-device-model-01.txt and
>> https://www.ietf.org/id/draft-openconfig-rtgwg-network-instance-01.txt.
>> 
>> Thanks,
>> Acee 
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> 
> 
> ___
> Rtg-dt-yang-arch mailing list
> rtg-dt-yang-a...@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] acl-model-5: remove time-range and put input-interface behind an if-feature

[Dean Bogdanovic]

Jason and I spoke on this issue and the question is

Do we want to add time range directly to the standard model or create a 
separate model for time range that can be then applied to other different 
nodes? If we decide to keep it as is, then the ask is to if-feature time range.

If there will not be any replies on the mailing list, this will be one question 
for discussion at the WG mtg

Dean

> On Oct 28, 2015, at 2:13 PM, Sterne, Jason (Jason) 
>  wrote:
> 
> Hi all,
>  
> This comment is still applicable to the recent version 5 draft.
>  
> Any other opinions about this ?  Just wanted to bring it up again a little 
> before IETF94 since this draft is on the agenda.
>  
> Regards,
> Jason
>  
> From: Sterne, Jason (Jason) 
> Sent: Friday, October 02, 2015 16:08
> To: Sterne, Jason (Jason); netmod@ietf.org 
> Subject: draft-ietf-netmod-acl-model-03: remove time-range and put 
> input-interface behind an if-feature
>  
> (splitting point (A) out of the “RE: [netmod] A few other misc. comments on   
>   draft-ietf-netmod-acl-model-03” thread)
>  
> Hi all,
>  
> I’d propose we remove time-range from the model for a number of reasons:
> 1)  I don’t think we should build individual time-range functions all 
> over the place in individual modules (likely in slightly different ways).  If 
> we want time-range type functions then I think we should define that in a 
> more generic way that can apply to any configuration items and keep it out of 
> individual modules.
> 2)  Maybe time range functions are more appropriate up in the 
> client/controller layer anyways
> 3)  This is not standard base functionality that is uniformly supported 
> in devices that use ACLs
>  
> The remaining meta-data item (input-interface) should probably also be 
> removed (same reason #3 as above).  At minimum it should an if-feature.
>  
> Regards,
> Jason
>  
> From: netmod [mailto:netmod-boun...@ietf.org 
> ] On Behalf Of Sterne, Jason (Jason)
> Sent: Sunday, July 19, 2015 13:43
> To: netmod@ietf.org 
> Subject: [netmod] A few other misc. comments on draft-ietf-netmod-acl-model-03
>  
> Hi all,
>  
> I brought up ACL types and ACE numerical IDs in other separate email threads. 
>  This one is for a set of other misc. comments (one functional, the rest are 
> more editorial).
>  
> A) Please make the metadata optional with an if-feature (or make each of 
> input-interface & time-range their own if-features – that is probably 
> better).  Or drop those out of the model and leave them to augmentations.
> If we do keep input-interface in the model as an if-feature then:
> - should we import ietf-interfaces with just the prefix"if" ?  That is the 
> prefix in the ietf-interfaces module and what is used in the routing model 
> for example.
> - shouldn’t the input-interface be a leafref (e.g. if:interface-ref) ?
>  
> [>>JTS] …snip…
>  
> ___
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod 
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Fwd: I-D Action: draft-ietf-netmod-acl-model-04.txt

[Dean Bogdanovic]

This version contains comments and suggestions from mailing list and last mtg 
in Prague

Dean

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: [netmod] I-D Action: draft-ietf-netmod-acl-model-04.txt
> Date: October 19, 2015 at 10:46:07 AM EDT
> To: 
> Cc: netmod@ietf.org
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the NETCONF Data Modeling Language Working Group 
> of the IETF.
> 
>Title   : Network Access Control List (ACL) YANG Data Model
>Authors : Dean Bogdanovic
>  Kiran Agrahara Sreenivasa
>  Lisa Huang
>  Dana Blair
>   Filename: draft-ietf-netmod-acl-model-04.txt
>   Pages   : 28
>   Date: 2015-10-17
> 
> Abstract:
>   This document describes a data model of Access Control List (ACL)
>   basic building blocks.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-acl-model-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-04
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] more Questions about draft-ietf-netmod-acl-model-03

[Dean Bogdanovic]

> On Sep 24, 2015, at 5:29 PM, Juergen Schoenwaelder 
>  wrote:
> 
> On Thu, Sep 24, 2015 at 08:51:45PM +, Linda Dunbar wrote:
>> 
>> Dean, et al,
>> 
>> I have a few questions about the draft:
>> 
>> 1.  Does the following statement in the Section 7 IANA Consideration 
>> make  "ietf-acl" equivalent to the long name 
>> "urn:ietf:params:xml:ns:yang:ietf-access-control-list"?
>> 
>> urn:ietf:params:xml:ns:yang:ietf-access-control-list prefix: ietf-acl
>> 
> 
> No. See RFC 6020 sections 7.1.3 and 7.1.4 how 'namespace' and 'prefix'
> statements work. The IANA section only registers the values declared
> in the YANG modules.
> 
>> If the answer is YES, can the example in Section 4.3 can use "ietf-acl" 
>> directly instead of the long name?
>> i.e.
>> 
> 
> The example does not match the YANG definition, it is broken.
>> Does the "1" in ":1.0" above mean "yang-version 1" defined in the "module 
>> ietf-access-control-list"?  what about the "0" a?
> 
> The :1.0 likely should not be there. There is not tagging of the YANG
> language version used to define the data model in the payload

We have used pyang with -f sample-xml-skeleton and then updated it with the 
example info. I’ll update the pyang compiler and redo the output. 

Dean
> .
> 
>> 2.  The beginning of the module has "prefix acl". Does it mean that 
>> "acl" is equivalent to "ietf-access-control-list"?
> 
> Essentially yes.
> 
>> file "ietf-access-control-l...@2015-05-03.yang"
>> module ietf-access-control-list {
>> yang-version 1;
>> namespace "urn:ietf:params:xml:ns:yang:ietf-access-control-list";
>> prefix acl;
>> 
>> 
>> 3.  With "prefix acl" listed right after the "namespace", does the acl 
>> in "ietf-acl:acl" (in Appendix A.1) actually mean the whole name space?
>> 
> 
> If you have in a YANG module
> 
>   import  {
> prefix foo;
>   }
> 
> then you can refer to  defined in  via
> 
>   foo:
> 
> but if you declare the namespace of the module you are defining an
> a prefix for it, that is
> 
>   module  {
> namespace ;
> prefix bar;
> 
>   }
> 
> and I (a) suggest that modules importing  should use the
> prefix 'bar' and (b) I allow to refer inside  to things
> defined in  using the prefix 'bar:' (which is however
> usually not needed since you can simply omit the prefix for anything
> locally defined).
> 
> /js
> 
> -- 
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG coordination feedback on draft-openconfig-netmod-opstate-01

[Dean Bogdanovic]

> On Sep 11, 2015, at 12:07 PM, Ladislav Lhotka  wrote:
> 
> Martin Bjorklund  writes:
> 
>> Sam Aldrin  wrote:
>>> 
 On Sep 10, 2015, at 4:13 PM, Mahesh Jethanandani
  wrote:
 
 
> On Sep 10, 2015, at 12:43 PM, Carl Moberg (camoberg)
> mailto:camob...@cisco.com>> wrote:
> 
> Now, think about configuration parameters that have applied
> configuration located in more than one place. Let’s say you change the
> IP address of an interface, it is likely that this configuration will
> be passed around as input to a handful of subsystems (e.g. the DHCP
> server, some routing daemons that may bind to specific IP
> addresses). Is the intended and applied in sync when a specific subset
> of those configurations are updated. What happens if there’s a partial
> failure?
 
 This is a good example. Another example, and somebody on the call
 today started to ask this but got cut off, relates to interfaces on
 the device.
 
 Interfaces already exist on a system. As such they have a
 configuration (default values) that exists on them. They are enabled
 when configuration gets applied on them. They will have applied
 configuration but no intended configuration. Should this be reported?
 
 Yet another example is of a BFD session that gets bootstrapped because
 of a ping. There is no intended configuration, but the session exists
 and a query of configuration in this case would return a valid BFD
 session.
 
 Could we get some clarification (with examples, preferably) on what
 the expectation is from a openconfig opstate perspective?
>>> 
>>> Section 7 of draft-openconfig-netmod-opstate talks about
>>> that. Specifically, #3 talks about the interface question you raise..
>> 
>> I think it is important that we understand how this 'applied config'
>> is supposed to be populated on a device.
>> 
>> First it was said that it there is just one way they can be different;
>> time (on async systems).  After some discussion I think there are now
>> four ways:
>> 
>>  1.  Time (in async systems).
>> 
>>  2.  Hardware.  If something is in intended config but there is no hw
>>  present, it is not in applied.
>> 
>>  3.  System-controlled stuff.  If the system auto-creates an
>>  interface (for example), it will be in the applied config but
>>  not in intended.
>> 
>>  4.  "Template substitution"; the draft uses the example of an 'all'
>>  interface that exists in intended config but not in applied.
>> 
>> 
>> Then Lada brought up the example of ip addresses.  It was mentioned
>> on the call that for ip addresses there would be three lists; one for
>> intended, one for applied, and one in derived state, where the one in
>> derived state is what the box *really* uses.  So for example if it
>> gets an ip from dhcp, it will be in the derived state list, but not in
>> applied config.
> 
> Right. After yesterday's interim I am much less in favour of this
> intended/applied proposal because
> 
> - as you say, applied configuration falls short of representing "the
>  state that the network element is actually in",
> 
> - states in which intended and applied configuration can be out of sync
>  are only transient. In the use cases I am interested in, such states
>  could be relatively normal and last long.
> 
> Another example that comes to my mind are static routes: an operator
> needs to know that a configured static route got installed, and this can
> be verified only by inspecting a corresponding RIB (operational
> state). I don't see how a copy of static routes in applied configuration
> could help.
> 
> I agree with Juergen that what we need is a clever representation of
> operational state and this is hard work that needs to be done by experts
> on an ad hoc basis. That's why I am also sceptical about the possibility
> of having fixed and universally applicable relationships between
> configuration and operational state.

This is very true! As the networking is done today by vendors, achieving 
universally applicable relation between config and operational state is very 
hard. Openconfig folks want to get a single tree with of variables and it is 
lot of work for existing vendors to translate between customer desires and 
current vendor implementations, having separate operational and config models.

We should ask ourselves are we ready to work on an object oriented networking 
model with getter and setter functions and if vendors are ready to support such 
model.

Dean

> 
> Lada
> 
>> 
>> Why is this ip-address list different from the interface list?  Why
>> was it enough with two lists for interfaces, but we need three for ip
>> addresses?
>> 
>> 
>> /martin
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 

Re: [netmod] ACL model problem

[Dean Bogdanovic]

Lada,

Our original intention was to be able to define wild cards for source and 
destination ports, but what you are suggesting is also an option and I agree 
your suggestion is better, so adding presence statement to port containers, as 
in example below, would be the right solution

grouping acl-transport-header-fields {
description
  "Transport header fields";
container source-port-range {
  presence “Enables source port range”;
  description
"Inclusive range representing source ports to be used.
When only lower-port is present, it represents a single port.";
  :
  :

Have fixed it in the model and will update on Monday the draft

Dean

> On Jul 14, 2015, at 3:26 PM, Ladislav Lhotka  wrote:
> 
> Hi,
> 
> the module ietf-packet-fields.yang in draft-ietf-netmod-acl-model-03
> still has the problem that I discovered in the previous revision:
> 
> - Containers "source-port-range" and "destination-port-range" are both
>  mandatory because the child leaf "lower-port" in each is mandatory. I
>  think this wasn't intended. One solution would be to make both of them
>  containers with presence.
> 
> (see
> https://mailarchive.ietf.org/arch/msg/netmod/ShROtXH7aMNDs5HoIiTUa99X0JY)
> 
> Even though the tree in sec. 3.1 displays "lower-port" as optional, in
> reality ietf-packet-fields.yang still has this leaf as "mandatory true;"
> in both "source-port-range" and "destination-port-range".
> 
> Lada
> 
> -- 
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] follow-up from virtual interim and i2rs discussions

[Dean Bogdanovic]

On Jun 23, 2015, at 5:57 PM, Andy Bierman 
mailto:a...@yumaworks.com>> wrote:



On Tue, Jun 23, 2015 at 2:15 PM, Dean Bogdanovic 
mailto:de...@juniper.net>> wrote:

On Jun 23, 2015, at 1:50 PM, Andy Bierman 
mailto:a...@yumaworks.com>> wrote:





Yup, and reality can change when you swap FRUs.

>>   actual state + counters => operational state
>This should be:
>  actual state + statistics => operational state
>Statistics is largely dominated by counters but not only counters.

Sound good.

Precise language is so important, so I think well-defined terms
matter.  Then again, one can be completely precise while being
completely useless, like my current favorite word, sphygmomanometer.


IMO getting the concepts right needs to be done first.
Picking the right terms helps if the concepts are right in the first place.

The thermometer example I have given many times needs to be understood.

Let's say the same leaf "temperature" is used in all datastores.
The "running" temperature is the configured desired value.
The "operational" temperature is the current value read from a sensor.

So where does "ephemeral" temperature fit in?  Does this setting override
the desired temperature and have no affect on the operational sensor value?
Or does it over-write the sensor value to the device is now lying
when it reports the operational temperature?

Andy,

ephemeral "temperature" would overwrite which ever data store was read to set 
"running" temperature. If the "temperature" was read from "startup" config, 
then ephemeral would mask the "temperature" leaf in the startup and running 
would read from ephemeral data store.
One of the issues I personally ran into while at Juniper was people perception 
that configuration is persistent. Ephemeral config was very confusing to 
Juniper customers, as I was trying to explain them, that if they change the 
ephemeral and device reboots, the configuration is gone. For many of them, it 
was running config, but it is not. Another issue was no rollback. Actually, 
there is only rollback 0, which is done automatically by the system, if the 
config commit is not successful.



IMO it is quite obvious that ephemeral data is configuration, not state.

I would not say that ephemeral data is config. It is temporary state developers 
want to change the device state too.



Here is a simple example.
I hope it is not too abstract.

No, it is not

   leaf admin-temp {
  type uint32;
   units "degrees Celsius";
  description "The configured temperature.";
  }

>From YANG perspective, it would be exactly the same, in persistent config and 
>ephemeral data store

the only difference is in NETCONF RPC

for persistent config


and for ephemeral


As there can be multiple ephemeral instances.

   leaf oper-temp {
   type uint32;
   units "degrees Celsius";
   config false;
   description "The measured temperature.";
  }


Would your I2RS solution be able to over-ride the admin-temp
with a temporary ephemeral value?

 When commit is executed in ephemeral instance, merge between persistent and 
ephemeral is being executed, with priority for values coming from ephemeral 
data store.

Makes sense?

Describe the solution
in detail.  Provide all YANG and all protocol operations that would be used



Thx

Dean


Andy


Operational state is always read-only.



Thanks,
 Phil


Andy


___
netmod mailing list
netmod@ietf.org<mailto: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



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] follow-up from virtual interim and i2rs discussions

[Dean Bogdanovic]

On Jun 23, 2015, at 1:50 PM, Andy Bierman 
mailto:a...@yumaworks.com>> wrote:





Yup, and reality can change when you swap FRUs.

>>   actual state + counters => operational state
>This should be:
>  actual state + statistics => operational state
>Statistics is largely dominated by counters but not only counters.

Sound good.

Precise language is so important, so I think well-defined terms
matter.  Then again, one can be completely precise while being
completely useless, like my current favorite word, sphygmomanometer.


IMO getting the concepts right needs to be done first.
Picking the right terms helps if the concepts are right in the first place.

The thermometer example I have given many times needs to be understood.

Let's say the same leaf "temperature" is used in all datastores.
The "running" temperature is the configured desired value.
The "operational" temperature is the current value read from a sensor.

So where does "ephemeral" temperature fit in?  Does this setting override
the desired temperature and have no affect on the operational sensor value?
Or does it over-write the sensor value to the device is now lying
when it reports the operational temperature?

Andy,

ephemeral "temperature" would overwrite which ever data store was read to set 
"running" temperature. If the "temperature" was read from "startup" config, 
then ephemeral would mask the "temperature" leaf in the startup and running 
would read from ephemeral data store.
One of the issues I personally ran into while at Juniper was people perception 
that configuration is persistent. Ephemeral config was very confusing to 
Juniper customers, as I was trying to explain them, that if they change the 
ephemeral and device reboots, the configuration is gone. For many of them, it 
was running config, but it is not. Another issue was no rollback. Actually, 
there is only rollback 0, which is done automatically by the system, if the 
config commit is not successful.



IMO it is quite obvious that ephemeral data is configuration, not state.

I would not say that ephemeral data is config. It is temporary state developers 
want to change the device state too.

Thx

Dean

Operational state is always read-only.



Thanks,
 Phil


Andy


___
netmod mailing list
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
https://www.ietf.org/mailman/listinfo/netmod