[netmod] Netmod ACL - Can "access-lists" be set up as a "grouping"

[Jon Shallow]

Hi There,

 

I appreciate that this is late to the table, but is it possible to set up
"access-lists" as a "grouping" in the YANG data model so that "access-lists"
can be included by "uses" in a higher level YANG data model?

 

I have raised this as issue #22 at
https://github.com/netmod-wg/acl-model/issues

 

Regards

 

Jon

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

[netmod] Eric Rescorla's No Objection on draft-ietf-netmod-revised-datastores-09: (with COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-netmod-revised-datastores-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/



--
COMMENT:
--


  protocol interactions with other systems and that is neither
  conventional nor dynamic configuration.
Could you provide an example of this?


   datastore that holds the complete current configuration on the
   device.  It MAY include configuration that requires further
   transformation before it can be applied, e.g., inactive

If I am reading the text, this doesn't seem to be true because "system
configuration" is not included.


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

Re: [netmod] AD review: draft-ietf-netmod-revised-datastores-08

[Robert Wilton]

Hi Andy,

Regarding your comment below, this intent is captured by this text 
describing the operational datastore in section 5.3:


SHOULD conform to any constraints specified in the data
   model, but given the principal aim of returning "in use" values, it
   is possible that constraints MAY be violated under some
   circumstances, e.g., an abnormal value is "in use", the structure of
   a list is being modified, or due to remnant configuration (see
   Section 5.3.1).  Note, that deviations SHOULD be used when it is
   known in advance that a device does not fully conform to the
schema.

   Only semantic constraints MAY be violated, these are the YANG "when",
   "must", "mandatory", "unique", "min-elements", and "max-elements"
   statements; and the uniqueness of key values.

   Syntactic constraints MUST NOT be violated, including hierarchical
   organization, identifiers, and type-based constraints.  If a node in
does not meet the syntactic constraints then it MUST
   NOT be returned, and some other mechanism should be used to flag the
   error.


Do you agree that this is sufficient?

Thanks,
Rob


On 21/12/2017 22:49, Andy Bierman wrote:

Hi,

It should be clear somehow that server requirements to provide 
config=false data

that is valid according to the YANG definitions is not affected by NMDA.
That is not being taken away.  The ability to validate operational values
of configuration data has never been provided, and therefore is not 
being taken away either.


A constraint on config=true nodes only applies to configuration 
datastores.

These are the only constraints that should be ignored in .
Constraints on config=false nodes still apply in .


Andy



On Thu, Dec 21, 2017 at 2:27 PM, Juergen Schoenwaelder 
> wrote:


On Thu, Dec 21, 2017 at 07:52:54PM +0100, Vladimir Vassilev wrote:
> On 12/21/2017 02:20 PM, Juergen Schoenwaelder wrote:
>
> > On Thu, Dec 21, 2017 at 02:03:45PM +0100, Vladimir Vassilev wrote:
> > > On 12/21/2017 11:34 AM, Robert Wilton wrote:
> > >
> > > > Hi Vladimir,
> > > >
> > > > First point of clarification is that this is not about
running/intended
> > > > at all.  The contents of running/intended do not change in
anyway
> > > > depending on whether hardware is present or absent.
> > > >
> > > > The section is only concerned with how the configuration
is applied in
> > > > operational, and basically says that you cannot apply
configuration for
> > > > resources that are missing (which seems reasonable).  E.g.
I cannot
> > > > configure an IP address on a physical interface that isn't
there.  Or if
> > > > the physical interface gets removed then the configuration
associated
> > > > with that interface is also removed from operational.
> > > >
> > > > Operational isn't validated and data model constraints are
allowed to be
> > > > broken (ideally transiently).
> > > I want to focus on this. IMO giving up schema validitiy for
any datastore is
> > > unacceptable price. Pre-NMDA devices had full model support
in operational
> > > data (all YANG constrains part of the model without
discrimination were
> > > enforced).
> > There was a long debate about the value of returning the true
> > operational state. What do you do if the operational state is
invalid?
> > A server can reject configuration changes if they lead to invalid
> > state, a server can not reject reality.
> IMO if the model can represent reality then data conforming to
the model
> can. If not a better model is needed not a hack that breaks the
datastore
> conformance to the YANG model. I do not see how
> /interfaces/interface/oper-status=not-present was not
representing the
> reality of a system with removed line card that is configured
and ready to
> resume operation as soon as the line card is reconnected.

I assume this is all system and implementation specific. If your
system knows about interfaces that are not present (i.e., there is
operational state about them), you can report these interfaces.  But
'is configured' is confusing here. I am not sure a line card that does
not exist should be considered configured. But yes, this may be system
specific. Anyway, draft-ietf-netmod-rfc7223bis-01.txt still has
oper-status 'not-present' - so this seems to be a mood point.

> > > If this is about to change it will compromise interoperability
> > > and a significant portion of the client implementation
workload that can be
> > > automated will need to be coded in hand and tested.
Unresolved leafrefs,
> > > undefined behaviour of different implementations removing
different
> > > configuration nodes in violation of YANG semantic
constraints (which I do
> > > not think can be so clearly separated

Re: [netmod] Netmod ACL - Can "access-lists" be set up as a "grouping"

[Einar Nilsen-Nygaard (einarnn)]

Since this is a 7-line change, I see no harm in it if no-one objects? Mahesh 
has the token for rolling in updates discussed just prior to the end of 2017.

Here’s a possible diff:

$ git diff -b
diff --git a/src/yang/ietf-access-control-list.yang 
b/src/yang/ietf-access-control-list.yang
index 4d698c9..b1a173f 100644
--- a/src/yang/ietf-access-control-list.yang
+++ b/src/yang/ietf-access-control-list.yang
@@ -402,6 +402,10 @@ module ietf-access-control-list {
   /*
* Configuration data nodes
*/
+  grouping access-lists-top {
+description
+  "Grouping to allow reuse of access lists container elsewhere.";
+
 container access-lists {
   description
 "This is a top level container for Access Control Lists.
@@ -576,6 +580,9 @@ module ietf-access-control-list {
 }
   }
 }
+  }
+  uses access-lists-top;
+
   augment "/if:interfaces/if:interface" {
 description
   "Augment interfaces to allow ACLs to be associated in either the

Cheers,

Einar


On 8 Jan 2018, at 10:53, Jon Shallow 
mailto:supjps-i...@jpshallow.com>> wrote:

Hi There,

I appreciate that this is late to the table, but is it possible to set up 
“access-lists” as a “grouping” in the YANG data model so that “access-lists” 
can be included by “uses” in a higher level YANG data model?

I have raised this as issue #22 at https://github.com/netmod-wg/acl-model/issues

Regards

Jon
___
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] Yangdoctors last call review of draft-ietf-netmod-entity-07

[Martin Bjorklund]

Hi,

Radek Krejčí  wrote:
> Reviewer: Radek Krejčí
> Review result: Ready with Issues
> 
> The document itself and normative parts seem fine to me, the only issue I see
> is with the ietf-hardware-state module in non-normative appendix A. It seems 
> to
> me that this temporary non-NMDA module does not conform to its purpose as
> described in RFC6087bis. According to guidelines, such a module is intended to
> provide state (config false) data in case the server does not implement NMDA
> (to bridge the time period until NMDA is implemented). So such a server is 
> IMHO
> intended to implement both modules, foo and foo-state. The foo-state contains
> "the top-level config-false data nodes that would have been defined in a 
> legacy
> YANG module" - so it's only the ro mirror of data nodes. But
> ietf-hardware-state contains notifications, which are not the data nodes as
> defined in RFC7950. I understand why the notifications were placed also into
> the ietf-hardware-state - the module's description states that "If a server
> that implements this module but doesn't support NMDA also supports
> configuration of hardware components, it SHOULD also implement the module
> 'ietf-hardware' ...", so it allows its standalone usage in case the server 
> does
> not support hw configuration. But in such a case, the server can implement
> ietf-hardware with deviations on the config=true nodes.

The problem with useing the notifcations defined in ietf-hardware in
this case is that all leafrefs would be wrong; they'd point into a
schema that is not implemented.

> The same way it had to
> implement the legacy YANG module (before NMDA).

Before NMDA the leafrefs in the notifcations pointed to
/hardware-state, and all config was defined with an if-feature, so a
server did not have to use any deviations in this case.



/martin



> 
> So I think that the notifications should be removed from ietf-hardware-state
> and the module's description should change this way:
> 
> OLD
> 
>   If a server that implements this module but doesn't support NMDA
>   also supports configuration of hardware components, it SHOULD
>   also implement the module 'ietf-hardware' in the configuration
>   datastores. The corresponding state data is found in the
>   '/hw-state:hardware' subtree.
> 
> NEW
> 
>   If a server that implements this module but doesn't support NMDA,
>   it MUST also implement the module 'ietf-hardware' in the
>   configuration datastores. The corresponding state data is found
>   in the '/hw-state:hardware' subtree.
> 
> 
> ___
> 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] Netmod ACL - Can "access-lists" be set up as a "grouping"

[Robert Wilton]

Hi Einar, Jon, Mahesh,

My gut instinct is that making this a grouping might not be a good idea:

1) If somebody updates the core ACL model, will then need to check that 
anyone using it should be similarly updated (unless they use 
import-by-revision).


2) Does it make sense to define ACLs in separate places.  Would like be 
more simple if ACLs were defined in a central place and then just 
referenced by other protocols as required.


3) I think that groupings are probably overused and I think that they 
can detract from the readability of the model.  (I regard the OpenConfig 
YANG models as an extreme example of this, where it is necessary to 
compile the modules together to figure out where everything fits together).


Having said that, I don't think that this issue is important enough to 
have a long discussion about ...


Thanks,
Rob


On 08/01/2018 15:02, Einar Nilsen-Nygaard (einarnn) wrote:
Since this is a 7-line change, I see no harm in it if no-one objects? 
Mahesh has the token for rolling in updates discussed just prior to 
the end of 2017.


Here’s a possible diff:

$ git diff -b
diff --git a/src/yang/ietf-access-control-list.yang 
b/src/yang/ietf-access-control-list.yang

index 4d698c9..b1a173f 100644
--- a/src/yang/ietf-access-control-list.yang
+++ b/src/yang/ietf-access-control-list.yang
@@ -402,6 +402,10 @@ module ietf-access-control-list {
   /*
    * Configuration data nodes
    */
+  grouping access-lists-top {
+    description
+      "Grouping to allow reuse of access lists container elsewhere.";
+
     container access-lists {
       description
         "This is a top level container for Access Control Lists.
@@ -576,6 +580,9 @@ module ietf-access-control-list {
         }
       }
     }
+  }
+  uses access-lists-top;
+
   augment "/if:interfaces/if:interface" {
     description
       "Augment interfaces to allow ACLs to be associated in either the

Cheers,

Einar


On 8 Jan 2018, at 10:53, Jon Shallow > wrote:


Hi There,
I appreciate that this is late to the table, but is it possible to 
set up “access-lists” as a “grouping” in the YANG data model so that 
“access-lists” can be included by “uses” in a higher level YANG data 
model?
I have raised this as issue #22 
athttps://github.com/netmod-wg/acl-model/issues

Regards
Jon
___
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] Netmod ACL - Can "access-lists" be set up as a "grouping"

[Martin Bjorklund]

Hi,

Robert Wilton  wrote:
> Hi Einar, Jon, Mahesh,
> 
> My gut instinct is that making this a grouping might not be a good
> idea:
> 
> 1) If somebody updates the core ACL model, will then need to check
> that anyone using it should be similarly updated (unless they use
> import-by-revision).
> 
> 2) Does it make sense to define ACLs in separate places.  Would like
> be more simple if ACLs were defined in a central place and then just
> referenced by other protocols as required.
> 
> 3) I think that groupings are probably overused and I think that they
> can detract from the readability of the model.  (I regard the
> OpenConfig YANG models as an extreme example of this, where it is
> necessary to compile the modules together to figure out where
> everything fits together).

I agree with all three statements.  The current acl data model has a
top-level grouping "interface-acl" which probably is not intended to
be "exported".  I think ot should be moved into the
"attachment-points" container, in order to make it local.

If the entire access-list container is defined as a goruping, and is
used in multiple places, how are the multiple interface
attachment-points handled?


/martin



> 
> Having said that, I don't think that this issue is important enough to
> have a long discussion about ...
> 
> Thanks,
> Rob
> 
> 
> On 08/01/2018 15:02, Einar Nilsen-Nygaard (einarnn) wrote:
> > Since this is a 7-line change, I see no harm in it if no-one objects?
> > Mahesh has the token for rolling in updates discussed just prior to
> > the end of 2017.
> >
> > Here’s a possible diff:
> >
> > $ git diff -b
> > diff --git a/src/yang/ietf-access-control-list.yang
> > b/src/yang/ietf-access-control-list.yang
> > index 4d698c9..b1a173f 100644
> > --- a/src/yang/ietf-access-control-list.yang
> > +++ b/src/yang/ietf-access-control-list.yang
> > @@ -402,6 +402,10 @@ module ietf-access-control-list {
> >    /*
> >     * Configuration data nodes
> >     */
> > +  grouping access-lists-top {
> > +    description
> > +      "Grouping to allow reuse of access lists container elsewhere.";
> > +
> >      container access-lists {
> >        description
> >          "This is a top level container for Access Control Lists.
> > @@ -576,6 +580,9 @@ module ietf-access-control-list {
> >          }
> >        }
> >      }
> > +  }
> > +  uses access-lists-top;
> > +
> >    augment "/if:interfaces/if:interface" {
> >      description
> >        "Augment interfaces to allow ACLs to be associated in either
> > the
> >
> > Cheers,
> >
> > Einar
> >
> >
> >> On 8 Jan 2018, at 10:53, Jon Shallow  >> > wrote:
> >>
> >> Hi There,
> >> I appreciate that this is late to the table, but is it possible to set
> >> up “access-lists” as a “grouping” in the YANG data model so that
> >> “access-lists” can be included by “uses” in a higher level YANG data
> >> model?
> >> I have raised this as issue #22
> >> athttps://github.com/netmod-wg/acl-model/issues
> >> Regards
> >> Jon
> >> ___
> >> 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] Netmod ACL - Can "access-lists" be set up as a "grouping"

[Jon Shallow]

Hi Robert,

 

A good set of points.

 

My particular use case (hence raising the question) is defining a YANG model 
where there are multiple appliances and where ACLs are defined for each 
appliance, but there is the likelihood of the different appliances using the 
same “acl-name”, but the contents of “acl-name” are different.  Having a 
grouping (using import-by-revision) would help me considerably here.

 

Regards

 

Jon

 

From: Robert Wilton [mailto: rwil...@cisco.com] 
Sent: 08 January 2018 15:31
To: Einar Nilsen-Nygaard (einarnn); Jon Shallow; Mahesh Jethanandani
Cc: netmod@ietf.org
Subject: Re: [netmod] Netmod ACL - Can "access-lists" be set up as a "grouping"

 

Hi Einar, Jon, Mahesh,

My gut instinct is that making this a grouping might not be a good idea:

1) If somebody updates the core ACL model, will then need to check that anyone 
using it should be similarly updated (unless they use import-by-revision).

2) Does it make sense to define ACLs in separate places.  Would like be more 
simple if ACLs were defined in a central place and then just referenced by 
other protocols as required.

3) I think that groupings are probably overused and I think that they can 
detract from the readability of the model.  (I regard the OpenConfig YANG 
models as an extreme example of this, where it is necessary to compile the 
modules together to figure out where everything fits together).

Having said that, I don't think that this issue is important enough to have a 
long discussion about ...

Thanks,
Rob



On 08/01/2018 15:02, Einar Nilsen-Nygaard (einarnn) wrote:

Since this is a 7-line change, I see no harm in it if no-one objects? Mahesh 
has the token for rolling in updates discussed just prior to the end of 2017. 

 

Here’s a possible diff: 

 

$ git diff -b

diff --git a/src/yang/ietf-access-control-list.yang 
b/src/yang/ietf-access-control-list.yang

index 4d698c9..b1a173f 100644

--- a/src/yang/ietf-access-control-list.yang

+++ b/src/yang/ietf-access-control-list.yang

@@ -402,6 +402,10 @@ module ietf-access-control-list {

   /*

* Configuration data nodes

*/

+  grouping access-lists-top {

+description

+  "Grouping to allow reuse of access lists container elsewhere.";

+

 container access-lists {

   description

 "This is a top level container for Access Control Lists.

@@ -576,6 +580,9 @@ module ietf-access-control-list {

 }

   }

 }

+  }

+  uses access-lists-top;

+

   augment "/if:interfaces/if:interface" {

 description

   "Augment interfaces to allow ACLs to be associated in either the

 

Cheers,

 

Einar

 





On 8 Jan 2018, at 10:53, Jon Shallow  wrote:

 

Hi There,

 

I appreciate that this is late to the table, but is it possible to set up 
“access-lists” as a “grouping” in the YANG data model so that “access-lists” 
can be included by “uses” in a higher level YANG data model?

 

I have raised this as issue #22 at  
 
https://github.com/netmod-wg/acl-model/issues

 

Regards

 

Jon

___
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] Netmod ACL - Can "access-lists" be set up as a "grouping"

[Einar Nilsen-Nygaard (einarnn)]

On 8 Jan 2018, at 15:31, Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) 
mailto:rwil...@cisco.com>> wrote:


Hi Einar, Jon, Mahesh,

My gut instinct is that making this a grouping might not be a good idea:

1) If somebody updates the core ACL model, will then need to check that anyone 
using it should be similarly updated (unless they use import-by-revision).

Groupings and typedefs are subject to the same backwards-compatibility 
constraints as any other data. Thus updates to the model should always be 
trouble-free if the updates conform to RFC 6020/7950 backwards-compatibility 
rules for model updates.


2) Does it make sense to define ACLs in separate places.  Would like be more 
simple if ACLs were defined in a central place and then just referenced by 
other protocols as required.

Jon clearly has a case he is thinking about, and making an access list 
container reusable doesn’t seem like an intrinsically bad idea to me. What may 
be an irritating thing is if there are >1 use case for this and each use case 
is in effect required to define it’s own idea of a list of access list 
definitions.


3) I think that groupings are probably overused and I think that they can 
detract from the readability of the model.  (I regard the OpenConfig YANG 
models as an extreme example of this, where it is necessary to compile the 
modules together to figure out where everything fits together).

I’m not going to disagree with your comments on the overuse of groupings. We 
could also refer to Cisco IOS-XR native models, where we have some models with 
8 levels (perhaps more?) of nested groupings ;-)

Having said that, I don't think that this issue is important enough to have a 
long discussion about ...

Likewise. I have no objection to this change, but no strong vested interest 
either. What I’m most interested in is getting to an agreed model at this 
point, and this change wouldn’t impact that as it doesn’t change the actual 
model.

Jon — could you perhaps articulate your use case(s)? And perhaps update 
https://github.com/netmod-wg/acl-model/issues with them?

Cheers,

Einar


Thanks,
Rob


On 08/01/2018 15:02, Einar Nilsen-Nygaard (einarnn) wrote:
Since this is a 7-line change, I see no harm in it if no-one objects? Mahesh 
has the token for rolling in updates discussed just prior to the end of 2017.

Here’s a possible diff:

$ git diff -b
diff --git a/src/yang/ietf-access-control-list.yang 
b/src/yang/ietf-access-control-list.yang
index 4d698c9..b1a173f 100644
--- a/src/yang/ietf-access-control-list.yang
+++ b/src/yang/ietf-access-control-list.yang
@@ -402,6 +402,10 @@ module ietf-access-control-list {
   /*
* Configuration data nodes
*/
+  grouping access-lists-top {
+description
+  "Grouping to allow reuse of access lists container elsewhere.";
+
 container access-lists {
   description
 "This is a top level container for Access Control Lists.
@@ -576,6 +580,9 @@ module ietf-access-control-list {
 }
   }
 }
+  }
+  uses access-lists-top;
+
   augment "/if:interfaces/if:interface" {
 description
   "Augment interfaces to allow ACLs to be associated in either the

Cheers,

Einar


On 8 Jan 2018, at 10:53, Jon Shallow 
mailto:supjps-i...@jpshallow.com>> wrote:

Hi There,

I appreciate that this is late to the table, but is it possible to set up 
“access-lists” as a “grouping” in the YANG data model so that “access-lists” 
can be included by “uses” in a higher level YANG data model?

I have raised this as issue #22 at https://github.com/netmod-wg/acl-model/issues

Regards

Jon
___
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] Netmod ACL - Can "access-lists" be set up as a "grouping"

[Acee Lindem (acee)]

Hi Jon,

From: netmod mailto:netmod-boun...@ietf.org>> on 
behalf of Jon Shallow 
mailto:supjps-i...@jpshallow.com>>
Date: Monday, January 8, 2018 at 10:47 AM
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" 
mailto:rwil...@cisco.com>>, 
"netmod@ietf.org" 
mailto:netmod@ietf.org>>, "Einar Nilsen-Nygaard (einarnn)" 
mailto:eina...@cisco.com>>, 'Mahesh Jethanandani' 
mailto:mjethanand...@gmail.com>>
Subject: Re: [netmod] Netmod ACL - Can "access-lists" be set up as a "grouping"

Hi Robert,

A good set of points.

My particular use case (hence raising the question) is defining a YANG model 
where there are multiple appliances and where ACLs are defined for each 
appliance, but there is the likelihood of the different appliances using the 
same “acl-name”, but the contents of “acl-name” are different.  Having a 
grouping (using import-by-revision) would help me considerably here.

I guess I don’t see the use case. Wouldn’t you have multiple network devices 
for multiple network devices? Or at least separate LNEs?  
https://www.ietf.org/id/draft-ietf-rtgwg-lne-model-05.txt

Thanks,
Acee

Regards

Jon

From: Robert Wilton [mailto: rwil...@cisco.com]
Sent: 08 January 2018 15:31
To: Einar Nilsen-Nygaard (einarnn); Jon Shallow; Mahesh Jethanandani
Cc: netmod@ietf.org
Subject: Re: [netmod] Netmod ACL - Can "access-lists" be set up as a "grouping"


Hi Einar, Jon, Mahesh,

My gut instinct is that making this a grouping might not be a good idea:

1) If somebody updates the core ACL model, will then need to check that anyone 
using it should be similarly updated (unless they use import-by-revision).

2) Does it make sense to define ACLs in separate places.  Would like be more 
simple if ACLs were defined in a central place and then just referenced by 
other protocols as required.
3) I think that groupings are probably overused and I think that they can 
detract from the readability of the model.  (I regard the OpenConfig YANG 
models as an extreme example of this, where it is necessary to compile the 
modules together to figure out where everything fits together).

Having said that, I don't think that this issue is important enough to have a 
long discussion about ...

Thanks,
Rob

On 08/01/2018 15:02, Einar Nilsen-Nygaard (einarnn) wrote:
Since this is a 7-line change, I see no harm in it if no-one objects? Mahesh 
has the token for rolling in updates discussed just prior to the end of 2017.

Here’s a possible diff:

$ git diff -b
diff --git a/src/yang/ietf-access-control-list.yang 
b/src/yang/ietf-access-control-list.yang
index 4d698c9..b1a173f 100644
--- a/src/yang/ietf-access-control-list.yang
+++ b/src/yang/ietf-access-control-list.yang
@@ -402,6 +402,10 @@ module ietf-access-control-list {
   /*
* Configuration data nodes
*/
+  grouping access-lists-top {
+description
+  "Grouping to allow reuse of access lists container elsewhere.";
+
 container access-lists {
   description
 "This is a top level container for Access Control Lists.
@@ -576,6 +580,9 @@ module ietf-access-control-list {
 }
   }
 }
+  }
+  uses access-lists-top;
+
   augment "/if:interfaces/if:interface" {
 description
   "Augment interfaces to allow ACLs to be associated in either the

Cheers,

Einar



On 8 Jan 2018, at 10:53, Jon Shallow 
mailto:supjps-i...@jpshallow.com>> wrote:

Hi There,

I appreciate that this is late to the table, but is it possible to set up 
“access-lists” as a “grouping” in the YANG data model so that “access-lists” 
can be included by “uses” in a higher level YANG data model?

I have raised this as issue #22 at https://github.com/netmod-wg/acl-model/issues

Regards

Jon
___
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] Netmod ACL - Can "access-lists" be set up as a "grouping"

[Martin Bjorklund]

"Acee Lindem (acee)"  wrote:
> Hi Jon,
> 
> From: netmod mailto:netmod-boun...@ietf.org>>
> on behalf of Jon Shallow
> mailto:supjps-i...@jpshallow.com>>
> Date: Monday, January 8, 2018 at 10:47 AM
> To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)"
> mailto:rwil...@cisco.com>>,
> "netmod@ietf.org"
> mailto:netmod@ietf.org>>, "Einar Nilsen-Nygaard
> (einarnn)" mailto:eina...@cisco.com>>, 'Mahesh
> Jethanandani'
> mailto:mjethanand...@gmail.com>>
> Subject: Re: [netmod] Netmod ACL - Can "access-lists" be set up as a
> "grouping"
> 
> Hi Robert,
> 
> A good set of points.
> 
> My particular use case (hence raising the question) is defining a YANG
> model where there are multiple appliances and where ACLs are defined
> for each appliance, but there is the likelihood of the different
> appliances using the same “acl-name”, but the contents of “acl-name”
> are different.  Having a grouping (using import-by-revision) would
> help me considerably here.
> 
> I guess I don’t see the use case. Wouldn’t you have multiple network
> devices for multiple network devices? Or at least separate LNEs?
> https://www.ietf.org/id/draft-ietf-rtgwg-lne-model-05.txt

Right.  If a grouping is required for acls for this use case, wouldn't
the same be true for interfaces and the other models?  I think LNE or
schema mount in general solves this issue.


/martin


> 
> Thanks,
> Acee
> 
> Regards
> 
> Jon
> 
> From: Robert Wilton [mailto:
> rwil...@cisco.com]
> Sent: 08 January 2018 15:31
> To: Einar Nilsen-Nygaard (einarnn); Jon Shallow; Mahesh Jethanandani
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Netmod ACL - Can "access-lists" be set up as a
> "grouping"
> 
> 
> Hi Einar, Jon, Mahesh,
> 
> My gut instinct is that making this a grouping might not be a good
> idea:
> 
> 1) If somebody updates the core ACL model, will then need to check
> that anyone using it should be similarly updated (unless they use
> import-by-revision).
> 
> 2) Does it make sense to define ACLs in separate places.  Would like
> be more simple if ACLs were defined in a central place and then just
> referenced by other protocols as required.
> 3) I think that groupings are probably overused and I think that they
> can detract from the readability of the model.  (I regard the
> OpenConfig YANG models as an extreme example of this, where it is
> necessary to compile the modules together to figure out where
> everything fits together).
> 
> Having said that, I don't think that this issue is important enough to
> have a long discussion about ...
> 
> Thanks,
> Rob
> 
> On 08/01/2018 15:02, Einar Nilsen-Nygaard (einarnn) wrote:
> Since this is a 7-line change, I see no harm in it if no-one objects?
> Mahesh has the token for rolling in updates discussed just prior to
> the end of 2017.
> 
> Here’s a possible diff:
> 
> $ git diff -b
> diff --git a/src/yang/ietf-access-control-list.yang
> b/src/yang/ietf-access-control-list.yang
> index 4d698c9..b1a173f 100644
> --- a/src/yang/ietf-access-control-list.yang
> +++ b/src/yang/ietf-access-control-list.yang
> @@ -402,6 +402,10 @@ module ietf-access-control-list {
>/*
> * Configuration data nodes
> */
> +  grouping access-lists-top {
> +description
> +  "Grouping to allow reuse of access lists container elsewhere.";
> +
>  container access-lists {
>description
>  "This is a top level container for Access Control Lists.
> @@ -576,6 +580,9 @@ module ietf-access-control-list {
>  }
>}
>  }
> +  }
> +  uses access-lists-top;
> +
>augment "/if:interfaces/if:interface" {
>  description
>"Augment interfaces to allow ACLs to be associated in either the
> 
> Cheers,
> 
> Einar
> 
> 
> 
> On 8 Jan 2018, at 10:53, Jon Shallow
> mailto:supjps-i...@jpshallow.com>> wrote:
> 
> Hi There,
> 
> I appreciate that this is late to the table, but is it possible to set
> up “access-lists” as a “grouping” in the YANG data model so that
> “access-lists” can be included by “uses” in a higher level YANG data
> model?
> 
> I have raised this as issue #22 at
> https://github.com/netmod-wg/acl-model/issues
> 
> Regards
> 
> Jon
> ___
> 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] AD review: draft-ietf-netmod-revised-datastores-08

[Andy Bierman]

On Mon, Jan 8, 2018 at 5:55 AM, Robert Wilton  wrote:

> Hi Andy,
>
> Regarding your comment below, this intent is captured by this text
> describing the operational datastore in section 5.3:
>
> SHOULD conform to any constraints specified in the data
>model, but given the principal aim of returning "in use" values, it
>is possible that constraints MAY be violated under some
>circumstances, e.g., an abnormal value is "in use", the structure of
>a list is being modified, or due to remnant configuration (see
>Section 5.3.1).  Note, that deviations SHOULD be used when it is
>known in advance that a device does not fully conform to the
> schema.
>
>Only semantic constraints MAY be violated, these are the YANG "when",
>"must", "mandatory", "unique", "min-elements", and "max-elements"
>statements; and the uniqueness of key values.
>
>Syntactic constraints MUST NOT be violated, including hierarchical
>organization, identifiers, and type-based constraints.  If a node in
> does not meet the syntactic constraints then it MUST
>NOT be returned, and some other mechanism should be used to flag the
>error.
>
>
> Do you agree that this is sufficient?
>


Not really.
It does not address my concern, which is that NMDA is
removing the YANG constraints on config=false data nodes
for no apparent reason.

The server implementation requirements expressed in YANG constraints
are applicable to any data node, not just config=true data nodes.
The requirement to implement the ancestor nodes (with keys) does not change.
The requirement to conform to the YANG constraints defined within
config=false
data nodes does not change.

To do otherwise does not make sense.  E.g. "when" conditions that add
ethernet
counters only when the interface type is ethernetCsmacd. Why would it be OK
for
the server to ignore that when-stmt and add ethernet counters to every
interface?

IMO the text above can only apply to the operational values of config=true
nodes.


> Thanks,
> Rob
>


Andy


>
>
> On 21/12/2017 22:49, Andy Bierman wrote:
>
> Hi,
>
> It should be clear somehow that server requirements to provide
> config=false data
> that is valid according to the YANG definitions is not affected by NMDA.
> That is not being taken away.  The ability to validate operational values
> of configuration data has never been provided, and therefore is not being
> taken away either.
>
> A constraint on config=true nodes only applies to configuration datastores.
> These are the only constraints that should be ignored in .
> Constraints on config=false nodes still apply in .
>
>
> Andy
>
>
>
> On Thu, Dec 21, 2017 at 2:27 PM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
>> On Thu, Dec 21, 2017 at 07:52:54PM +0100, Vladimir Vassilev wrote:
>> > On 12/21/2017 02:20 PM, Juergen Schoenwaelder wrote:
>> >
>> > > On Thu, Dec 21, 2017 at 02:03:45PM +0100, Vladimir Vassilev wrote:
>> > > > On 12/21/2017 11:34 AM, Robert Wilton wrote:
>> > > >
>> > > > > Hi Vladimir,
>> > > > >
>> > > > > First point of clarification is that this is not about
>> running/intended
>> > > > > at all.  The contents of running/intended do not change in anyway
>> > > > > depending on whether hardware is present or absent.
>> > > > >
>> > > > > The section is only concerned with how the configuration is
>> applied in
>> > > > > operational, and basically says that you cannot apply
>> configuration for
>> > > > > resources that are missing (which seems reasonable).  E.g. I
>> cannot
>> > > > > configure an IP address on a physical interface that isn't
>> there.  Or if
>> > > > > the physical interface gets removed then the configuration
>> associated
>> > > > > with that interface is also removed from operational.
>> > > > >
>> > > > > Operational isn't validated and data model constraints are
>> allowed to be
>> > > > > broken (ideally transiently).
>> > > > I want to focus on this. IMO giving up schema validitiy for any
>> datastore is
>> > > > unacceptable price. Pre-NMDA devices had full model support in
>> operational
>> > > > data (all YANG constrains part of the model without discrimination
>> were
>> > > > enforced).
>> > > There was a long debate about the value of returning the true
>> > > operational state. What do you do if the operational state is invalid?
>> > > A server can reject configuration changes if they lead to invalid
>> > > state, a server can not reject reality.
>> > IMO if the model can represent reality then data conforming to the model
>> > can. If not a better model is needed not a hack that breaks the
>> datastore
>> > conformance to the YANG model. I do not see how
>> > /interfaces/interface/oper-status=not-present was not representing the
>> > reality of a system with removed line card that is configured and ready
>> to
>> > resume operation as soon as the line card is reconnected.
>>
>> I assume this is all system and implementation specific. If your
>> system knows about in

[netmod] Opsdir telechat review of draft-ietf-netmod-rfc7223bis-01

[Jouni Korhonen]

Reviewer: Jouni Korhonen
Review result: Ready

I did a shallow review on the document and to me it looked ok. The YANG passes
online validators (obviously the examples in Appendixes create bogus warnings).
Similarly IDnits warning concerning abstract and "obsoletes" is bogus.

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

[netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-rfc7223bis-01: (with DISCUSS)

[Kathleen Moriarty]

Kathleen Moriarty has entered the following ballot position for
draft-ietf-netmod-rfc7223bis-01: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/



--
DISCUSS:
--

Hello,

Thanks for your work on this draft.  It appears an older version of the
Security Considerations template was used.  Could you please update to the
current version that adds in transport security and other considerations?  I
believe this is the latest version, but Benoit can confirm.

https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-10#page-52




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

[netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-rfc7277bis-01: (with DISCUSS)

[Kathleen Moriarty]

Kathleen Moriarty has entered the following ballot position for
draft-ietf-netmod-rfc7277bis-01: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7277bis/



--
DISCUSS:
--

Hello,

I'm a little confused on the Security Consideration section as it doesn't use
the latest template, but does specify SSH for NETCONF, so I'm good with that
part.  Will RESTCONF also be used as a transport or is there some reason it
won't be used for this YANG module?

Here's what I think is the latest template and please let me know if sections
of it do not apply to this draft and I'll drop the discuss for correcting the
security considerations section.

https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-10#page-52

Thanks in advance!




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

Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-rfc7277bis-01: (with DISCUSS)

[joel jaeggli]

On 1/8/18 1:53 PM, Kathleen Moriarty wrote:
> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-netmod-rfc7277bis-01: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7277bis/
>
>
>
> --
> DISCUSS:
> --
>
> Hello,
>
> I'm a little confused on the Security Consideration section as it doesn't use
> the latest template, but does specify SSH for NETCONF, so I'm good with that
> part.  Will RESTCONF also be used as a transport or is there some reason it
> won't be used for this YANG module?
>
> Here's what I think is the latest template and please let me know if sections
> of it do not apply to this draft and I'll drop the discuss for correcting the
> security considerations section.

the security consideration section of 7277bis is the same as for rfc 7277

the ssh recommendation came from you at the time.


  *Comment* (2014-03-21 for -13)

Add a RECOMMEND use of SSH in addition to the MTI to prevent MITM or monitoring 
attacks (pervasive or otherwise).

> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-10#page-52
>
> Thanks in advance!
>
>
>
>

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

[netmod] Opsdir telechat review of draft-ietf-netmod-revised-datastores-09

[Victor Kuarsingh]

Reviewer: Victor Kuarsingh
Review result: Ready

Dear Authors,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Document Reviewed - Network Management Datastore Architecture

Link to Document -
https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-09

Summary:

This document specifies and architectural framework for datastores as it
pertains to YANG (RFC7960)and NETCONF(RFC6241)/RESTCONF(RFC8040).  A
significant amount of input was gathered from real world experience to help
evolve the the the datamodels user/proposed.

The document outlines a revised architecture model for datastores with the
addition of “Intended” and “operational” to the conceptual model.

General Comments and Feedback:

In general, this document seems well written and reviewed by the working group.
 N specific NITs or edits are recommended by this review.

The document describes operational impacts os the change since Implications to
YANG in section 6 and YANG model examples in section 7 which are highly useful
the for the operationalization of this updated specification.

I fee the document is ready for publishing baed on the current (ver -09) draft.

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

[netmod] Opsdir telechat review of draft-ietf-netmod-rfc7277bis-01

[Sheng Jiang]

Reviewer: Sheng Jiang
Review result: Ready

Hi, OPS-DIR, Authors,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written with the intent of improving the operational aspects of the IETF
drafts. Comments that are not addressed in last call may be included in AD
reviews during the IESG review. Document editors and WG chairs should treat
these comments just like any other last call comments.

This Standards Track document defines a YANG data model for management of IP
implementations.  It includes configuration and system  state.  This document
obsoletes RFC 7277. As a Bis document, this document is well written. It is
ready with minor issues.

Major issue: no.

Minor issue: no.

Regards,

Sheng


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

Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-rfc7223bis-01: (with DISCUSS)

[Martin Bjorklund]

Hi,

Kathleen Moriarty  wrote:
> --
> DISCUSS:
> --
> 
> Hello,
> 
> Thanks for your work on this draft.  It appears an older version of the
> Security Considerations template was used.  Could you please update to the
> current version that adds in transport security and other considerations?  I
> believe this is the latest version, but Benoit can confirm.
> 
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-10#page-52

I have updated to the latest version in my local copy.


/martin

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

Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-rfc7277bis-01: (with DISCUSS)

[Martin Bjorklund]

Hi,

Kathleen Moriarty  wrote:
> --
> DISCUSS:
> --
> 
> Hello,
> 
> I'm a little confused on the Security Consideration section as it doesn't use
> the latest template, but does specify SSH for NETCONF, so I'm good with that
> part.  Will RESTCONF also be used as a transport or is there some reason it
> won't be used for this YANG module?
> 
> Here's what I think is the latest template and please let me know if sections
> of it do not apply to this draft and I'll drop the discuss for correcting the
> security considerations section.
> 
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-10#page-52

I have updated to the latest version in my local copy.


/martin

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

Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-rfc7277bis-01: (with DISCUSS)

[Benoit Claise]

On 1/9/2018 8:27 AM, Martin Bjorklund wrote:

Hi,

Kathleen Moriarty  wrote:

--
DISCUSS:
--

Hello,

I'm a little confused on the Security Consideration section as it doesn't use
the latest template, but does specify SSH for NETCONF, so I'm good with that
part.  Will RESTCONF also be used as a transport or is there some reason it
won't be used for this YANG module?

Here's what I think is the latest template and please let me know if sections
of it do not apply to this draft and I'll drop the discuss for correcting the
security considerations section.

https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-10#page-52

I have updated to the latest version in my local copy.

Thanks Martin.
The IETF LC finishes today. So please post a new version tomorrow.

Regards, B.



/martin

.



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