Re: [netmod] Question on the path element of the NACM YANG model

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hi Juergen,

Thanks for your interpretation.

-Original Message-
> From: Jürgen Schönwälder  
> Sent: Thursday, December 23, 2021 11:37 AM
> To: Bogaert, Bart (Nokia - BE/Antwerp) 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Question on the path element of the NACM YANG model
>
> On Thu, Dec 23, 2021 at 08:40:41AM +, Bogaert, Bart (Nokia - BE/Antwerp) 
> wrote:
> > 
> > The RFC text is not specific on whether prefixes are mandatory in the path 
> > content but this is how I understand the text:
> > 
> >   *   If a module-name is part of the rule, the path is within the context 
> > of the module and 'adopts' the namespace of that module
> >   *   If the module-name is not part of the rule, the complete data store 
> > applies and then it depends on whether prefixes have been used in the path 
> > contents (or not).
> >   *   The module-name is not inside the rule-type choice, so the presence 
> > of module-name in the rule has meaning and brings context to the rule.
> >
>
> I have not implemented this so I am not sure either but I would assume that 
> the 'data-node' value (of type 'node-instance-identifier') resolves into a 
> set of nodes, regardless of the existence or value of the 'module-name'
 > sibling. If a 'module-name' is set, then this set is further restricted to 
 > the set of nodes defined in that module.
>
>  Note that in my interpretation, instance identifiers with components in 
> multiple modules, e.g., "/a:level0/b:level1/c:level3", will match as long as 
> the prefix 'c' of the node 'level3' is bound to 'c-module'
> and 'module-name' is 'c-module'. In other words, I would not assume that 
> setting 'module-name' to 'c-module' implies that all nodes in the instance 
> identifier have to belong to 'c-module'.

I also did not make that assumption but I'm not sure - when specifying a 
module-name In the rule - to refer to other nodes having nothing to do with 
that module.  Maybe there is a use case, however not sure which one (I would 
omit the module-name in such cases).  
To me it also does not seem to be mandatory to prefix the nodes (so binding it 
to a namespace).  If it is prefixed, then the match will be restricted to that 
namespace only, in case there is no prefix you may get multiple matched from 
different namespaces (if there happens to be an overlapping xpath. 

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

[netmod] Question on the path element of the NACM YANG model

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hi,

We are having some debate about the contents of the path element of an NACM 
rule when combined with the module-name element.  Assume the following rule:


nome-of-rule
some-module
/node-a/node-b/node-c
read
permit


When reading the RFC txt, the way I understand this rule is that only 
/node-a/node-b/node-c as defined in module 'some-module' will match (so the 
path 'adopts' the namespace of module 'some-module'.  As such it is not 
necessary the prefix the path.

When having a rule like this:


some-other-rule
/node-a/node-b/node-c 
read
permit


There may be more 'matches' depending on whether there would be more than 1 
module defining a path as in the above example (I leave in the middle whether 
this is good modelling or not but it is for the sake of the context of the 
question).

The RFC text is not specific on whether prefixes are mandatory in the path 
content but this is how I understand the text:

  *   If a module-name is part of the rule, the path is within the context of 
the module and 'adopts' the namespace of that module
  *   If the module-name is not part of the rule, the complete data store 
applies and then it depends on whether prefixes have been used in the path 
contents (or not).
  *   The module-name is not inside the rule-type choice, so the presence of 
module-name in the rule has meaning and brings context to the rule.

Is that a correct understanding?  Is there a section in the RFC that explicitly 
describes what can be expected as behavior when implemented in a server?

Best regards,
Bart
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] RFC 8802 (reset to factory defaults) versus RFC 8342 (NMDA)

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hi,

We are a little confused when reading RFC8808 (reset to factory-default 
datastore) in relation to the "system configuration" source in figure 2 of 
RFC8342.  When correctly understanding RFC 8342, the running datastore is empty 
when the system starts up after coming from the factory, and 'factory default' 
data is entered in the operational datastore as 'system/default configuration' 
data.

RFC 8808 seems to suggest that the running datastore contains (factory-default, 
system) data when the system starts up after coming from the factory. I.e. the 
understanding is that a reset to factory default brings the system back to the 
status as if it comes from the factory, and it is said the factory default goes 
into the running, ...

What exactly is the content of the running datastore when it comes from the 
factory?
Could this be clarified?

Regards, Bart

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

Re: [netmod] Question related to ietf-netconf-with-defaults

[Bogaert, Bart (Nokia - BE/Antwerp)]

Seems that I better address this subject to ietf-netmode.

Sorry for the trouble.

Regards, Bart

From: netconf  On Behalf Of Bogaert, Bart (Nokia - 
BE/Antwerp)
Sent: Friday, May 8, 2020 4:55 PM
To: netc...@ietf.org
Subject: [netconf] Question related to ietf-netconf-with-defaults

Hi,

I have a question related to the with-defaults capability and the how a NC 
server should be dealing with schema-defaults.


  1.  Assume the following model:

module leaf-has-default {
  yang-version 1.1;
  namespace "http://www.example.com/lhd;;
  prefix lhd;

  container contains-leafs {
leaf num-value {
  type uint32;
  default 1;
}
leaf string-value {
  type string;
  default "bla";
}
  }
}


  1.  The server does not support ietf-netconf-with-defaults


Using an RPC we configure the node 'string-value' to "bla" (which coincides 
with the schema-default).  But the optional 'num-value' has been defined with a 
schema-default.  I'm assuming that the server will return the value 1 in case 
it receives a get-config request, correct?


  1.  Now assume that the model is changed so that the schema-default of 
num-value is changed to 5 and the schema-default is changed to "blabla" and the 
server is restarted with this new module (or does an in-service upgrade)

My assumption is that the server now:

  *   returns 5 for the node 'num-value' (new schema-default and node was not 
configured explicitly)
  *   but still returns 'bla' for the node 'string-value' (as this node was 
configured explicitly but happened to be configured to the schema-default0 to 
the same get-config request.

Is that understanding correct?

I'm not looking at this topic from the view-point whether this is good 
YANG-practice but from the viewpoint of what must be expected from a NC server 
implementation.

Best regards, Bart
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Question about schema-mount

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hi Martin,

-Original Message-
From: Martin Bjorklund  
Sent: Thursday, November 28, 2019 9:28 AM
To: Bogaert, Bart (Nokia - BE/Antwerp) 
Cc: netmod@ietf.org
Subject: Re: [netmod] Question about schema-mount

Hi,

"Bogaert, Bart (Nokia - BE/Antwerp)"  wrote:
> Hi,
> 
> We're trying to figure out whether it is possible to define a module 
> in the parent schema which would use a node being a leafref to a node 
> in a model under a mount point.

In order for this to work, the leafref target would have to be present at 
compile time / design time.  RFC 8528 defines Design time, Implementation time, 
and Run time mounts, and says: "Design-time mounts are outside the scope of 
this document" (see section 1).

Another alternative would be some new kind of "leafref-like" construct that 
supported this.

What you can do though is to ensure the leaf in the parent module is of the 
same type as the mounted node you want to refer to, and explain in text what 
the semantics is.

[Bogaert, Bart] Thanks for this feedback.  The use case we're looking into is 
the following:
[Bogaert, Bart] A forwarder contains references to interfaces which are defined 
as leafref with path /interfaces/interface/name.  In the scope of this question 
the path would be 
/logical-network/elements/logical-network-element/interfaces/interface/name.  
Question is: will this work with leafref?  What will the [Bogaert, Bart] 
NETCONF server do in such a case, in other word: is it able to resolve this 
leafref or do we have to define this as a some kind of string that includes the 
name of the logical-network-element and the name of the interface?


> I don't seem to find any statement
> that would prohibit this but RFC 8530, referred to from the schema 
> mount RFC, uses a leafref to a node in a module which is still in the 
> list of YANG modules of the parent (and consequently in the YANG 
> library of the parent).
> 
> So, using RFC8530 as example:
> 
> Instead of lne:bind-lne-name being a leafref to 
> /logical-network-elements/logical-network-element/name we would point 
> to 
> /logical-network-elements/logical-network-element/interfaces/interface/name.
> 
> The interfaces YANG module is also part of the YANG library of the 
> parent but I'm not so sure whether above construction would work well 
> as the information related to the mounted YANG modules is in a YANG 
> library different from the parent's YANG library.
> 
> Note that there is also some confusion with the examples in RFC8530:
> while the bind-lne-name in the YANG module is a leafref as syntax, the 
> examples work with a string as syntax for that same leaf.

Do you mean the tree diagram?

[Bogaert, Bart] Correct.

Best regards, Bart

   module: ietf-interfaces
 +--rw interfaces
+--rw interface* [name]
   +--rw namestring
   +--rw lne:bind-lne-name?  string

This looks like a bug to me; it should be a leafref.


/martin

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

[netmod] YANG 1.1 inline notifications

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hi,

I'm trying to seek some clarification.

According to RFC7950 section 7.16.2:
When a notification node is defined as a child to a data node, the
 element defined in [RFC5277] contains a hierarchy of
nodes that identifies the node in the datastore.

According to RFC6241 section 1.1:
datastore: A conceptual place to store and access information. A
datastore might be implemented, for example, using files, a
database, flash memory locations, or combinations thereof

When combining these two, the "hierarchy of nodes that identifies the node in 
the datastore" actually refers to resources that do exist (at least that is how 
I understand this).

Now consider the following model.

container state-data {
  config false;
  list elements {
key name;
leaf name {
  type string;
}
leaf status {
  type enumeration {
enum up;
enum down;
  }
}
notification inline-notification {
  description
"An in-line notification";

leaf result {
  type string;
  mandatory true;
}
}
  }
}

Can a device send the notification 'inline-notification' if the list 
/state-data/elements is empty?
My feeling is that this should not be possible as there is no "hierarchy of 
nodes that identifies the node in the datastore", so against what would that 
notification be sent in such case?

Best regards, Bart
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Question on when-construction involving identities not detected as an error during module compilation

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hi,

We have a question on YANG module compilation.  Assume the following model:

module test-feat-compile {
  yang-version 1.1;
  namespace "http://www.example.com/test-feat-compile;;
  prefix "tfc";

  identity failure-reason {
description
  "The reason a failure occurred.";
  }

  identity no-failure {
description
  "No failure has occurred.";
  }

  identity general-error {
base failure-reason;
description
  "A general error occurred.";
  }

  container failure {
description
  "Objects associated with a failure.";

leaf failure-reason {
  type identityref {
base failure-reason;
  }
  description
"The reason the failure occurred.";
}

leaf failure-string {
  when "../failure-reason != 'no-failure'" {
description
  "Only valid when there is a failure.";
  }
  type string;
  description
"A text string indicating the reason for the failure when
 either no defined reason exists or additional information
 is available beyond the definition of the reason.";
}
  }
}

Looking at the when clause there is something obviously wrong (at least this is 
how I see it):

  *   The leaf 'failure-reason' is of type identityref  with 'failure-reason' 
as base
  *   Identity 'no-failure' does not have 'failure-reason' as base (see it as 
having been forgotten)
Question is: shouldn't this be reported at compile time?  Pyang doesn't and the 
other compiler we use doesn't report this either.

Even when 'no-failure' is modified into some arbitrary string it is still 
accepted while this arbitrary string is not defined anywhere as identity.

And when it comes to the correct syntax, RFC 7950 states (section 9.1.3) that 
identities in must and when statements should be prefixed (so tfc:no-failure in 
this case).  Also this "violation" passes.

So: what can we expect to be checked at compile time in this case?  Now you can 
only detect these anomalies when using a system supporting the modules and 
detect that things do not work as intended.  It would be better to have these 
erroneous constructions being detected at compile time.  If there is something 
in the RFC that allows the compiler to behave as it does now it would be good 
to know.

Best regards, Bart
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] An abundant amount of IANA if types...

[Bogaert, Bart (Nokia - BE/Antwerp)]

Juergen,

I was not suggesting to have a feature for all identities but I would assume 
that there are several identities that logically belong to each other so these 
could be grouped.  If this would still lead to a lot of features I do not see 
how a deviation can help out here to reduce the number of identities as you do 
not have a schema node for identities so to me the only way to reduce the 
amount of interface types one supports is to define a YANG module importing 
ietf-interfaces for the base interface-type identity and defining the set of 
identities required but then this not really in-line with what is coming from 
the standardization bodies (you could re-use the same names as used in 
iana-if-type but this is not very nice).

Regards, Bart

-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
Sent: Friday, April 6, 2018 1:37 PM
To: Bogaert, Bart (Nokia - BE/Antwerp) <bart.boga...@nokia.com>; Alex Campbell 
<alex.campb...@aviatnet.com>; netmod@ietf.org
Subject: Re: [netmod] An abundant amount of IANA if types...

On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> writes:
> 
> > If we would have a mechanism to deviate an identityref to a subset 
> > of identity values supported by an implementation, we would have 
> > solved a more generic problem. Yes, the IANA list could be 'nicer' 
> > but it will never be 'nice'.
> 
> Three mechanisms can be used for this:
> 
> - splitting the identities into separate modules

Whatever module organization you come up with, it won't work for all 
implementations. 

> - using features

Making every identity a feature will turn the feature system upside down. This 
is similar to making every leaf a feature.

> - using deviations (even though vendors frown on them)

If my implementation only supports A and B and C, then a deviation may state 
exactly that and the problem is solved. Hoping that my specific combination of 
A and B and C matches a set of modules or some set of features is in my view an 
illusion.

Vendors not shipping proper deviations are essentially telling their customers 
that they have not yet understood model driven management.
We need to change the mindset here instead of polluting our data models with 
hundreds or thousands of fine grained 'features'.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <https://www.jacobs-university.de/>

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

Re: [netmod] An abundant amount of IANA if types...

[Bogaert, Bart (Nokia - BE/Antwerp)]

Alex,

Not sure if this only has to do with "practical limitations providing a CLI 
interface"...   In a machine-to-machine interface this is less of a problem but 
in a human-to-machine interface it seems a bit impractical to me to find a 
solution for a problem to scroll through a list of 100+ completions if an 
operator would ask for the possible completion in case he does not know what to 
provide as input.  There are ways to limit this output but it can be solved on 
a modelling level as well.  As I indicated identities can be conditional to a 
feature and if implementations choose not to implement a set of interface-type 
related features the list becomes (a whole lot) shorter "by itself".  Now 
iana-if-type is just a collection of all interface types that have been defined 
once without any kind of "structure".

Regards, Bart

-Original Message-
From: Ladislav Lhotka [mailto:lho...@nic.cz] 
Sent: Friday, April 6, 2018 9:55 AM
To: Alex Campbell <alex.campb...@aviatnet.com>; Bogaert, Bart (Nokia - 
BE/Antwerp) <bart.boga...@nokia.com>; netmod@ietf.org
Subject: Re: [netmod] An abundant amount of IANA if types...

Hi,

I have argued several times in the past that the IANA interface list (and, for 
that matter, the iana-if-type module) is a useless pile of rubbish because

- for some interface classes (Ethernet, tunnels) it is way too coarse-grained

- on the other hand, it contains a lot of stuff that nobody will ever use

- using the cabalistic (and wrong, in fact) name "ethernetCsmacd" for Ethernet 
is outright stupid

- YANG identities allow for encoding important relationships in interface 
types,in the flat list all this information is lost 

- as you say, implementing the iana-if-type module means that all interface 
types listed therein become valid.

So yes, I do believe that it would be useful if authoritative expert groups 
develop a better structure of interface type identities.

Lada
  
On Thu, 2018-04-05 at 23:59 +, Alex Campbell wrote:
> I haven't seen any previous discussions on the topic, but we have a 
> similar problem.
> Note this is not really to do with YANG itself, so much as the 
> practical limitations of the software package that provides our CLI interface.
> In NETCONF, the existence of extra unused identities doesn't pose any problem.
> 
> From: netmod <netmod-boun...@ietf.org> on behalf of Bogaert, Bart 
> (Nokia -
> BE/Antwerp) <bart.boga...@nokia.com>
> Sent: Thursday, 5 April 2018 8:21 p.m.
> To: netmod@ietf.org
> Subject: [netmod] An abundant amount of IANA if types...
>  
> Hi,
>  
> We were wondering if it would make sense to introduce features in the 
> IANA if types YANG model to enable grouping of related interface 
> types.  This would allow implementations to include only the types it 
> really requires (by supporting the related features but not the 
> others) and (in case of a CLI
> interface) would reduce the possible completions if an operator would 
> ask for the possible values of the type of an interface.
> Has this ever been considered/discussed?
>  
> Best regards,
> Bart
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] An abundant amount of IANA if types...

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hi,

We were wondering if it would make sense to introduce features in the IANA if 
types YANG model to enable grouping of related interface types.  This would 
allow implementations to include only the types it really requires (by 
supporting the related features but not the others) and (in case of a CLI 
interface) would reduce the possible completions if an operator would ask for 
the possible values of the type of an interface.
Has this ever been considered/discussed?

Best regards,
Bart
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Question on edit-config statement (section 7.2)

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hi,

We have a question about the following statement in the edit-config RPC section:

"If the  operation contains multiple sub-operations
that apply to the same conceptual node in the underlying data
model, then the result of the operation is undefined (i.e.,
outside the scope of the NETCONF protocol)."

How do we need to read this?  Does this mean that if there is an edit-config in 
which, say, 10 interfaces are created these 10 interfaces need to be grouped in 
the same "section" of the edit-config as this:

  ...
  

  one
  ...

   
  two
  ...

  
  ...


And not like this:

  ...
  

  one
  ...

  
  ...
  

  two

  
  ...


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

Re: [netmod] Guideline on modeling including features and phased support by a device

[Bogaert, Bart (Nokia - BE/Antwerp)]

Rob,

Just to clarify: in this case we are not changing the model, it is the same 
model but the device SW in release X is not supporting the feature and in 
release Y it is.  Supporting the feature results in adding that part of the 
tree to the configuration that is related to the feature and the data leafs 
related to that feature are simply not there in the data configured when SW 
release X was active.

Regards, Bart

From: Robert Wilton [mailto:rwil...@cisco.com]
Sent: Tuesday, March 6, 2018 12:59 PM
To: Bogaert, Bart (Nokia - BE/Antwerp) <bart.boga...@nokia.com>
Cc: netmod@ietf.org
Subject: Re: [netmod] Guideline on modeling including features and phased 
support by a device


Arguably the guidelines, or YANG, should say "don't allow this" ;-)

I think that what you are describing is just another instance of "don't augment 
with a mandatory node rule", or "only backwards compatible changes revisions 
should be made to a published YANG module".

The key reasoning behind these rules is that the a client should be able to 
work unchanged after the server has been upgraded, as long as they are not 
making use of any new functionality.
Thanks,
Rob

On 06/03/2018 11:34, Bogaert, Bart (Nokia - BE/Antwerp) wrote:
Hi Rob,

I agree but the fact is that some of the BBF models have constructions like 
that and we were wondering whether this should not be mentioned in the 
guildelines document.  Normally a server can't set config true leafs if there 
is no default available in the model.  That is the reason we reached out to 
NETMOD.  Your suggestions can work but require adaptation of the current model.

Regards, Bart

From: Robert Wilton [mailto:rwil...@cisco.com]
Sent: Tuesday, March 6, 2018 10:38 AM
To: Bogaert, Bart (Nokia - BE/Antwerp) 
<bart.boga...@nokia.com><mailto:bart.boga...@nokia.com>; 
netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] Guideline on modeling including features and phased 
support by a device


Hi Bart,

I think that the best solution to problem is perhaps to avoid it altogether.  
I.e. I don't think that the only-if-feature leaf should be marked mandatory.  
Instead, it would be better to define a sensible default value/behaviour if the 
leaf is absent even when the feature is supported.

Alternatively, you can simulate something similar to an if-feature statement by 
using a when or must expression instead that is predicated on a leaf that the 
client must explicitly set to enable the feature, giving control back to the 
client.

E.g. something along the lines of ...

leaf enable-super-feature {
  if-feature test-feature;
  type boolean;
  default "false";
}

...
  leaf only-if-feature {
when '/enable-super-feature = "true"';
type string;
mandatory true;
  }

It would be interesting if you have a concrete example where neither of the 
above suggestions would work or be appropriate.

Thanks,
Rob


On 05/03/2018 09:25, Bogaert, Bart (Nokia - BE/Antwerp) wrote:
Hi,

We have a question with respect to YANG models using features.  Assume that a 
part of the model is defined under a feature and that this feature-dependent 
part defines a leaf as mandatory.

module servers {
  namespace "http://www.example.com/servers;;
  prefix servers;

  import ietf-inet-types {
prefix inet;
  }

  revision 2018-03-01 {
description
   "Initial version.";
  }

  feature test-feature {
description "testing feature";
  }

  container servers {
list server {
  key name;
  max-elements 64;
  leaf name {
type string;
  }
  leaf ip {
type inet:ip-address;
mandatory true;
  }
  leaf port {
type inet:port-number;
mandatory true;
  }
  leaf only-if-feature {
if-feature test-feature;
type string;
mandatory true;
  }
}
  }
}

Now assume that we have a device that implements the model step-wise by first 
not supporting this feature and in a sub-sequent release by supporting this 
feature (and uses a persistent running datastore).  The question arising now is 
how to deal with this mandatory leaf?  Normally this can only be configured by 
a client, meaning that without any "help", the NC server will not be able to 
startup with the data contained in the device's persistent datastore unless a 
value is set for the mandatory leaf that now becomes available as a result of 
supporting the feature.

When modeling as follows it seems the NC server can start with the model 
supporting the feature that was not supported before:

module servers {
  namespace "http://www.example.com/servers;;
  prefix servers;

  import ietf-inet-types {
prefix inet;
  }

  revision 2018-03-01 {
description
   "Initial version.";
  }

  feature test-feature {
description "testing feature";
  }

  container servers {
li

[netmod] Guideline on modeling including features and phased support by a device

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hi,

We have a question with respect to YANG models using features.  Assume that a 
part of the model is defined under a feature and that this feature-dependent 
part defines a leaf as mandatory.

module servers {
  namespace "http://www.example.com/servers;;
  prefix servers;

  import ietf-inet-types {
prefix inet;
  }

  revision 2018-03-01 {
description
   "Initial version.";
  }

  feature test-feature {
description "testing feature";
  }

  container servers {
list server {
  key name;
  max-elements 64;
  leaf name {
type string;
  }
  leaf ip {
type inet:ip-address;
mandatory true;
  }
  leaf port {
type inet:port-number;
mandatory true;
  }
  leaf only-if-feature {
if-feature test-feature;
type string;
mandatory true;
  }
}
  }
}

Now assume that we have a device that implements the model step-wise by first 
not supporting this feature and in a sub-sequent release by supporting this 
feature (and uses a persistent running datastore).  The question arising now is 
how to deal with this mandatory leaf?  Normally this can only be configured by 
a client, meaning that without any "help", the NC server will not be able to 
startup with the data contained in the device's persistent datastore unless a 
value is set for the mandatory leaf that now becomes available as a result of 
supporting the feature.

When modeling as follows it seems the NC server can start with the model 
supporting the feature that was not supported before:

module servers {
  namespace "http://www.example.com/servers;;
  prefix servers;

  import ietf-inet-types {
prefix inet;
  }

  revision 2018-03-01 {
description
   "Initial version.";
  }

  feature test-feature {
description "testing feature";
  }

  container servers {
list server {
  key name;
  max-elements 64;
  leaf name {
type string;
  }
  leaf ip {
type inet:ip-address;
mandatory true;
  }
  leaf port {
type inet:port-number;
mandatory true;
  }
  container only-if-feature {
presence "see if this helps";
if-feature test-feature;
leaf only-if-feature {
  type string;
  mandatory true;
}
  }
}
  }
}

Are recommendations or guidelines in place to deal with this?

Regards, Bart

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

[netmod] Question on schema-mount

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hi,

We have a question w.r.t. deletion of entry in a list using mounted schema 
knowing that in NC/Y there is no such thing as a "cascading delete" (leafref 
constructions in many cases even makes it impossible to delete a resource if it 
is still referred).

How does this apply to such a schema being mounted.  Using the example from the 
draft:

 +--rw interfaces
 |  +--rw interface* [name]
 | ...
 +--rw logical-device* [name]
+--rw name
|   ...
+--rw interfaces
  +--rw interface* [name]
 ...

Is it possible in this case to delete /logical-device[name='x'] and the server 
has to remove all the data associated with the mounted schema?  Or does the 
edit-config also explicitly has to delete the data related to the mounted 
schema?

I could not find something in the draft that deals with this (or it is there, 
but then I did not understand that section very well).

Thanks in advance,
Bart

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

Re: [netmod] Question on range for parent-rel-pos in ietf-hatrdware.yang versus RFC 6933 entPhysicalParentRelPos

[Bogaert, Bart (Nokia - BE/Antwerp)]

Thanks Martin, this makes sense.

Regards, Bart

-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com] 
Sent: Thursday, February 8, 2018 9:24 AM
To: Bogaert, Bart (Nokia - BE/Antwerp) <bart.boga...@nokia.com>
Cc: netmod@ietf.org
Subject: Re: [netmod] Question on range for parent-rel-pos in 
ietf-hatrdware.yang versus RFC 6933 entPhysicalParentRelPos

"Bogaert, Bart (Nokia - BE/Antwerp)" <bart.boga...@nokia.com> wrote:
> Hi,
> 
> During implementation we came across the following anomaly:
> 
> According to RFC 6933 entPhysicalParentRelPos the value should be set 
> to -1 in case there is no parent.
> The hardware YANG model defines this leaf as int32 with range "0 .. 
> 2147483647",  To be in-line with the referred RFC, shouldn't the range 
> be extended as "-1 .. 2147483647"?

In MIBs, people often use special values to indicate that the underlying thing 
doesn't exist.  In YANG we try to avoid this, and instead not instantiate the 
node.  This should probably have been clarified in the YANG module.


/martin

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

Re: [netmod] I-D Action: draft-ietf-netmod-rfc7223bis-03.txt

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hi,

We do have a question about the operational-state value 'not-present'.  The 
revised data store draft document mentions that for resources that are not 
available (e.g. HW components) there will not be an entry for the state (see 
section 5.3.2) so for equipment there will never be a state entry where the 
operational state is 'not-present'.  For interfaces it appears to us that if an 
interface is related to a HW component that is not there the operational state 
is either down of lower-layer-down depending on the position in the interface 
stack.

Is there a need to keep the value 'not-present'  for operational-state?

Regards, Bart

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of 
internet-dra...@ietf.org
Sent: Thursday, January 11, 2018 4:43 PM
To: i-d-annou...@ietf.org
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc7223bis-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

Title   : A YANG Data Model for Interface Management
Author  : Martin Bjorklund
Filename: draft-ietf-netmod-rfc7223bis-03.txt
Pages   : 48
Date: 2018-01-11

Abstract:
   This document defines a YANG data model for the management of network
   interfaces.  It is expected that interface-type-specific data models
   augment the generic interfaces data model defined in this document.
   The data model includes definitions for configuration and system
   state (status information and counters for the collection of
   statistics).

   The YANG model in this document conforms to the Network Management
   Datastore Architecture defined in I-D.ietf-netmod-revised-datastores.

   This document obsoletes RFC 7223.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc7223bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc7223bis-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7223bis-03


Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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

Re: [netmod] AD review of draft-ietf-netmod-entity-06

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hi Martin,

We agree with option 2.

Regards, Bart

-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com] 
Sent: Thursday, January 11, 2018 2:47 PM
To: Bogaert, Bart (Nokia - BE/Antwerp) <bart.boga...@nokia.com>
Cc: netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06

Hi,

To summarize this, I think we have three options for the three nodes 
'model-name', 'mfg-name', and 'serial-num':

  1.  Do nothing (keep the nodes as config true).

  2.  Make these three nodes config false (fairly simple change).
  (vendors can augment w/ their own config true nodes).

  3.  Add three new nodes for the configured values.


After thinking about this some more, and discussing with Benoit, I think the 
best path forward is to do 2, i.e., mark the nodes 'model-name', 'mfg-name', 
and 'serial-num' as "config false".  As such they would not be configurable, 
and thus contain the detected values.
If no value is detected, the node is not present.

Note that 1 or 3 can be done in a future update to this module (or by a vendor).


/martin


Martin Bjorklund <m...@tail-f.com> wrote:
> Hi,
> 
> "Bogaert, Bart (Nokia - BE/Antwerp)" <bart.boga...@nokia.com> wrote:
> > Hi,
> > 
> > --- snip ---
> > 
> > > state.”, so the above sentence only applies for the second case below.
> > 
> > Ok.
> > 
> > > 2. The second case is that something is detected but it can’t be read.
> > > We do not see a reason to use the value configured for the leafs 
> > > ‘serial-num’, ‘mfg-name’ and ‘model-name’ of a matching entry in 
> > > the configuration data.  These leafs are defined as optional so 
> > > why would we report something entered by an operator in the 
> > > operational datastore that intends to report on what is detected?  
> > > Is it not better to not report them at all?  In an NMDA context it 
> > > would be possible to have a different value (or no value at all) 
> > > for certain leafs while there is something in the running/intended 
> > > datastore.
> > 
> > The normal NMDA procedure for a configuration leaf is to repeat it 
> > in operational state.  This is then the "applied configuration".
> > I don't think we should have a special rule for these leafs.
> > 
> > This also means that a client that just wants to read all the serial 
> > numbers can do so from one place, the operational state, regardless 
> > of how they came into existance.
> > 
> > [Bogaert, Bart ]
> > 
> > We do understand that a target of NMDA is to read out the actually 
> > applied data in one request.  But the result should not be 
> > confusion. A key word is “applied”.
> > 
> > Section 5.3 of draft-ietf-netmod-revised-datastores-09 also contains 
> > (I put a part of the section between ***):
> > The datastore schema for  MUST be a superset of the 
> > combined datastore schema used in all configuration datastores 
> > except that configuration data nodes supported in a configuration 
> > datastore ***MAY be omitted from  if a server is not 
> > able to accurately report them ***.
> 
> Note that this text talks about the *schema*.  It is intended for 
> servers to migrate to NMDA without having to instrument all config 
> nodes in  immediately.  If you apply this to 
> ietf-hardware, it could be a server that implements the node 
> "serial-num" in config, but not in  (which would be 
> weird).
> 
> > For example, it is expected that the value of multiple leafs need to 
> > be a consistent set, e.g. the mfg-name, the model-name, and the 
> > serial-num.
> > Suppose we have a use case in which a hardware component is 
> > planned/configured (e.g. a board supporting DSL interfaces) but a 
> > different one is plugged (e.g. a board supporting ethernet 
> > interfaces).
> > Suppose it is possible to read some fields on the detected component 
> > but due to an issue not to read other fields.
> > If in that case the operational datastore will be completed with the 
> > data taken from the running datastore, then the presented view might 
> > be inconsistent.
> 
> This is true for other similar nodes as well - "asset-id" and "uri".
> 
> > The question is also: what data is applied? Our assumption: if there 
> > is a mismatch between detected versus configured hardware, then the 
> > interface/service related data that is configured consistently with 
> > the planned hardware is not applied on the mismatching hardware. 
> > I.e. the detected hardware is not brought in service so not 
> > ‘applied’, the opera

Re: [netmod] AD review of draft-ietf-netmod-entity-06

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hi,

--- snip ---

> state.”, so the above sentence only applies for the second case below.

Ok.

> 2. The second case is that something is detected but it can’t be read.
> We do not see a reason to use the value configured for the leafs 
> ‘serial-num’, ‘mfg-name’ and ‘model-name’ of a matching entry in the 
> configuration data.  These leafs are defined as optional so why would 
> we report something entered by an operator in the operational 
> datastore that intends to report on what is detected?  Is it not 
> better to not report them at all?  In an NMDA context it would be 
> possible to have a different value (or no value at all) for certain 
> leafs while there is something in the running/intended datastore.

The normal NMDA procedure for a configuration leaf is to repeat it in 
operational state.  This is then the "applied configuration".  
I don't think we should have a special rule for these leafs.

This also means that a client that just wants to read all the serial numbers 
can do so from one place, the operational state, regardless of how they came 
into existance.

[Bogaert, Bart ] 

We do understand that a target of NMDA is to read out the actually applied data 
in one request.  But the result should not be confusion. A key word is 
“applied”.

Section 5.3 of draft-ietf-netmod-revised-datastores-09 also contains (I put a 
part of the section between ***):
The datastore schema for  MUST be a superset of the combined 
datastore schema used in all configuration datastores except that configuration 
data nodes supported in a configuration datastore ***MAY be omitted from 
 if a server is not able to accurately report them ***.

For example, it is expected that the value of multiple leafs need to be a 
consistent set, e.g. the mfg-name, the model-name, and the serial-num.
Suppose we have a use case in which a hardware component is planned/configured 
(e.g. a board supporting DSL interfaces) but a different one is plugged (e.g. a 
board supporting ethernet interfaces).
Suppose it is possible to read some fields on the detected component but due to 
an issue not to read other fields.
If in that case the operational datastore will be completed with the data taken 
from the running datastore, then the presented view might be inconsistent.
The question is also: what data is applied? Our assumption: if there is a 
mismatch between detected versus configured hardware, then the 
interface/service related data that is configured consistently with the planned 
hardware is not applied on the mismatching hardware. I.e. the detected hardware 
is not brought in service so not ‘applied’, the operational datastore only 
(accurately) reports on what is detected.

We do not see this as a special rule for this data but rather would apply a 
general rule:
-   if there is a ‘missing resource’, then the data is not reported in the 
operational datastore.
-   If the server is not able to report accurately, then the data is 
omitted from the operational

Regards, Bart

/martin


> 
> Best regards, Bart
> 
> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Robert 
> Wilton
> Sent: Thursday, December 21, 2017 4:14 PM
> To: Martin Bjorklund ; netmod@ietf.org
> Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06
> 
> Hi Martin,
> 
> 
> On 21/12/2017 11:37, Martin Bjorklund wrote:
> > Hi,
> >
> > I need WG input on this issue.  The question is how to handle 
> > 'serial-num', 'mfg-name', and 'model-name'.  I think they should all 
> > be treated the same.  Based on previous WG discussion (see e.g. the 
> > mail thread "draft-ietf-netmod-entity issue #13"), I think they 
> > should all be configurable, but the configured value is only used in 
> > operational state if the system cannot read it from the hardware.
> I think that this approach is probably OK:
>   - The client can always see the real value if it is available.
>   - If it is not available then they can assign a value via  
> configuration.
> 
> I was also considering an alternative approach of having a separate 
> set of config false leaves for the "burnt in values".  And then having 
> the configurable leaves always override the default operational 
> values. E.g. similar to how an interface MAC address would expect to 
> be handled.
> 
> But one set of leaves is probably sufficient.
> 
> Thanks,
> Rob
> 
> 
> >
> > So I suggest the following changes:
> >
> > OLD:
> >
> >leaf serial-num {
> >  type string;
> >  config false;
> >  description
> >"The vendor-specific serial number string for the
> > component.  The preferred value is the serial number
> > string actually printed on the component itself (if
> > present).";
> >  reference "RFC 6933: entPhysicalSerialNum";
> >}
> >
> > NEW:
> >
> >leaf serial-num {
> >  type string;
> >  description
> >"The 

Re: [netmod] AD review of draft-ietf-netmod-entity-06

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hi Martin,

We had a discussion on this and we have some concerns about below statement 
(behavior in the description statement):

>This leaf can be configured.  The configured value is used only if
>the server cannot determine the vendor-specific serial number from
>the component itself.

For the above sentence “server cannot determine” we have 2 cases:
1.  It can’t be determined because there is nothing detected.  According to 
the NMDA-draft it is clear that in this case there is no row for the associated 
component and hence no data.  I think this case is covered by the sentence in 
the latest draft-ietf-netmod-entity for the list “component” where it is 
stated: “When the server detects a new hardware component, it initializes a 
list entry in the operational state.”, so the above sentence only applies for 
the second case below.
2.  The second case is that something is detected but it can’t be read.  We 
do not see a reason to use the value configured for the leafs ‘serial-num’, 
‘mfg-name’ and ‘model-name’ of a matching entry in the configuration data.  
These leafs are defined as optional so why would we report something entered by 
an operator in the operational datastore that intends to report on what is 
detected?  Is it not better to not report them at all?  In an NMDA context it 
would be possible to have a different value (or no value at all) for certain 
leafs while there is something in the running/intended datastore.

Best regards, Bart

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Robert Wilton
Sent: Thursday, December 21, 2017 4:14 PM
To: Martin Bjorklund ; netmod@ietf.org
Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06

Hi Martin,


On 21/12/2017 11:37, Martin Bjorklund wrote:
> Hi,
>
> I need WG input on this issue.  The question is how to handle 
> 'serial-num', 'mfg-name', and 'model-name'.  I think they should all 
> be treated the same.  Based on previous WG discussion (see e.g. the 
> mail thread "draft-ietf-netmod-entity issue #13"), I think they should 
> all be configurable, but the configured value is only used in 
> operational state if the system cannot read it from the hardware.
I think that this approach is probably OK:
  - The client can always see the real value if it is available.
  - If it is not available then they can assign a value via configuration.

I was also considering an alternative approach of having a separate set of 
config false leaves for the "burnt in values".  And then having the 
configurable leaves always override the default operational values. E.g. 
similar to how an interface MAC address would expect to be handled.

But one set of leaves is probably sufficient.

Thanks,
Rob


>
> So I suggest the following changes:
>
> OLD:
>
>leaf serial-num {
>  type string;
>  config false;
>  description
>"The vendor-specific serial number string for the
> component.  The preferred value is the serial number
> string actually printed on the component itself (if
> present).";
>  reference "RFC 6933: entPhysicalSerialNum";
>}
>
> NEW:
>
>leaf serial-num {
>  type string;
>  description
>"The vendor-specific serial number string for the
> component.  The preferred value is the serial number
> string actually printed on the component itself (if
> present).
>
> This leaf can be configured.  There are two use cases for
> this; as a 'post-it' note if the server cannot determine
> this value from the component, or when pre-provisioning a
> component.
>
> If the server can determine the serial number from the
> component, then that value is always used in operational
> state, even if another value has been configured.";
>  reference "RFC 6933: entPhysicalSerialNum";
>}
>
> And corresponding text for 'mfg-name' and 'model-name'.
>
> And also:
>
> OLD:
>
>   When the server detects a new hardware component, it
>   initializes a list entry in the operational state.
>
>   If the server does not support configuration of hardware
>   components, list entries in the operational state are
>   initialized with values for all nodes as detected by the
>   implementation.
>
>   Otherwise, the following procedure is followed:
>
> 1. If there is an entry in the /hardware/component list in
>the intended configuration with values for the nodes
>'class', 'parent', 'parent-rel-pos' that are equal to
>the detected values, then:
>
> 1a. If the configured entry has a value for 'mfg-name'
> that is equal to the detected value, or if the
> 'mfg-name' value cannot be detected, then 

[netmod] Question regarding YANG model revision (in context of submodules)

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hi,

 

I've been looking in various documents w.r.t. the usage of a model revision
statement, especially in the case where the YANG model is split up in
various submodules.

Assume that one of the included submodules is changed and gets a new
revision while the model this submodule belongs-to is not updated.  How is a
client supposed to know that there was a change?

The YANG library does include a list of submodules for each YANG model but
is it expected to scan that list?  What in case there is no YANG library
(this is only mandatory in the case of YANG 1.1)?  In the hello, only the
revision of the YANG model is announced, so in that case no change would be
visible although there is one.

Is there some explicit statement in RFC 7950 or 6087bis on this (meaning
that if a submodule gets a new revision, the revision of the owning YANG
model must also be updated)?  There are statements that imply that this
could be done (e.g. by specifying the revision-data when doing the include
but if no revision data is specified the behavior is "undefined" meaning
that the version of the submodule that is stored on the server will be used
but still leaves room for uncertainty).

 

Regards, Bart



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG Last Call: draft-ietf-netmod-entity-05

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hello,

The latest draft does not contain an appendix with the deprecated state tree
(to support the non-NMDA model as specified in RFC6087bis section 4.23.3),
so if it is published in this way, there is an issue at the level of BBF
TR-383.

Note that the draft-ietfnetmod-rfc7223bis does include the deprecated
container interfaces-state.

Best regards,
Bart Bogaert

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger
Sent: Wednesday, November 29, 2017 6:36 PM
To: NetMod WG 
Cc: NetMod WG Chairs 
Subject: [netmod] WG Last Call: draft-ietf-netmod-entity-05

All,

This starts a two-week working group last call on
draft-ietf-netmod-entity-05.

The working group last call ends on December 13.
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.

Thank you,
Netmod Chairs

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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Notications in interface model

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hello,

 

In the interfaces module we notice support of if-mib feature indicating
whether the IF-MIB is supported or not.  Part of this feature is a flag to
indicate whether an SNMP link-up/down trap has to be generated or not.
Looking at the YANG model itself we notice that it does not foresee any
similar capability.  We were wondering whether it has been discussed as part
of the YANG model definition for interfaces to define a general status
change notification in case an interface goes down or comes up and whether
the generation of such a notification can be enabled or disabled?

 

Regards, Bart Bogaert

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] draft-ietf-netmod-rfc6087bis-13 - section 4.26.2

[Bogaert, Bart (Nokia - BE/Antwerp)]

-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com] 
Sent: Monday, August 28, 2017 1:12 PM
To: Bogaert, Bart (Nokia - BE/Antwerp) <bart.boga...@nokia.com>
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis-13 - section 4.26.2

Hi,

"Bogaert, Bart (Nokia - BE/Antwerp)" <bart.boga...@nokia.com> wrote:
> I would like to understand why the YANG 1.1 feature logic is *much 
> more
> expensive* than YANG 1.0.

The document says "much more _expressive_".
[Bart Bogaert] Oops... need to have my eyes checked...  thanks for pointing
out.

Regards, Bart



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] What is the best way to HW identities

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hi Martin,

Using this feedback, there is a basis to continue the work in BBF

What is the best way to continue with the sub-classes w.r.t. IANA, who needs
to initiate this?  Your reply seems to suggest that irrespective of this
email, still something was required?  Anyhow, BBF can define sub-identities
to continue and align later when there would be standardized HW
sub-identities.

Best regards, Bart

-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com] 
Sent: Thursday, August 17, 2017 1:02 PM
To: Bogaert, Bart (Nokia - BE/Antwerp) <bart.boga...@nokia.com>
Cc: netmod@ietf.org; joey.b...@adtran.com; Pauwels, Ludwig (Nokia -
BE/Antwerp) <ludwig.pauw...@nokia.com>
Subject: Re: [netmod] What is the best way to HW identities

Hi,

"Bogaert, Bart (Nokia - BE/Antwerp)" <bart.boga...@nokia.com> wrote:
> Hello,
> 
>  
> 
> Within BBF we have had a discussion on the use of 
> draft-ietf-netmod-entity-03, and we would appreciate to hear the 
> opinion of IETF. More specific the discussion is on the use of the 
> leaf 'class' and the leaf 'parent-rel-pos'.
> 
>  
> 
> First some BBF context:
> 
> - the systems for which BBF specifies YANG models can be built with 
> various 'types of hardware', e.g. as pluggable item (module) it can 
> contain boards and it can contain SFP/XFPs. As 'type of port' it can 
> have connectors to terminate fastdsl links (supported over copper 
> wires), and it can have positions to insert optical fibers (e.g. the 
> position in the SFP in which one can plug the optical fiber).
> 
>  
> 
> - in the data model we have the need for some conditional data: e.g. 
> an SFP/XFP has some data that is defined in SFF-8472. This data is not 
> applicable to boards. Hence we need to distinguish between these 2 
> types of pluggable items. A 2nd example: for the optical fibers 
> terminated by an SFP/XFP, we have specific data that is also defined 
> in SFF-8472, e.g. the wavelength. This data is not applicable to 
> fastdsl ports. On fastdsl ports we have specific data that relates to 
> remote power feeding. Obviously there is no power feeding over the 
> optical fiber. There might be other ports with (for now) no specific 
> data, e.g. an rj45. Conclusion: need data conditional to the port type.
> 
>  
> 
> In draft-ietf-netmod-entity-03 we read
> 
> - "The "class" leaf is a YANG identity that describes the type of the 
> hardware.  Vendors are encouraged to either directly use one of the 
> common IANA-defined identities, or derive a more specific identity 
> from one of them.
> 
>  
> 
> - As description for 'parent-rel-pos': "An indication of the relative 
> position of this child component among all its sibling components.  
> Sibling components are defined as components that share the same 
> instance values of each of the 'parent' and 'class' nodes.
> 
>  
> 
> Based on what we read in the first bullet a thought was to specialize 
> the various hardware-class identities. Examples:
> 
>  
> 
>   identity board {
> 
> base ianahw:module;
> 
> description
> 
>   "A board is a special type of module that represents a physical 
> item, commonly known as a board or a card.";
> 
>   }
> 
>  
> 
>   identity transceiver {
> 
> base ianahw:module;
> 
> description
> 
>   "A transceiver is a special type of module that represents a 
> physical item like a pluggable SFP, an SFP+, or an XFP; or a soldered 
> SFF.";
> 
>   }
> 
>  
> 
>   identity transceiver-link {
> 
> base ianahw:port;
> 
> description
> 
>   "A transceiver-link is a special type of port that terminates an 
> optical fiber.";
> 
>   }
> 
>  
> 
>   identity rj45 {
> 
> base ianahw:port;
> 
> description
> 
>   "A RJ45 is a special type of port that terminates an electrical 
> Ethernet link.";
> 
>   }
> 
>   identity fastdsl {
> 
> base ianahw:port;
> 
> description
> 
>   "A fastdsl is a special type of port that terminates a copper 
> wire supporting a FAST or one of the DSL types link.";
> 
>   }
> 
>  
> 
> The intention with this approach: the 'class' leaf is used to 
> distinguish between all types of hardware. If hardware specific data 
> is augmented to the hardware model, then it is using a 'when' 
> condition referring to the value of the leaf 'class'.
> 
>  
> 
> Based on the description of the parent-rel-pos it is understood that 
> the value of this leaf is relative to the value of the class, so 
> numbering of e.g. the various types of port supported by one 

[netmod] What is the best way to HW identities

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hello,

 

Within BBF we have had a discussion on the use of
draft-ietf-netmod-entity-03, and we would appreciate to hear the opinion of
IETF. More specific the discussion is on the use of the leaf 'class' and the
leaf 'parent-rel-pos'.

 

First some BBF context:

- the systems for which BBF specifies YANG models can be built with various
'types of hardware', e.g. as pluggable item (module) it can contain boards
and it can contain SFP/XFPs. As 'type of port' it can have connectors to
terminate fastdsl links (supported over copper wires), and it can have
positions to insert optical fibers (e.g. the position in the SFP in which
one can plug the optical fiber).

 

- in the data model we have the need for some conditional data: e.g. an
SFP/XFP has some data that is defined in SFF-8472. This data is not
applicable to boards. Hence we need to distinguish between these 2 types of
pluggable items. A 2nd example: for the optical fibers terminated by an
SFP/XFP, we have specific data that is also defined in SFF-8472, e.g. the
wavelength. This data is not applicable to fastdsl ports. On fastdsl ports
we have specific data that relates to remote power feeding. Obviously there
is no power feeding over the optical fiber. There might be other ports with
(for now) no specific data, e.g. an rj45. Conclusion: need data conditional
to the port type.

 

In draft-ietf-netmod-entity-03 we read

- "The "class" leaf is a YANG identity that describes the type of the
hardware.  Vendors are encouraged to either directly use one of the common
IANA-defined identities, or derive a more specific identity from one of
them.

 

- As description for 'parent-rel-pos': "An indication of the relative
position of this child component among all its sibling components.  Sibling
components are defined as components that share the same instance values of
each of the 'parent' and 'class' nodes.

 

Based on what we read in the first bullet a thought was to specialize the
various hardware-class identities. Examples:

 

  identity board {

base ianahw:module;

description

  "A board is a special type of module that represents a physical item,
commonly known as a board or a card.";

  }

 

  identity transceiver {

base ianahw:module;

description

  "A transceiver is a special type of module that represents a physical
item like a pluggable SFP, an SFP+, or an XFP; or a soldered SFF.";

  }

 

  identity transceiver-link {

base ianahw:port;

description

  "A transceiver-link is a special type of port that terminates an
optical fiber.";

  }

 

  identity rj45 {

base ianahw:port;

description

  "A RJ45 is a special type of port that terminates an electrical
Ethernet link.";

  }

  identity fastdsl {

base ianahw:port;

description

  "A fastdsl is a special type of port that terminates a copper wire
supporting a FAST or one of the DSL types link.";

  }

 

The intention with this approach: the 'class' leaf is used to distinguish
between all types of hardware. If hardware specific data is augmented to the
hardware model, then it is using a 'when' condition referring to the value
of the leaf 'class'.

 

Based on the description of the parent-rel-pos it is understood that the
value of this leaf is relative to the value of the class, so numbering of
e.g. the various types of port supported by one board is independent of each
other.

 

Then the worry starts: 

- some of the BBF members understand this concept of specializing the
hardware identities and use these values for the leaf class as the way to
go, and take the impact on the numbering as a given.

 

- Others think this impact on the parent-rel-pos is not the intention and
assume a flat numbering of all childs within a parent, hence do not want to
use the class leaf for further specialization, hence want to introduce a new
separate leaf to contain the more detailed information, hence the
conditional data for the various types of hardware shall be defined with a
'when statement' referring to this new separate leaf.

 

The feedback we would appreciate from IETF: 

- did IETF consider the need for additional conditional data?

- which approach is the IETF preference?

- in case the IETF preference is to specialize the hardware identities, does
IETF think it is worth to standardize them in IANA, or is the preference to
keep these identities within BBF?

 

Regards,

Bart



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Questions on NMDA and "merged config and state"

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hello Juergen,

I have also noticed this but when I look at the type of remarks Andy is
making I get an impression that "dust has not settled" on how this will work
in "real life".

Regards, Bart
-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
Sent: Saturday, August 05, 2017 10:36 AM
To: Bogaert, Bart (Nokia - BE/Antwerp) <bart.boga...@nokia.com>
Cc: Andy Bierman <a...@yumaworks.com>; netmod@ietf.org
Subject: Re: [netmod] Questions on NMDA and "merged config and state"

On Fri, Aug 04, 2017 at 07:03:43AM +, Bogaert, Bart (Nokia - BE/Antwerp)
wrote:
> Maybe a stupid question from my side (I'm not involved  in the NMDA 
> work) but is there some kind of consensus on what is proposed in this 
> draft RFC or are we miles away from such a consensus?  Since this is 
> linked to how a server has to handle state in the proposed merging of 
> config and state under one branch of the tree coming to a conclusion 
> to me seems a requirement since in the current implementation we just 
> can't change a CT leaf in the running DS by a value that is 
> dynamically learned; in the NMDA approach that would be possible as 
> the operational DS contains both CT and CF leaves and consequently a 
> value as configured by the client can be overwritten by a dynamically 
> learned value as the value configured by the client remains untouched 
> in the running DS.  In the current implementation we would need to 
> model a CF leaf for this purpose.  At least that is how I have always 
> understood how it should be done.  As long as we do not have 
> NDMA-based server implementations we can't design and implement YANG
models as proposed in NMDA and its associated guidelines.
>

Bart,

you may want to look at draft-dsdt-nmda-guidelines-01. Protocol updates to
support NMDA are on the way as well, draft-dsdt-nmda-netconf-00 and
draft-dsdt-netconf-restconf-nmda-00.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Questions on NMDA and "merged config and state"

[Bogaert, Bart (Nokia - BE/Antwerp)]

Maybe a stupid question from my side (I'm not involved  in the NMDA work)
but is there some kind of consensus on what is proposed in this draft RFC or
are we miles away from such a consensus?  Since this is linked to how a
server has to handle state in the proposed merging of config and state under
one branch of the tree coming to a conclusion to me seems a requirement
since in the current implementation we just can't change a CT leaf in the
running DS by a value that is dynamically learned; in the NMDA approach that
would be possible as the operational DS contains both CT and CF leaves and
consequently a value as configured by the client can be overwritten by a
dynamically learned value as the value configured by the client remains
untouched in the running DS.  In the current implementation we would need to
model a CF leaf for this purpose.  At least that is how I have always
understood how it should be done.  As long as we do not have NDMA-based
server implementations we can't design and implement YANG models as proposed
in NMDA and its associated guidelines.

Regards, Bart

-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
Sent: Friday, August 04, 2017 8:29 AM
To: Andy Bierman <a...@yumaworks.com>
Cc: Bogaert, Bart (Nokia - BE/Antwerp) <bart.boga...@nokia.com>;
netmod@ietf.org
Subject: Re: [netmod] Questions on NMDA and "merged config and state"

On Thu, Aug 03, 2017 at 10:06:23AM -0700, Andy Bierman wrote:
> 
> So you are saying there is no such thing as an NMDA-compliant server.
> There are protocols that may use specific datastores in various ways.
> Different protocols can have different behavior for the same datastore.
> Sounds very fun for client developers to figure out.
>

This is what I wrote:

  The protocols (with their various capabilities) expose different sets
  of datastores. I agree, the protocol documents should state clearly
  what is required to expose for the different protocols and what is
  optional to expose.

I did not write that different protocols can have different behavior for the
same datastore. I did not write that protocols may use specific datastores
in various ways.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Questions on NMDA and "merged config and state"

[Bogaert, Bart (Nokia - BE/Antwerp)]

On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder 
<j.schoenwael...@jacobs-university.de 
<mailto:j.schoenwael...@jacobs-university.de> > wrote:

On Thu, Aug 03, 2017 at 06:59:58AM +0000, Bogaert, Bart (Nokia - BE/Antwerp) 
wrote:
>
> Just to get confirmation on my assumptions:
>
> In section 4.7.3 the origin metadata does not include 'running' as origin
> but only 'intended'.  So it seems to be mandatory for a NC server to support
> the intended datastore?

If your server does not support templates or inactive configuration or
the like, then intended is just an alias for running.





IMO this is not correct.

There are no standards at all to define these things.

Our server supports an implementation of config templates that expands the

template when it is first created.  A different proprietary implementation MAY 
choose

to expand templates in some other way.  Since there are no standards for this 
purpose,

any proprietary implementation decision is valid.



The contents of the "intended" datastore are purely proprietary.

The opaque nature of this datastore is by design and the WG accepts that 
servers

are free to choose to implement whatever datastores they want.

The origin metadata should just reflect what the server does, not mandate

any sort of datastore conformance.

[Bart Bogaert] In that case I would expect that the running is also included 
as an origin of the data in the operational datastore?



Regards, Bart





Andy







I do not think
you need to expose intended in this case. Still, the value of the
origin attribute is 'intended' since in the general case, the
configuration is coming from .

> With the introduction of the operational datastore I assume it also means
> that when someone wants to know what the client has configured on the device
> a get-config on the running datastore is required while to know the 'in-use'
> configuration a get(-config) on the operational datastore is required?

Yes. The operation, however, is likely called get-data in NETCONF, at
least this is what draft-dsdt-nmda-netconf-00 suggested.

> The Guidelines for YANG Module Authors (NMDA) - draft-dsdt-nmda-guidelines
> mentions that a derived module can be generated from the YANG models where
> state and config are merged in a single branch.  In the simple example this
> results in another YANG model with its own namespace.  I assume that this
> state YANG model will then also show up in the hello message?

The general idea is that we produce YANG modules that have config and
state merged into a single branch. Out of this YANG module, people may
generate a separate module that consists of the config false nodes
plus any additional key nodes needed to make it work. Such a YANG
module will be treated as any other YANG module. Note that YANG 1.1
started to move module announcements to the ietf-yang-library to avoid
very long module announcements during session startup.

/js

--
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>

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





smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Questions on NMDA and "merged config and state"

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hi,

 

Just to get confirmation on my assumptions:

In section 4.7.3 the origin metadata does not include 'running' as origin
but only 'intended'.  So it seems to be mandatory for a NC server to support
the intended datastore?

 

With the introduction of the operational datastore I assume it also means
that when someone wants to know what the client has configured on the device
a get-config on the running datastore is required while to know the 'in-use'
configuration a get(-config) on the operational datastore is required?

 

The Guidelines for YANG Module Authors (NMDA) - draft-dsdt-nmda-guidelines
mentions that a derived module can be generated from the YANG models where
state and config are merged in a single branch.  In the simple example this
results in another YANG model with its own namespace.  I assume that this
state YANG model will then also show up in the hello message?

 

Best regards,

Bart



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Question on intefaces-state model

[Bogaert, Bart (Nokia - BE/Antwerp)]

That's why these counters are optional in the model: if there is nothing to
return we should indeed not return 0...

-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
Sent: 14 June 2017 11:40
To: Robert Wilton <rwil...@cisco.com>
Cc: Vladimir Vassilev <vladi...@transpacket.com>; Andy Bierman
<a...@yumaworks.com>; Bogaert, Bart (Nokia - BE/Antwerp)
<bart.boga...@nokia.com>; netmod@ietf.org
Subject: Re: [netmod] Question on intefaces-state model

On Wed, Jun 14, 2017 at 10:15:22AM +0100, Robert Wilton wrote:
> 
> Returning zero values here is not useful, in fact it is misleading. I 
> think that if a server doesn't have a value to return for a particular 
> node it is much better to return nothing than to return a false value.

+1.

It took us years to kill this attitude in SNMP land. Saying a counter is
zero and never changes is largely misleading if you actually have no such
counter. It is easy to waste hours of expensive engineering time by given
people fake counters.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Question on intefaces-state model

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hi,

 

We have a question regarding the statistics container as defined in the
interfaces-state model.  This container defines one mandatory leaf
(discontinuity-time) while all other leafs are optional.  What is the
rationale behind this leaf being mandatory and not an optional field?

It does not make a lot of sense to return a discontinuity-time value and no
counters if none of the counters are relevant for a specific interface.

Another alternative could be to add, via a deviation, a when clause to the
container indicating for which ifType(s) the container is (or is not)
present. But that would lead to not supporting the IETF interfaces model to
the full extent.

 

Regards, Bart

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Question about must statement in grouping

[Bogaert, Bart (Nokia - BE/Antwerp)]

Lada, thanks for the feedback.

Any specific reason why you say that this would be more efficient when used
in the context of the parent container and not in the grouping?

Regards, Bart

-Original Message-
From: Ladislav Lhotka [mailto:lho...@nic.cz] 
Sent: 29 March 2017 14:37
To: Bogaert, Bart (Nokia - BE/Antwerp) <bart.boga...@nokia.com>; Bogaert,
Bart (Nokia - BE/Antwerp) <bart.boga...@nokia.com>; netmod@ietf.org
Subject: Re: [netmod] Question about must statement in grouping

"Bogaert, Bart (Nokia - BE/Antwerp)" <bart.boga...@nokia.com> writes:

> Changing "count(.) != 1" into "count(../a-list) != 1" in the grouping 
> does the job as expected.  So it seems that count(.) within the 
> context of the a-list applies to each element in the list and rather 
> than to the list itself?

Both versions of the XPath expression are evaluated once for each entry of
the list, and the entry's 'a-list' node is the context node. By definition,
'.'  selects the context node, so 'count(.)' is always 1. After the change,
'..' selects the parent node and 'a-list' then selects all nodes of that
name, which are the entries of the list.

Note that it would be more efficient to verify the constraint on the parent
container, with 'count(a-list) != 1'.

Lada

>
>  
>
> Regards, Bart
>
>  
>
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Bogaert, 
> Bart (Nokia - BE/Antwerp)
> Sent: 29 March 2017 12:47
> To: netmod@ietf.org
> Subject: [netmod] Question about must statement in grouping
>
>  
>
> Hi,
>
>  
>
> We have a question on the usage of a must statement within a grouping.
>
>  
>
> Assume the following grouping
>
>  
>
> grouping a-group {
>
>   list a-list {
>
> must "count(.) != 1" {
>
>   description
>
> "This list must either be empty or have at least 2 elements";
>
> }
>
> key "entry";
>
> leaf entry {
>
>   type uint16;
>
> }
>
> leaf another-entry {
>
>   type uint32;
>
> }
>
>   }
>
> }
>
>  
>
> And used in another module
>
>  
>
> container a-container {
>
>   uses a-group;
>
> }
>
>  
>
> The uses actually results in a data-tree like below
>
>  
>
>   +--rw a-container
>
>   +--rw a-list* [entry]
>
>+--rw entry   uint16
>
>+--rw another-entry   uint32
>
>  
>
> Does the usage of the grouping usage also result in the expected 
> behavior for the must statement when configuring /a-container/a-list?  
> The '.' in the must statement in the grouping refers to 'a-list' so 
> will that return 2 in case we have configured 2 elements in 
> /a-container/a-list or should we write the must statement at the level 
> of 'a-container' stating that "count(a-list) != 1" (as below)?
>
>  
>
> grouping a-group {
>
>   list a-list {
>
> key "entry";
>
> leaf entry {
>
>   type uint16;
>
> }
>
>   }
>
> }
>
>  
>
> And used in another module
>
>  
>
> container a-container {
>
>   uses a-group;
>
>   must "count(a-list) != 1" {
>
> description
>
>   "This list must either be empty or have at least 2 elements";
>
>   }
>
> }
>
>  
>
> Best regards - Vriendelijke groeten,
>
> Bart Bogaert
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Question about must statement in grouping

[Bogaert, Bart (Nokia - BE/Antwerp)]

Changing "count(.) != 1" into "count(../a-list) != 1" in the grouping does
the job as expected.  So it seems that count(.) within the context of the
a-list applies to each element in the list and rather than to the list
itself?

 

Regards, Bart

 

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Bogaert, Bart
(Nokia - BE/Antwerp)
Sent: 29 March 2017 12:47
To: netmod@ietf.org
Subject: [netmod] Question about must statement in grouping

 

Hi,

 

We have a question on the usage of a must statement within a grouping.

 

Assume the following grouping

 

grouping a-group {

  list a-list {

must "count(.) != 1" {

  description

"This list must either be empty or have at least 2 elements";

}

key "entry";

leaf entry {

  type uint16;

}

leaf another-entry {

  type uint32;

}

  }

}

 

And used in another module

 

container a-container {

  uses a-group;

}

 

The uses actually results in a data-tree like below

 

  +--rw a-container

  +--rw a-list* [entry]

   +--rw entry   uint16

   +--rw another-entry   uint32

 

Does the usage of the grouping usage also result in the expected behavior
for the must statement when configuring /a-container/a-list?  The '.' in the
must statement in the grouping refers to 'a-list' so will that return 2 in
case we have configured 2 elements in /a-container/a-list or should we write
the must statement at the level of 'a-container' stating that "count(a-list)
!= 1" (as below)?

 

grouping a-group {

  list a-list {

key "entry";

leaf entry {

  type uint16;

}

  }

}

 

And used in another module

 

container a-container {

  uses a-group;

  must "count(a-list) != 1" {

description

  "This list must either be empty or have at least 2 elements";

  }

}

 

Best regards - Vriendelijke groeten,

Bart Bogaert



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Question about must statement in grouping

[Bogaert, Bart (Nokia - BE/Antwerp)]

Hi,

 

We have a question on the usage of a must statement within a grouping.

 

Assume the following grouping

 

grouping a-group {

  list a-list {

must "count(.) != 1" {

  description

"This list must either be empty or have at least 2 elements";

}

key "entry";

leaf entry {

  type uint16;

}

leaf another-entry {

  type uint32;

}

  }

}

 

And used in another module

 

container a-container {

  uses a-group;

}

 

The uses actually results in a data-tree like below

 

  +--rw a-container

  +--rw a-list* [entry]

   +--rw entry   uint16

   +--rw another-entry   uint32

 

Does the usage of the grouping usage also result in the expected behavior
for the must statement when configuring /a-container/a-list?  The '.' in the
must statement in the grouping refers to 'a-list' so will that return 2 in
case we have configured 2 elements in /a-container/a-list or should we write
the must statement at the level of 'a-container' stating that "count(a-list)
!= 1" (as below)?

 

grouping a-group {

  list a-list {

key "entry";

leaf entry {

  type uint16;

}

  }

}

 

And used in another module

 

container a-container {

  uses a-group;

  must "count(a-list) != 1" {

description

  "This list must either be empty or have at least 2 elements";

  }

}

 

Best regards - Vriendelijke groeten,

Bart Bogaert



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Interaction of 'when' and 'default' statements

[Bogaert, Bart (Nokia - BE/Antwerp)]

William,

The when clause determines whether the node will be instantiated or not.
Only when it is instantiated (when condition evaluates to true), the default
property comes into the picture.  At least, that is how I interpret it.

Best regards - Vriendelijke groeten,
Bart Bogaert

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of William Ivory
Sent: 22 March 2017 18:56
To: Martin Bjorklund 
Cc: Nick Brown ; netmod@ietf.org
Subject: Re: [netmod] Interaction of 'when' and 'default' statements

Hi Martin,

Thanks.  Can you point me at the part of RFC 6020 that explicitly states
that 'when' wins over 'default'?

William

-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com]
Sent: 22 March 2017 17:53
To: William Ivory 
Cc: netmod@ietf.org; Nick Brown 
Subject: Re: [netmod] Interaction of 'when' and 'default' statements

William Ivory  wrote:
> Hi,
> 
> I'm looking for clarification of the 'when' and 'default' statements 
> on a leaf.  For example, if a leaf has a 'default', can it also have a 
> 'when' statement that could cause it to disappear if the 'when'
> condition evaluates to false?

Yes, and in that case the default doesn't apply.

> Section 8.3 or RFC 6020 isn't clear on how evaluation of constraints 
> should be done here, and neither the section on the 'when' statement 
> nor the 'default' section have any cross-references.

If the "when" expression evaluates to false, it's like if the whole node
doesn't exist.  A client can't set it etc.


/martin

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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod