Re: [netmod] ietf-access-control-l...@2017-10-03.yang : Can access-lists use a grouping?

[Mahesh Jethanandani]

Ranga,

Is there a reason why you do not want to consider augmenting the model, 
particularly since you seem to want to use the entire model?

> On Oct 31, 2017, at 8:39 PM, M. Ranganathan  wrote:
> 
> Re-posted from OPSAWG list :
> 
> 
> Hello,
> 
> In the file  
> 
> ietf-access-control-l...@2017-10-03.yang
> 
> I see that access-lists is directly defined as a collection.
> 
> 
> May I suggest making a grouping (say access-lists-grouping) and use a "uses" 
> statement in access-lists.
> 
> The use-case for this change request - I would like to use the grouping in 
> another YANG model using a "uses" statement.
> 
> Thanks in advance for considering it.
> 
> Regards,
> 
> Ranga.
> 
> -- 
> M. Ranganathan
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanand...@gmail.com

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

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

[Andy Bierman]

Hi,

I have read this draft a few times.
I have not implemented the draft but it seems reasonably constrained.

here are some comments.

Sec 1: seems like a lot of background on YANG and then some explanation
of the solution.  The problem statement is never really explained.
Some discussion of building blocks for virtual servers might help.

Sec. 3.3: there are no examples of multiple level schema -mounts.
What is the use-case for this complexity?

Sec. 4: an instance document showing the config for the example would help

Sec. 5: A NETCONF example of an RPC converted to action would help.
Also mention action converted to deeper nested action would help.
Sec. A.4 has a very terse RESTCONF example.

Sec. 8: There are no examples using the mount-point extension-stmt
Why is this restriction in the text? It is not explained.

  The 'mount-point' statement MUST NOT be used in a YANG
  version 1 module, neither explicitly nor via a 'uses'
  statement.


I do not understand why the mount-point subtree is needed twice in the YANG
module.
Why is the list duplicated under each schema entry?
An example showing the entire YANG module would help.
Seems like a lot of duplication of the YANG library.

Why is the entire schema-mounts container config=false?
There is no standard way to configure the schema mounts?
All this data is configured via proprietary models, probably
with even more copies of the YANG library?



Andy




On Fri, Oct 20, 2017 at 2: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] WG Last Call: draft-ietf-netmod-acl-model-14

[Mahesh Jethanandani]

Kristian,

> On Nov 1, 2017, at 10:27 PM, Kristian Larsson  wrote:
> 
> I think there's a problem with the current approach for features
> where it conflates the limitations of the device with the
> limitations of an attachment point.  Ultimately it is the
> limitations of the attachment point that matter. Creating an ACL
> in config on a device doesn't actually mean anything until you
> attach it somewhere.
> 
> It's not hard to imagine a device where different limitations
> apply, let's say a fairly simple Ethernet switch built on some
> commodity chip. It consists of, say:
> * 24 * 10GE on a commodity chip
> * some control plane (a x86 PC) connected to that commodity chip
> 
> The commodity chip supports matching ethernet headers, so ACLs
> attached to those ports are "eth-acl". The control plane on the
> other hand supports complex matching on anything you can imagine.
> What YANG features should such a device advertise?

The feature statement is a “static” statement that a particular implementation 
defines for what it supports across the entire device. YANG does not allow for 
a feature to be defined for a particular node in the model. 

For the behavior you desire, one would define a feature statement that covers 
everything the device supports, and will have to use must statements to control 
what parts of the model get supported by the ports and what parts of the model 
are supported in the control plane. That will usually be a implementation level 
detail that this model cannot cover.

Thanks.

> 
>   kll
> 
> 
> 
> 
> On Wed, Nov 01, 2017 at 02:26:31PM +0100, Kristian Larsson wrote:
>> Mahesh,
>> 
>> On Wed, Nov 01, 2017 at 05:13:18PM +0630, Mahesh Jethanandani wrote:
>>> I think there is confusion in how the ACL model is going to be
>>> implemented by vendors and used by customers.
>>> 
>>> As Eliot alluded to, the model is trying to address the issue
>>> of the capabilities of each platform as they exist across the
>>> industry but also within each vendor. So the first thing an
>>> implementation would do is to pick which feature they do
>>> support. A low end platform that supports only layer 2 ACL will
>>> pick l2-acl as their feature, while a high end router capable
>>> of support l2 and l3, ipv4 and ipv6 ACL will declare
>>> l2-l3-ipv4-ipv6 as the feature they support. That pretty much
>>> takes out all the other containers in the matches container.
>>> The additional features they might want to choose include
>>> support for TCP, UDP and ICMP. For a high end router this boils
>>> down to having definitions for
>>> 
>>> - ethernet
>>> - ipv4
>>> - ipv6
>>> - tcp
>>> - udp
>>> - icmp
>>> 
>>> which is the list you have in mind, but this time making sure
>>> that the platform is capable of supporting each one of the
>>> definitions. Imagine if the low end platform advertised a model
>>> for all the above capabilities only to reject them when you
>>> tried to configure a ipv6 address that it already knows it
>>> cannot support.
>> 
>> You imply that the low end platform would advertise features that
>> it doesn't support. Why would it do that?
>> 
>> I don't suggest removing features - only restructure where the
>> data is held.  In my example, under the ethernet container I can
>> do: if-feature "eth-acl or eth-ipv4-acl..."; to check if the
>> device supports a given feature so why are you saying that we
>> need different containers for the ethernet matching part of an
>> ACL of type eth-acl vs say eth-ipv4-acl?
>> 
>> Right now the features themselves affect the structure of the
>> model and thus the data, which I rather dislike. The config to
>> match e.g. ethernet headers should always go in the same place.
>> 
>> The model gives the illusion of supporting "unified" ACLs but
>> actually doesn't at all.
>> 
>> 
>>> Similarly the condition on tcp/udp/icmp container is to make
>>> sure the platform is capable of supporting them. Only if the
>>> platform declares tcp-acl, udp-acl, and icmp-acl feature, will
>>> those containers be visible from a configuration perspective.
>> 
>> And if the device supports all of those features I can write an
>> ACE that matches on TCP flags at and ICMP types.. and it would
>> validate according to the model but cleary makes no sense.
>> 
>>> The acl-type is used as a check to make sure the user is aware
>>> what kind of ACL the platform supports and the ACL they are
>>> trying to configure matches the acl-type. If the platform
>>> declared the feature l2-acl and if the user tries to set the
>>> ACL type to l2-l3-ipv4-ipv6 then the configuration would be
>>> rejected.
>> 
>> Another way of structuring this is to have completely different
>> lists of ACLs where each type of ACL is its own list, e.g.
>> * eth-acl
>> * ipv4-acl
>> * ipv6-acl
>> * eth-ipv4-ipv6-acl
>> 
>> What advantage do you think your currently proposed model holds
>> over such an approach?
>> 
>> What are your thoughts on the attachment point using two leaves?
>> Are you satisfied with this?
>

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

[Mahesh Jethanandani]

Juergen,

> On Nov 1, 2017, at 5:52 PM, Juergen Schoenwaelder 
>  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. 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. 

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 container (to support the if-feature statement for that 
container), the tree would look like this:

||  +--rw l2-acl {l2-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 ipv4-acl {ipv4-acl}?
||  |  +--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 ipv6-acl {ipv6-acl}?
||  |  +--rw dscp?   inet:dscp
| 

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] WG Last Call: draft-ietf-netmod-schema-mount-07

[Juergen Schoenwaelder]

Does 'Yes/support' imply "I've reviewed this document and believe it
is ready for publication"?

/js

On Wed, Nov 01, 2017 at 03:49:53PM -0400, Xufeng Liu wrote:
> Yes/support.
> 
> Thanks,
> - Xufeng
> 
> > -Original Message-
> > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
> > Sent: Friday, October 20, 2017 5:38 PM
> > To: netmod@ietf.org
> > Subject: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07
> > 
> > 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

-- 
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] draft agenda posted

[Kent Watsen]

The draft agenda for the NETMOD sessions has been posted:

  https://datatracker.ietf.org/meeting/100/materials/agenda-100-netmod/

There are no sessions listed for the three NMDA-update
model drafts (rfc7223bis, rfc7277bis, rfc8022bis).  They
will be covered together by the chairs in the beginning
of Session 1.

Cheers, 
Kent (and Lou)



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

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

[Acee Lindem (acee)]

Hi Xufeng, 

I support publication of this document.

Thanks,
Acee 

>>-Original Message-
>> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
>> Sent: Friday, October 20, 2017 5:38 PM
>> To: netmod@ietf.org
>> Subject: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07
>> 
>> 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

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

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

[Xufeng Liu]

Yes/support.

Thanks,
- Xufeng

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen
> Sent: Friday, October 20, 2017 5:38 PM
> To: netmod@ietf.org
> Subject: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07
> 
> 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] Action and RPC statements

[Juergen Schoenwaelder]

On Wed, Nov 01, 2017 at 06:00:15PM +, Alexander Clemm wrote:
> 
> > -Original Message-
> ...
> > > That is an interesting question.
> > >
> > > To describe this as a concrete example, if you have a single config
> > > true YANG list for dynamic/configuration subscriptions then a
> > > subscription can be created either via configuration or as an RPC 
> > > operation.
> > >
> > > I would probably classify this as "learned", and I think that we could
> > > extend the definition of the "learned" origin to cover this case.
> > 
> > I do not think any changes are needed, section 5.3.4 is pretty clear that 
> > the
> > origin 'intended' applies to configuration provided by . If you at
> > the options, there is pretty much only 'learned' applicable.
> > 
> 
> It may be clear that "intended" may not be the right choice, but what is?  I 
> think it does not hurt to be explicit about it.  This way, people don't have 
> to guess if it should be learned, or maybe system, or possibly even unknown.  
> In its current definition, "learned" only talks about "protocol interactions 
> with other systems ... such as routing protocols, DHCP, etc." If it is 
> "learned" then update its definition to something like
> 
> learned: represents configuration that has been learned via
>   protocol interactions with other systems, including protocols such
>   as link-layer negotiations, routing protocols, DHCP, etc, or as a side 
> effect of RPCs. 
>

I do think that the choice is clear enough if you read the origin
value definitions. The point is that we can't cover all cases. Even if
we name side effects of RPCs (which is BTW not correct since some RPCs
do as a side effect modify configuration datastores), the next person
is going to say we do not cover YANG actions or certain SNMP sets or.

/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] Action and RPC statements

[Alexander Clemm]

Thanks, Rob
--- Alex

From: Robert Wilton [mailto:rwil...@cisco.com]
Sent: Wednesday, November 01, 2017 4:43 AM
To: Alexander Clemm ; Martin Bjorklund 
; a...@yumaworks.com; netmod@ietf.org; Randy Presuhn 
; Phil Shafer 
Subject: Re: [netmod] Action and RPC statements


Hi Alex,

On 31/10/2017 17:36, Alexander Clemm wrote:
Hi Rob,

A few comments, inline

--- Alex

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Robert Wilton
Sent: Tuesday, October 31, 2017 7:14 AM
To: Martin Bjorklund ; 
a...@yumaworks.com; 
netmod@ietf.org; Randy Presuhn 

Subject: Re: [netmod] Action and RPC statements


Hi,

Here is another attempt for proposed text for Actions/RPC statements in NMDA.



6.2 Invocation of RPC Operations

This section updates section 7.14 of RFC 7950.

RPCs MAY be defined as affecting the contents of a specific datastore,
any configuration datastore (e.g., ), or any datastore
(e.g., ).  The RPC definition specifies how the RPC input
data is interpreted by the server.

 why “e.g., ”?  Does  affect the contents of the 
datastore – I thought it just gets data, hence this example is not ideal.

There is also no mention about the source of the “in” parameters.  It probably 
makes sense to mention that explicitly.

Perhaps something along the lines of “RPCs MAY be defined as _relating_ to the 
contents of a specific datastore….   Input data resolves to , as 
does output data, as do RPC side effects“.  Then below

“RPCs definitions that do not explicitly state an affected
datastore(s) _refer_to_  the general operational state of the server.”
Yes, that makes sense.





One other comment, it would be good to also indicate that when an RPC leads to 
modification of data nodes, what the “origin” of those modifications is.
That is an interesting question.

To describe this as a concrete example, if you have a single config true YANG 
list for dynamic/configuration subscriptions then a subscription can be created 
either via configuration or as an RPC operation.

I would probably classify this as "learned", and I think that we could extend 
the definition of the "learned" origin to cover this case.

Thanks,
Rob







RPCs definitions that do not explicitly state an affected
datastore(s) modify the general operational state of the server.
Hence, if any RPC input data relates to data node instances then
those would generally resolve to data node instances in the
 data tree.


6.3 Invocation of Actions

This section updates section 7.15 of RFC 7950.

In YANG data models, the "action" statement may appear under "config
true" and "config false" schema nodes.  While instances of both
schema nodes may appear in , instances of "config true"
schema nodes may also appear in other datastores.

Actions are always invoked on a data node instance that exist in the
 data tree.  The behavior defined by an action statement
is generally expected to affect the operational state of the server
rather than directly modifying the contents of any configuration
datastore.



On a related note, I also want to confirm that it is right that RPC input data 
is always checked against operational:

Section 6.1. of the NMDA draft states:




   o  If the XPath expression is defined in a substatement to an "input"

  statement in an "rpc" or "action" statement, the accessible tree

  is the RPC or action operation instance and all operational state

  in the server.  The root node has top-level data nodes in all

  modules as children.  Additionally, for an RPC, the root node also

  has the node representing the RPC operation being defined as a

  child.  The node representing the operation being defined has the

  operation's input parameters as children.


Is  always the right datastore to evaluate RPC input/output data 
relative to?  For most RPCs this seems to be the right choice by default but it 
also seems plausible that someone may wish to define an RPC that wants to 
validate its input parameters against the contents of another datastore.

An example could be an "is-applied" RPC that takes a path to a subtree in 
 or  and checks whether the configuration for that subtree 
is fully represented in .

Thanks,
Rob


On 27/10/2017 09:33, Martin Bjorklund wrote:

Andy Bierman  wrote:

On Thu, Oct 26, 2017 at 11:22 AM, Randy Presuhn <

randy_pres...@alumni.stanford.edu> 
wrote:



Hi -



On 10/26/2017 10:44 AM, Robert Wilton wrote:



Hi ,



Separating out the issue regarding which datastore action and RPC apply

to, we propose the following NEW text to the datastores draft:



6.2 Invocation of Actions and RPC Operations



   This section updates section 7.15. of RFC 7950.



   In YANG data models, the "action" statement may appear under "config

   true" and "config false" schema nodes.  While instances of both

   s

Re: [netmod] Action and RPC statements

[Alexander Clemm]

> -Original Message-
...
> > That is an interesting question.
> >
> > To describe this as a concrete example, if you have a single config
> > true YANG list for dynamic/configuration subscriptions then a
> > subscription can be created either via configuration or as an RPC operation.
> >
> > I would probably classify this as "learned", and I think that we could
> > extend the definition of the "learned" origin to cover this case.
> 
> I do not think any changes are needed, section 5.3.4 is pretty clear that the
> origin 'intended' applies to configuration provided by . If you at
> the options, there is pretty much only 'learned' applicable.
> 

It may be clear that "intended" may not be the right choice, but what is?  I 
think it does not hurt to be explicit about it.  This way, people don't have to 
guess if it should be learned, or maybe system, or possibly even unknown.  In 
its current definition, "learned" only talks about "protocol interactions with 
other systems ... such as routing protocols, DHCP, etc." If it is "learned" 
then update its definition to something like

learned: represents configuration that has been learned via
  protocol interactions with other systems, including protocols such
  as link-layer negotiations, routing protocols, DHCP, etc, or as a side 
effect of RPCs. 

--- Alex

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

Re: [netmod] Action and RPC statements

[Andy Bierman]

Hi,

So a server will be required to guess the correct datastore until it
finds the right one that matches the action instance?

   
   
  
 10
 
candidate
 
  



The server will guess the datastore in some proprietary order and parse
instances of /top/ and /top/list1.  Then it finds the  action
and parses the input to get to the datastore and find out the real datastore
to use.  If the server guessed wrong, then it reparses the  against
the requested datastore.  Hopefully the schema trees match up.

Will vendors do all the extra work required to support this sort of thing?
I doubt it.


Andy




On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer  wrote:

> Robert Wilton writes:
> >ii) However, as far as I can see, it doesn't make sense for an action to
> >directly affect the contents of any configuration datastore, that should
> >be done via a purpose built rpc (like edit-config).
>
> An example action would be to retrieve the  fingerprint of an ssh
> key.  I might want to get the fingerprint of a key in 
> before I commit it.
>
> Or I could have an action that sets the SNMPv3 auth key to a random
> value, and I want to invoke that action against .
>
> Seems like  might also be an interesting place to target
> actions, but I can't think of a good example.
>
> There are always scenarios where something is useful, and the problem
> with ruling it out is that it becomes needed at some later point.
> We've a habit of ruling out things and later wishing we had them.
>
> Is the easy fix to just put a datastore leaf under rpc/action and
> have it default to operational?  Any specific RPC can define its
> own datastore leaf of hard-code the database in the description
> (explicitly or implicitly ), but the  RPC only
> gets this if we make a new parameter for it.
>
> Thanks,
>  Phil
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kristian Larsson]

I think there's a problem with the current approach for features
where it conflates the limitations of the device with the
limitations of an attachment point.  Ultimately it is the
limitations of the attachment point that matter. Creating an ACL
in config on a device doesn't actually mean anything until you
attach it somewhere.

It's not hard to imagine a device where different limitations
apply, let's say a fairly simple Ethernet switch built on some
commodity chip. It consists of, say:
 * 24 * 10GE on a commodity chip
 * some control plane (a x86 PC) connected to that commodity chip

The commodity chip supports matching ethernet headers, so ACLs
attached to those ports are "eth-acl". The control plane on the
other hand supports complex matching on anything you can imagine.
What YANG features should such a device advertise?

   kll




On Wed, Nov 01, 2017 at 02:26:31PM +0100, Kristian Larsson wrote:
> Mahesh,
> 
> On Wed, Nov 01, 2017 at 05:13:18PM +0630, Mahesh Jethanandani wrote:
> > I think there is confusion in how the ACL model is going to be
> > implemented by vendors and used by customers.
> >
> > As Eliot alluded to, the model is trying to address the issue
> > of the capabilities of each platform as they exist across the
> > industry but also within each vendor. So the first thing an
> > implementation would do is to pick which feature they do
> > support. A low end platform that supports only layer 2 ACL will
> > pick l2-acl as their feature, while a high end router capable
> > of support l2 and l3, ipv4 and ipv6 ACL will declare
> > l2-l3-ipv4-ipv6 as the feature they support. That pretty much
> > takes out all the other containers in the matches container.
> > The additional features they might want to choose include
> > support for TCP, UDP and ICMP. For a high end router this boils
> > down to having definitions for
> > 
> > - ethernet
> > - ipv4
> > - ipv6
> > - tcp
> > - udp
> > - icmp
> > 
> > which is the list you have in mind, but this time making sure
> > that the platform is capable of supporting each one of the
> > definitions. Imagine if the low end platform advertised a model
> > for all the above capabilities only to reject them when you
> > tried to configure a ipv6 address that it already knows it
> > cannot support.
> 
> You imply that the low end platform would advertise features that
> it doesn't support. Why would it do that?
> 
> I don't suggest removing features - only restructure where the
> data is held.  In my example, under the ethernet container I can
> do: if-feature "eth-acl or eth-ipv4-acl..."; to check if the
> device supports a given feature so why are you saying that we
> need different containers for the ethernet matching part of an
> ACL of type eth-acl vs say eth-ipv4-acl?
> 
> Right now the features themselves affect the structure of the
> model and thus the data, which I rather dislike. The config to
> match e.g. ethernet headers should always go in the same place.
> 
> The model gives the illusion of supporting "unified" ACLs but
> actually doesn't at all.
> 
> 
> > Similarly the condition on tcp/udp/icmp container is to make
> > sure the platform is capable of supporting them. Only if the
> > platform declares tcp-acl, udp-acl, and icmp-acl feature, will
> > those containers be visible from a configuration perspective.
> 
> And if the device supports all of those features I can write an
> ACE that matches on TCP flags at and ICMP types.. and it would
> validate according to the model but cleary makes no sense.
> 
> > The acl-type is used as a check to make sure the user is aware
> > what kind of ACL the platform supports and the ACL they are
> > trying to configure matches the acl-type. If the platform
> > declared the feature l2-acl and if the user tries to set the
> > ACL type to l2-l3-ipv4-ipv6 then the configuration would be
> > rejected.
> 
> Another way of structuring this is to have completely different
> lists of ACLs where each type of ACL is its own list, e.g.
>  * eth-acl
>  * ipv4-acl
>  * ipv6-acl
>  * eth-ipv4-ipv6-acl
> 
> What advantage do you think your currently proposed model holds
> over such an approach?
> 
> What are your thoughts on the attachment point using two leaves?
> Are you satisfied with this?
> 
> 
> > In the Linux/nftables case, the platform should
> > declare the feature l2-l3-ipv4-ipv6, tcp-acl, udp-acl, and
> > icmp-acl if that is what it wants to support. The interface
> > attachment point has been defined but it is not mandatory that
> > a configuration has to define it. So if in Linux, the ACL list
> > is global, one would not define a attachment point, which
> > implies it is a global list.
> 
> Naturally one has to define an attachment point or the system
> wouldn't know which one of potentially multiple ACLs to apply to
> nftables. It might however be up to another YANG model to define
> that attachment point.
> 
> The list of features seem to align poorly with reality. How can
> we have a list of attachment poin

Re: [netmod] YANG model for netowrk configuration of a device's management interface

[Vladimir Vassilev]

On 11/01/2017 10:03 AM, Martin Bjorklund wrote:

Hi,

Jan Kundrát  wrote:

Hi,
I'm working on adding NETCONF support for configuring network on a few
management interfaces of our product, a random network appliance. I
would prefer not to reinvent this particular wheel, so I started
searching for existing models. I was surprised that it seems that all
vendors essentially go creative and appear to hack together something
proprietary.

Our product has a pretty modern Linux system inside. It has three
network interfaces -- two gigabit RJ-45 ethernets, and one SFP
port. My goal is to offer an intuitive way of assigning static IPv4 or
IPv6 addresses, control whether DHCP/SLAAC are enabled, and perhaps
configuring one static VLAN on each of them. It would be amazing if I
could bridge them together, or if there was a way of configuring, say,
OSPF, but that comes secondary to getting basic stuff done.

So far, I was able to find the following building blocks:

- RFC 7223. Perfect -- I can simply leave out the arbitrary-names and
- pre-provisioning features.
- RFC 7277, so that I can assign IPv4 and IPv6 addresses by hand. Good.
- RFC 8022 for static route definitions.

However, I would also like to offer one toggle which enables an IPv4
DHCP client on a given interface. This is where stuff starts to get
interesting:

-https://tools.ietf.org/html/draft-liu-dhc-dhcp-yang-model-06  and its
- IPv6 brother,
-https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-yang-04  . Wow. Why
- is the DHCP client configuration done outside of the /if:interfaces
- tree?

So to summarize, it seems that you found published modules for what
you were looking for, except for DHCP client configuration, for which
you found one individual draft and one WG draft.  I agree with your
comment re. /if:interfaces.  Since these documents are developed in
the DHC WG, I suggest you send your comments to them, and hopefully
you will be able to contribute to better models!

+1

The design of a ietf-dhcp(v4) and ietf-dhcpv6 modules must have 
"something" in common. I get it that the DHC WG is concentrated on v6 
but v4 is what is a mandatory requirement if there will be any point in 
implementing the ietf model.



/martin





-https://tools.ietf.org/html/draft-faq-netmod-cpe-yang-profile-01
- refers to the above, so it seems that I'm looking in a right
- direction.

-https://tools.ietf.org/html/draft-ietf-rtgwg-device-model-02  looks
- nice because it mentions a "dhcp-client" within the /if:interfaces
- tree. However, it does not define how that node looks like!

At this point I begin to understand why vendors unleash their
creativity when it comes to assigning IP addresses to management
interfaces of their boxes :(. However, I would prefer to just use
whatever is most common here, and focus on the application-specific
YANG model. Is there something that I can use as-is? I would hate to
implement 1000th version of this task...

With kind regards,
Jan

___
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] WG Last Call: draft-ietf-netmod-acl-model-14

[Kristian Larsson]

Mahesh,

On Wed, Nov 01, 2017 at 05:13:18PM +0630, Mahesh Jethanandani wrote:
> I think there is confusion in how the ACL model is going to be
> implemented by vendors and used by customers.
>
> As Eliot alluded to, the model is trying to address the issue
> of the capabilities of each platform as they exist across the
> industry but also within each vendor. So the first thing an
> implementation would do is to pick which feature they do
> support. A low end platform that supports only layer 2 ACL will
> pick l2-acl as their feature, while a high end router capable
> of support l2 and l3, ipv4 and ipv6 ACL will declare
> l2-l3-ipv4-ipv6 as the feature they support. That pretty much
> takes out all the other containers in the matches container.
> The additional features they might want to choose include
> support for TCP, UDP and ICMP. For a high end router this boils
> down to having definitions for
> 
> - ethernet
> - ipv4
> - ipv6
> - tcp
> - udp
> - icmp
> 
> which is the list you have in mind, but this time making sure
> that the platform is capable of supporting each one of the
> definitions. Imagine if the low end platform advertised a model
> for all the above capabilities only to reject them when you
> tried to configure a ipv6 address that it already knows it
> cannot support.

You imply that the low end platform would advertise features that
it doesn't support. Why would it do that?

I don't suggest removing features - only restructure where the
data is held.  In my example, under the ethernet container I can
do: if-feature "eth-acl or eth-ipv4-acl..."; to check if the
device supports a given feature so why are you saying that we
need different containers for the ethernet matching part of an
ACL of type eth-acl vs say eth-ipv4-acl?

Right now the features themselves affect the structure of the
model and thus the data, which I rather dislike. The config to
match e.g. ethernet headers should always go in the same place.

The model gives the illusion of supporting "unified" ACLs but
actually doesn't at all.


> Similarly the condition on tcp/udp/icmp container is to make
> sure the platform is capable of supporting them. Only if the
> platform declares tcp-acl, udp-acl, and icmp-acl feature, will
> those containers be visible from a configuration perspective.

And if the device supports all of those features I can write an
ACE that matches on TCP flags at and ICMP types.. and it would
validate according to the model but cleary makes no sense.

> The acl-type is used as a check to make sure the user is aware
> what kind of ACL the platform supports and the ACL they are
> trying to configure matches the acl-type. If the platform
> declared the feature l2-acl and if the user tries to set the
> ACL type to l2-l3-ipv4-ipv6 then the configuration would be
> rejected.

Another way of structuring this is to have completely different
lists of ACLs where each type of ACL is its own list, e.g.
 * eth-acl
 * ipv4-acl
 * ipv6-acl
 * eth-ipv4-ipv6-acl

What advantage do you think your currently proposed model holds
over such an approach?

What are your thoughts on the attachment point using two leaves?
Are you satisfied with this?


> In the Linux/nftables case, the platform should
> declare the feature l2-l3-ipv4-ipv6, tcp-acl, udp-acl, and
> icmp-acl if that is what it wants to support. The interface
> attachment point has been defined but it is not mandatory that
> a configuration has to define it. So if in Linux, the ACL list
> is global, one would not define a attachment point, which
> implies it is a global list.

Naturally one has to define an attachment point or the system
wouldn't know which one of potentially multiple ACLs to apply to
nftables. It might however be up to another YANG model to define
that attachment point.

The list of features seem to align poorly with reality. How can
we have a list of attachment points in the model but without
if-feature wrapping it? Surely a Linux machine must be able to
announce that it doesn't support per-interface ACLs? A side
question is why that attachment list exists in the first place -
why isn't it an augmentation of the interfaces module?

   kll

-- 
Kristian LarssonKLL-RIPE
+46 704 264511k...@spritelink.net

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

Re: [netmod] Action and RPC statements

[Juergen Schoenwaelder]

On Wed, Nov 01, 2017 at 11:42:43AM +, Robert Wilton wrote:
> 
> > One other comment, it would be good to also indicate that when an RPC
> > leads to modification of data nodes, what the “origin” of those
> > modifications is.
> > 
> That is an interesting question.
> 
> To describe this as a concrete example, if you have a single config true
> YANG list for dynamic/configuration subscriptions then a subscription can be
> created either via configuration or as an RPC operation.
> 
> I would probably classify this as "learned", and I think that we could
> extend the definition of the "learned" origin to cover this case.

I do not think any changes are needed, section 5.3.4 is pretty clear
that the origin 'intended' applies to configuration provided by
. If you at the options, there is pretty much only
'learned' applicable.

/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] Action and RPC statements

[Robert Wilton]

Hi Alex,


On 31/10/2017 17:36, Alexander Clemm wrote:


Hi Rob,

A few comments, inline

--- Alex

*From:*netmod [mailto:netmod-boun...@ietf.org] *On Behalf Of *Robert 
Wilton

*Sent:* Tuesday, October 31, 2017 7:14 AM
*To:* Martin Bjorklund ; a...@yumaworks.com; 
netmod@ietf.org; Randy Presuhn 

*Subject:* Re: [netmod] Action and RPC statements

Hi,

Here is another attempt for proposed text for Actions/RPC statements 
in NMDA.




6.2 Invocation of RPC Operations

This section updates section 7.14 of RFC 7950.

RPCs MAY be defined as affecting the contents of a specific datastore,
any configuration datastore (e.g., ), or any datastore
(e.g., ).  The RPC definition specifies how the RPC input
data is interpreted by the server.

 why “e.g., ”?  Does  affect the contents of 
the datastore – I thought it just gets data, hence this example is not 
ideal.


There is also no mention about the source of the “in” parameters.  It 
probably makes sense to mention that explicitly.


Perhaps something along the lines of “RPCs MAY be defined as 
_/relating/_ to the contents of a specific datastore….   Input data 
resolves to , as does output data, as do RPC side 
effects“.  Then below


“RPCs definitions that do not explicitly state an affected
datastore(s) _/refer_to/_  the general operational state of the server.”


Yes, that makes sense.

One other comment, it would be good to also indicate that when an RPC 
leads to modification of data nodes, what the “origin” of those 
modifications is.



That is an interesting question.

To describe this as a concrete example, if you have a single config true 
YANG list for dynamic/configuration subscriptions then a subscription 
can be created either via configuration or as an RPC operation.


I would probably classify this as "learned", and I think that we could 
extend the definition of the "learned" origin to cover this case.


Thanks,
Rob







RPCs definitions that do not explicitly state an affected
datastore(s) modify the general operational state of the server.
Hence, if any RPC input data relates to data node instances then
those would generally resolve to data node instances in the
 data tree.


6.3 Invocation of Actions

This section updates section 7.15 of RFC 7950.

In YANG data models, the "action" statement may appear under "config
true" and "config false" schema nodes.  While instances of both
schema nodes may appear in , instances of "config true"
schema nodes may also appear in other datastores.

Actions are always invoked on a data node instance that exist in the
 data tree.  The behavior defined by an action statement
is generally expected to affect the operational state of the server
rather than directly modifying the contents of any configuration
datastore.




On a related note, I also want to confirm that it is right that RPC 
input data is always checked against operational:


Section 6.1. of the NMDA draft states:


   o  If the XPath expression is defined in a substatement to an "input"
  statement in an "rpc" or "action" statement, the accessible tree
  is the RPC or action operation instance and all operational state
  in the server.  The root node has top-level data nodes in all
  modules as children.  Additionally, for an RPC, the root node also
  has the node representing the RPC operation being defined as a
  child.  The node representing the operation being defined has the
  operation's input parameters as children.



Is  always the right datastore to evaluate RPC 
input/output data relative to?  For most RPCs this seems to be the 
right choice by default but it also seems plausible that someone may 
wish to define an RPC that wants to validate its input parameters 
against the contents of another datastore.


An example could be an "is-applied" RPC that takes a path to a subtree 
in  or  and checks whether the configuration for 
that subtree is fully represented in .


Thanks,
Rob

On 27/10/2017 09:33, Martin Bjorklund wrote:

Andy Bierman   wrote:

On Thu, Oct 26, 2017 at 11:22 AM, Randy Presuhn <

randy_pres...@alumni.stanford.edu
> wrote:

Hi -

On 10/26/2017 10:44 AM, Robert Wilton wrote:

Hi ,

Separating out the issue regarding which datastore action and 
RPC apply

to, we propose the following NEW text to the datastores draft:

6.2 Invocation of Actions and RPC Operations

    This section updates section 7.15. of RFC 7950.

    In YANG data models, the "action" statement may appear under 
"config

    true" and "config false" schema nodes.  While instances of 
both

    schema nodes may appear in , instances of "config 
true"

    schema nodes may also appear in other datastores.

    An NMDA compliant server MUST execute all 

Re: [netmod] Action and RPC statements

[Robert Wilton]

On 01/11/2017 06:36, Phil Shafer wrote:

Robert Wilton writes:

ii) However, as far as I can see, it doesn't make sense for an action to
directly affect the contents of any configuration datastore, that should
be done via a purpose built rpc (like edit-config).

An example action would be to retrieve the  fingerprint of an ssh
key.  I might want to get the fingerprint of a key in 
before I commit it.

Or I could have an action that sets the SNMPv3 auth key to a random
value, and I want to invoke that action against .

Seems like  might also be an interesting place to target
actions, but I can't think of a good example.

There are always scenarios where something is useful, and the problem
with ruling it out is that it becomes needed at some later point.
We've a habit of ruling out things and later wishing we had them.

Yes, I have this concern.




Is the easy fix to just put a datastore leaf under rpc/action and
have it default to operational?  Any specific RPC can define its
own datastore leaf of hard-code the database in the description
(explicitly or implicitly ), but the  RPC only
gets this if we make a new parameter for it.


I think that an action/rpc statement should indicate in the schema where 
its input/output arguments are resolved against.  I.e. "configuration", 
"state", or "client-provided".  This would be specified by a new 
optional "resolve-to" YANG sub-statement to action/rpc, that defaults to 
"state" if not specified.


(i) Actions/rpcs that "resolve-to state" would resolve against 
 (the default behaviour).
(ii) Actions/rpcs that "resolve-to configuration" would probably resolve 
against .
(iii) Actions/rpcs that "resolve-to client-provided" would require that 
an explicit datastore be specified as an input parameter to the action/rpc.


Actions of type "resolve-to client-provided" would be required to be 
invoked with a new  RPC that has a new target 
datastore input parameter.


RPCs of type "resolve-to client-provided" would be required to have an 
input parameter named "datastore" that is a leafref to a datastore.


Finally, I would propose that we defer defining the new "resolved-to" 
YANG statement and  RPC to YANG/NETCONF/RESTCONF 2.0, 
so that for the moment actions/rpcs always resolve against  
because that will be the default behaviour today, but with the 
understanding that this could be extended in future.


Thanks,
Rob




Thanks,
  Phil
.



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

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

[Juergen Schoenwaelder]

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. BTW, how do I filter on TCP flags in combination with
a source IP address? There seem to be reasonable combinations of
features not even covered.

/js

On Wed, Nov 01, 2017 at 05:13:18PM +0630, Mahesh Jethanandani wrote:
> Kristian,
> 
> I think there is confusion in how the ACL model is going to be implemented by 
> vendors and used by customers.
> 
> As Eliot alluded to, the model is trying to address the issue of the 
> capabilities of each platform as they exist across the industry but also 
> within each vendor. So the first thing an implementation would do is to pick 
> which feature they do support. A low end platform that supports only layer 2 
> ACL will pick l2-acl as their feature, while a high end router capable of 
> support l2 and l3, ipv4 and ipv6 ACL will declare l2-l3-ipv4-ipv6 as the 
> feature they support. That pretty much takes out all the other containers in 
> the matches container. The additional features they might want to choose 
> include support for TCP, UDP and ICMP. For a high end router this boils down 
> to having definitions for
> 
> - ethernet
> - ipv4
> - ipv6
> - tcp
> - udp
> - icmp
> 
> which is the list you have in mind, but this time making sure that the 
> platform is capable of supporting each one of the definitions. Imagine if the 
> low end platform advertised a model for all the above capabilities only to 
> reject them when you tried to configure a ipv6 address that it already knows 
> it cannot support.
> 
> Similarly the condition on tcp/udp/icmp container is to make sure the 
> platform is capable of supporting them. Only if the platform declares 
> tcp-acl, udp-acl, and icmp-acl feature, will those containers be visible from 
> a configuration perspective.
> 
> The acl-type is used as a check to make sure the user is aware what kind of 
> ACL the platform supports and the ACL they are trying to configure matches 
> the acl-type. If the platform declared the feature l2-acl and if the user 
> tries to set the ACL type to l2-l3-ipv4-ipv6 then the configuration would be 
> rejected. In the Linux/nftables case, the platform should declare the feature 
> l2-l3-ipv4-ipv6, tcp-acl, udp-acl, and icmp-acl if that is what it wants to 
> support. The interface attachment point has been defined but it is not 
> mandatory that a configuration has to define it. So if in Linux, the ACL list 
> is global, one would not define a attachment point, which implies it is a 
> global list.
> 
> I will take a look at the remaining issues/comments you raise, but I wanted 
> to make sure that the overall design of the model was clear, which from this 
> email I can only guess could be made more clear.
> 
> Cheers.
> 
> > On Oct 31, 2017, at 4:55 PM, Kristian Larsson  
> > wrote:
> > 
> > On Fri, Oct 20, 2017 at 09:37:04PM +, Kent Watsen wrote:
> >> 
> >> All,
> >> 
> >> This starts a two-week working group last call on
> >> draft-ietf-netmod-acl-model-14.
> >> 
> >> The working group last call ends on November 3.
> >> Please send your comments to the netmod mailing list.
> > 
> > 
> > I initially read this draft (or an older version) close to a year
> > ago and meant to give feedback back then. I first wanted to read
> > up on the list archive on any previous discussions (since the
> > initial draft is relly old) but ran out of time.
> > 
> > I have still not read all previous discussions (there are 687
> > emails when searching for 'acl' in the archive) and therefore
> > I'll apologise beforehand as I'm bound to reiterate questions or
> > topics that have been brought up already. I'd be grateful if
> > those with the history in memory can help me by providing
> > references to the list archive.
> > 
> > Anyway, to the model. There's this concept of unified ACLs. I
> > see two dimensions:
> > * mixed layer ACLs, where we match on headers in different
> >   layers in the OSI/TCP/IP model, like ethernet and ipv4
> > * mixed family ACLs, where we in one ACL match on different
> >   protocols in the same OSI model layer, like both IPv4 and
> >   IPv6. However, within one ACE we always just match on one
> >   protocol.
> > 
> > What I don't understand is why under the matches container there
> > are these other containers, like l2-acl, ipv4-acl, ipv6-acl,
> > l2-l3-ipv4-acl etc? Depending on the type I would input the
> > ethernet matches in different places. That seems suboptimal.  If
> > we wanted an ACL type per AFI then we could have just created a
> > top level list per AFI instead of trying to pretend they are
> > unified by putting them in one list a

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

[Mahesh Jethanandani]

Kristian,

I think there is confusion in how the ACL model is going to be implemented by 
vendors and used by customers.

As Eliot alluded to, the model is trying to address the issue of the 
capabilities of each platform as they exist across the industry but also within 
each vendor. So the first thing an implementation would do is to pick which 
feature they do support. A low end platform that supports only layer 2 ACL will 
pick l2-acl as their feature, while a high end router capable of support l2 and 
l3, ipv4 and ipv6 ACL will declare l2-l3-ipv4-ipv6 as the feature they support. 
That pretty much takes out all the other containers in the matches container. 
The additional features they might want to choose include support for TCP, UDP 
and ICMP. For a high end router this boils down to having definitions for

- ethernet
- ipv4
- ipv6
- tcp
- udp
- icmp

which is the list you have in mind, but this time making sure that the platform 
is capable of supporting each one of the definitions. Imagine if the low end 
platform advertised a model for all the above capabilities only to reject them 
when you tried to configure a ipv6 address that it already knows it cannot 
support.

Similarly the condition on tcp/udp/icmp container is to make sure the platform 
is capable of supporting them. Only if the platform declares tcp-acl, udp-acl, 
and icmp-acl feature, will those containers be visible from a configuration 
perspective.

The acl-type is used as a check to make sure the user is aware what kind of ACL 
the platform supports and the ACL they are trying to configure matches the 
acl-type. If the platform declared the feature l2-acl and if the user tries to 
set the ACL type to l2-l3-ipv4-ipv6 then the configuration would be rejected. 
In the Linux/nftables case, the platform should declare the feature 
l2-l3-ipv4-ipv6, tcp-acl, udp-acl, and icmp-acl if that is what it wants to 
support. The interface attachment point has been defined but it is not 
mandatory that a configuration has to define it. So if in Linux, the ACL list 
is global, one would not define a attachment point, which implies it is a 
global list.

I will take a look at the remaining issues/comments you raise, but I wanted to 
make sure that the overall design of the model was clear, which from this email 
I can only guess could be made more clear.

Cheers.

> On Oct 31, 2017, at 4:55 PM, Kristian Larsson  wrote:
> 
> On Fri, Oct 20, 2017 at 09:37:04PM +, Kent Watsen wrote:
>> 
>> All,
>> 
>> This starts a two-week working group last call on
>> draft-ietf-netmod-acl-model-14.
>> 
>> The working group last call ends on November 3.
>> Please send your comments to the netmod mailing list.
> 
> 
> I initially read this draft (or an older version) close to a year
> ago and meant to give feedback back then. I first wanted to read
> up on the list archive on any previous discussions (since the
> initial draft is relly old) but ran out of time.
> 
> I have still not read all previous discussions (there are 687
> emails when searching for 'acl' in the archive) and therefore
> I'll apologise beforehand as I'm bound to reiterate questions or
> topics that have been brought up already. I'd be grateful if
> those with the history in memory can help me by providing
> references to the list archive.
> 
> Anyway, to the model. There's this concept of unified ACLs. I
> see two dimensions:
> * mixed layer ACLs, where we match on headers in different
>   layers in the OSI/TCP/IP model, like ethernet and ipv4
> * mixed family ACLs, where we in one ACL match on different
>   protocols in the same OSI model layer, like both IPv4 and
>   IPv6. However, within one ACE we always just match on one
>   protocol.
> 
> What I don't understand is why under the matches container there
> are these other containers, like l2-acl, ipv4-acl, ipv6-acl,
> l2-l3-ipv4-acl etc? Depending on the type I would input the
> ethernet matches in different places. That seems suboptimal.  If
> we wanted an ACL type per AFI then we could have just created a
> top level list per AFI instead of trying to pretend they are
> unified by putting them in one list and then splitting it up
> further down under the matches container. In that case, the
> attachment points would also have been made much simpler with
> just a single reference instead of having two leaves like the
> current model.
> 
> It seems to me that this can be modeled in a more elegant way by
> having the following containers under matches:
> * ethernet
> * ipv4
> * ipv6
> * tcp
> * udp
> * icmp
> 
> The ethernet containers presence is conditioned on the acl-type
> being one of l2-acl, l2-l3-ipv4-acl, l2-l3-ipv6-acl or
> l2-l3-ipv4-ipv6-acl.
> 
> The ipv4 container is conditioned on the acl-type being one of
> ipv4-acl, l2-l3-ipv4-acl, l2-l3-ipv4-ipv6-acl.
> 
> The ipv6 container is conditioned on the acl-type being one of
> ipv6-acl, l2-l3-ipv6-acl, l2-l3-ipv4-ipv6-acl.
> 
> In addition, there is a condition that prevents b

Re: [netmod] YANG model for netowrk configuration of a device's management interface

[Martin Bjorklund]

Hi,

Jan Kundrát  wrote:
> Hi,
> I'm working on adding NETCONF support for configuring network on a few
> management interfaces of our product, a random network appliance. I
> would prefer not to reinvent this particular wheel, so I started
> searching for existing models. I was surprised that it seems that all
> vendors essentially go creative and appear to hack together something
> proprietary.
> 
> Our product has a pretty modern Linux system inside. It has three
> network interfaces -- two gigabit RJ-45 ethernets, and one SFP
> port. My goal is to offer an intuitive way of assigning static IPv4 or
> IPv6 addresses, control whether DHCP/SLAAC are enabled, and perhaps
> configuring one static VLAN on each of them. It would be amazing if I
> could bridge them together, or if there was a way of configuring, say,
> OSPF, but that comes secondary to getting basic stuff done.
> 
> So far, I was able to find the following building blocks:
> 
> - RFC 7223. Perfect -- I can simply leave out the arbitrary-names and
> - pre-provisioning features.
> - RFC 7277, so that I can assign IPv4 and IPv6 addresses by hand. Good.
> - RFC 8022 for static route definitions.
> 
> However, I would also like to offer one toggle which enables an IPv4
> DHCP client on a given interface. This is where stuff starts to get
> interesting:
> 
> - https://tools.ietf.org/html/draft-liu-dhc-dhcp-yang-model-06 and its
> - IPv6 brother,
> - https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-yang-04 . Wow. Why
> - is the DHCP client configuration done outside of the /if:interfaces
> - tree?

So to summarize, it seems that you found published modules for what
you were looking for, except for DHCP client configuration, for which
you found one individual draft and one WG draft.  I agree with your
comment re. /if:interfaces.  Since these documents are developed in
the DHC WG, I suggest you send your comments to them, and hopefully
you will be able to contribute to better models!



/martin




> 
> - https://tools.ietf.org/html/draft-faq-netmod-cpe-yang-profile-01
> - refers to the above, so it seems that I'm looking in a right
> - direction.
> 
> - https://tools.ietf.org/html/draft-ietf-rtgwg-device-model-02 looks
> - nice because it mentions a "dhcp-client" within the /if:interfaces
> - tree. However, it does not define how that node looks like!
> 
> At this point I begin to understand why vendors unleash their
> creativity when it comes to assigning IP addresses to management
> interfaces of their boxes :(. However, I would prefer to just use
> whatever is most common here, and focus on the application-specific
> YANG model. Is there something that I can use as-is? I would hate to
> implement 1000th version of this task...
> 
> With kind regards,
> Jan
> 
> ___
> 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