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

2018-03-05 Thread Alex Campbell 
Presumably you will have to decide on a sensible default value to use.


What value will your actual device use after the software upgrade? That should 
be the value it stores in the data tree when performing the upgrade.




From: netmod  on behalf of Bogaert, Bart (Nokia - 
BE/Antwerp) 
Sent: Monday, 5 March 2018 10:25 p.m.
To: netmod@ietf.org
Subject: [netmod] Guideline on modeling including features and phased support 
by a device

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] I-D Action: draft-ietf-netmod-yang-data-ext-01.txt

2018-03-05 Thread internet-drafts 

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   : YANG Data Extensions
Authors : Andy Bierman
  Martin Bjorklund
  Kent Watsen
Filename: draft-ietf-netmod-yang-data-ext-01.txt
Pages   : 11
Date: 2018-03-05

Abstract:
   This document describes YANG mechanisms for defining abstract data
   structures with YANG.  It is intended to replace and extend the
   "yang-data" extension statement defined in RFC 8040.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-01
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-data-ext-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-data-ext-01


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

Re: [netmod] draft-ietf-netmod-syslog-model-23

2018-03-05 Thread Clyde Wildes (cwildes) 
Bob,

I will add your wording in the next revision.

Thanks,

Clyde

From: Bob Harold 
Date: Monday, March 5, 2018 at 11:06 AM
To: Clyde Wildes 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] draft-ietf-netmod-syslog-model-23


On Fri, Mar 2, 2018 at 5:13 PM, Clyde Wildes (cwildes) 
> wrote:
Bob,

Syslog message severity is set in RFC 5424 Table 2. The model in 
draft-ietf-netmod-syslog-model-23 conforms to that specification. A lower 
number means higher severity.


Thanks.  Can we add "A lower number means higher severity" to make it clear?

In Section 
"4.1.
 The ietf-syslog Module"
on page 11, cna we change:

From:


 typedef syslog-severity {

   type enumeration {

 enum "emergency" {

   value 0;

   description



Change to:



 typedef syslog-severity {

   description

 "Note that a lower value is a higher severity.

  Comparisons of equal-or-higher security mean equal or lower numeric 
value"

   type enumeration {

 enum "emergency" {

   value 0;

   description

--
Bob Harold


The severity-filter specifies that “all messages of the specified severity and 
greater match” and therefore will be selected. This conforms to the way that 
many vendors that we evaluated perform syslog message severity match selection.

Juniper Example:
https://www.juniper.net/documentation/en_US/junos12.3/topics/task/configuration/syslog-single-chassis-facility-severity-messages-specifying.html

“Messages from the facility that are rated at that level or higher are logged 
to the destination”

Linux rsyslogd Example:
http://www.rsyslog.com/doc/v8-stable/configuration/filters.html#selectors

“The behavior of the original BSD syslogd is that all messages of the specified 
priority and higher are logged according to the given action. Rsyslogd behaves 
the same…”

Changing the table to match higher severity to higher number means that we 
would not conform the RFC 5424.

Note: I do see a typo in the description for severity-filter (the word “use” is 
missing):

else compare message severity with the specified severity
  according to the default compare rule (all messages of the
  specified severity and greater match) or if the
  select-adv-compare feature is present, the advance-compare
  rule.

should be:

else compare message severity with the specified severity
  according to the default compare rule (all messages of the
  specified severity and greater match) or if the
  select-adv-compare feature is present, use the advance-compare
  rule.

Thanks,

Clyde

From: netmod > on 
behalf of Bob Harold >
Date: Friday, March 2, 2018 at 12:33 PM
To: "netmod@ietf.org" 
>
Subject: [netmod] draft-ietf-netmod-syslog-model-23

Sorry for being late to the discussion - just joined this group.

Can we have "higher severity" match "higher number" in the enumerated values, 
to avoid confusion?

In section 4.1.  The ietf-syslog Module
on Page 11

typedef syslog-severity {

-- should be in the order:
debug=0
emergency=7

because "severity-filter" uses "equals-or-higher" which means "higher severity" 
but should also mean "higher number" to avoid confusion.
--
Bob Harold

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

Re: [netmod] draft-ietf-netmod-syslog-model-23

2018-03-05 Thread Bob Harold 
On Fri, Mar 2, 2018 at 5:13 PM, Clyde Wildes (cwildes) 
wrote:

> Bob,
>
>
>
> Syslog message severity is set in RFC 5424 Table 2. The model in
> draft-ietf-netmod-syslog-model-23 conforms to that specification. A lower
> number means higher severity.
>
>
>

Thanks.  Can we add "A lower number means higher severity" to make it clear?

In Section "4.1
.
The ietf-syslog Module"
on page 11, cna we change:

From:

 typedef syslog-severity {
   type enumeration {
 enum "emergency" {
   value 0;
   description


Change to:


 typedef syslog-severity {

   description

 "Note that a lower value is a higher severity.

  Comparisons of equal-or-higher security mean equal or lower
numeric value"
   type enumeration {
 enum "emergency" {
   value 0;
   description


-- 
Bob Harold


>
> The severity-filter specifies that “all messages of the specified severity
> and greater match” and therefore will be selected. This conforms to the way
> that many vendors that we evaluated perform syslog message severity match
> selection.
>
>
>
> Juniper Example:
>
> https://www.juniper.net/documentation/en_US/junos12.3/topics
> /task/configuration/syslog-single-chassis-facility-
> severity-messages-specifying.html
>
>
>
> “Messages from the facility that are rated at that level or higher are
> logged to the destination”
>
>
>
> Linux rsyslogd Example:
>
> http://www.rsyslog.com/doc/v8-stable/configuration/filters.html#selectors
>
>
>
> “The behavior of the original BSD syslogd is that all messages of the
> specified priority and higher are logged according to the given action.
> Rsyslogd behaves the same…”
>
>
>
> Changing the table to match higher severity to higher number means that we
> would not conform the RFC 5424.
>
>
>
> Note: I do see a typo in the description for severity-filter (the word
> “use” is missing):
>
>
>
> else compare message severity with the specified severity
>
>   according to the default compare rule (all messages of the
>
>   specified severity and greater match) or if the
>
>   select-adv-compare feature is present, the advance-compare
>
>   rule.
>
>
>
> should be:
>
>
>
> else compare message severity with the specified severity
>
>   according to the default compare rule (all messages of the
>
>   specified severity and greater match) or if the
>
>   select-adv-compare feature is present, use the advance-compare
>
>   rule.
>
>
>
> Thanks,
>
>
>
> Clyde
>
>
>
> *From: *netmod  on behalf of Bob Harold <
> rharo...@umich.edu>
> *Date: *Friday, March 2, 2018 at 12:33 PM
> *To: *"netmod@ietf.org" 
> *Subject: *[netmod] draft-ietf-netmod-syslog-model-23
>
>
>
> Sorry for being late to the discussion - just joined this group.
>
> Can we have "higher severity" match "higher number" in the enumerated
> values, to avoid confusion?
>
> In section 4.1.  The ietf-syslog Module
> on Page 11
>
> typedef syslog-severity {
>
> -- should be in the order:
> debug=0
> emergency=7
>
> because "severity-filter" uses "equals-or-higher" which means "higher
> severity" but should also mean "higher number" to avoid confusion.
>
> --
> Bob Harold
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] choice/case in tree diagrams

2018-03-05 Thread Mahesh Jethanandani 


> On Mar 5, 2018, at 6:27 AM, Martin Bjorklund  wrote:
> 
> Martin Bjorklund > wrote:
>> Juergen Schoenwaelder  wrote:
>>> On Mon, Mar 05, 2018 at 02:54:18PM +0100, Martin Bjorklund wrote:
> 
> So it seems the running code got it right. ;-)
 
 As the author of that code, I think that was purely by accident...
 
 But I'm not convinced it is the correct solution.  We have one example
 in the other thread where someone was confused by the "rw" flag and
 thought that it implied that the node would be present in the data
 tree.
 
>>> 
>>> So what does rw mean?
>>> 
>>> (i)  The schema node has a rw property.
>>> (ii) The schema node can be instantiated and the instantiated data node
>>> has a rw property.
>>> 
>>> I think it is difficult to have both at the same time. If the tree is
>>> a representation of schema nodes, then (i) seems to make more
>>> sense. That said, the explanation in 2.6 is somewhat vague since it
>>> says 'data' and not 'nodes' (like everywhere else):
>>> 
>>> OLD:
>>> 
>>>is one of:
>>> rw  for configuration data
>>> ro  for non-configuration data, output parameters to rpcs
>>> and actions, and notification parameters
>>> 
>>> NEW:
>>> 
>>>is one of:
>>> rw  for configuration data nodes
>>> ro  for non-configuration data nodes, output parameters to rpcs
>>> and actions, and notification parameters
>> 
>> I think this is ok.  But that means that we also have to add:
>> 
>>   --  for a choice or case node
>> 
>> But in order to be consistent, we should probably have:
>> 
>>   --  for a choice, case, input or output node
> 
> Whoops, it shouldn't be "--".  Somehow we should say that no flags are
> used for choice,case,input,output.

I would agree, as having choice/case statements represented as schema nodes is 
not only confusing in the tree diagram, but also confusing when constructing an 
example. The tree diagram represents it as a node, where one would put it in 
the example, but validation complained about it (not being a node).

> 
> 
> /martin
> 
> 
>> 
>> 
>> This means that the correct tree syntax for choice and case will be:
>> 
>> +-- (subnet)?
>>+-- :(prefix-length)
>>|  +--rw prefix-length?   uint8
>>+-- :(netmask)
>>   +--rw netmask? yang:dotted-quad
>> 
>> 
>> /martin
>> 
>> 
>>> The document (as far as I searched for it) does not clearly say that
>>> 'node' means 'schema node'. In hindsight, it might have been useful to
>>> explicitely import terminology from RFC 7950 and to use it carefully
>>> (RFC 7950 has 'schema node' and 'data node' but here we largely talk
>>> about 'nodes' - and my assumption is that this means 'schema nodes'.)
>> 
>> ___
>> 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 
> 
Mahesh Jethanandani
mjethanand...@gmail.com

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

Re: [netmod] choice/case in tree diagrams

2018-03-05 Thread Per Hedeland 
On 2018-03-05 16:06, Ladislav Lhotka wrote:
> On Mon, 2018-03-05 at 15:49 +0100, Per Hedeland wrote:
>> On 2018-03-05 15:41, Ladislav Lhotka wrote:
>>> On Mon, 2018-03-05 at 15:26 +0100, Martin Bjorklund wrote:
 Juergen Schoenwaelder  wrote:
> On Mon, Mar 05, 2018 at 02:54:18PM +0100, Martin Bjorklund wrote:
>>>
>>> So it seems the running code got it right. ;-)
>>
>> As the author of that code, I think that was purely by accident...
>>
>> But I'm not convinced it is the correct solution.  We have one example
>> in the other thread where someone was confused by the "rw" flag and
>> thought that it implied that the node would be present in the data
>> tree.
>>
>
> So what does rw mean?
>
> (i)  The schema node has a rw property.
> (ii) The schema node can be instantiated and the instantiated data node
>  has a rw property.
>
> I think it is difficult to have both at the same time. If the tree is
> a representation of schema nodes, then (i) seems to make more
> sense. That said, the explanation in 2.6 is somewhat vague since it
> says 'data' and not 'nodes' (like everywhere else):
>
> OLD:
>
> is one of:
>  rw  for configuration data
>  ro  for non-configuration data, output parameters to rpcs
>  and actions, and notification parameters
>
> NEW:
>
> is one of:
>  rw  for configuration data nodes
>  ro  for non-configuration data nodes, output parameters to rpcs
>  and actions, and notification parameters

 I think this is ok.  But that means that we also have to add:

--  for a choice or case node

 But in order to be consistent, we should probably have:

--  for a choice, case, input or output node
>>>
>>> But unlike the three other statements, "choice" can have the config
>>> substatement, so "rw/ro" makes sense there.
>>
>> I don't think so - that config statement does not a define a property of
>> the choice node (it can obviously neither be read nor written), only a
>> default for descendant data nodes, as described in section 7.21.1 of RFC
>> 7950.
> 
> It is not a default - if a choice has "config false", then no descendant can 
> be
> "config true". One of the benefits of having rw/ro in the ascii tree is to see
> where a state data subtree actually starts.

It is a default, but yes, it is also a restriction in the specific case
of the argument being "false" at a point where the default would
otherwise be "true". And in that case it is equivalent to having "config
false" on all the descendant data nodes, and they will of course be
flagged as "ro" regardless of whether the "config false" comes from the
choice or the individual data nodes - and that is where the state *data*
suntree(s) actually start(s).

So I guess the question then is whether this specific case motivates
always having flags on specifically choice nodes, while the other
non-data nodes have no flags. Since the 'config' statement is ignored in
rpc/action input/output and notification, choice nodes there should then
presumably have "-w"/"ro"/"-n". Personally I think the diagram is
clearer with flags only on the data nodes.

--Per

> Lada
> 
>>
>> --Per
>>
>>> Lada
>>>


 This means that the correct tree syntax for choice and case will be:

  +-- (subnet)?
 +-- :(prefix-length)
 |  +--rw prefix-length?   uint8
 +-- :(netmask)
+--rw netmask? yang:dotted-quad


 /martin


> The document (as far as I searched for it) does not clearly say that
> 'node' means 'schema node'. In hindsight, it might have been useful to
> explicitely import terminology from RFC 7950 and to use it carefully
> (RFC 7950 has 'schema node' and 'data node' but here we largely talk
> about 'nodes' - and my assumption is that this means 'schema nodes'.)

 ___
 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] choice/case in tree diagrams

2018-03-05 Thread Ladislav Lhotka 
On Mon, 2018-03-05 at 15:49 +0100, Per Hedeland wrote:
> On 2018-03-05 15:41, Ladislav Lhotka wrote:
> > On Mon, 2018-03-05 at 15:26 +0100, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder  wrote:
> > > > On Mon, Mar 05, 2018 at 02:54:18PM +0100, Martin Bjorklund wrote:
> > > > > > 
> > > > > > So it seems the running code got it right. ;-)
> > > > > 
> > > > > As the author of that code, I think that was purely by accident...
> > > > > 
> > > > > But I'm not convinced it is the correct solution.  We have one example
> > > > > in the other thread where someone was confused by the "rw" flag and
> > > > > thought that it implied that the node would be present in the data
> > > > > tree.
> > > > > 
> > > > 
> > > > So what does rw mean?
> > > > 
> > > > (i)  The schema node has a rw property.
> > > > (ii) The schema node can be instantiated and the instantiated data node
> > > >  has a rw property.
> > > > 
> > > > I think it is difficult to have both at the same time. If the tree is
> > > > a representation of schema nodes, then (i) seems to make more
> > > > sense. That said, the explanation in 2.6 is somewhat vague since it
> > > > says 'data' and not 'nodes' (like everywhere else):
> > > > 
> > > > OLD:
> > > > 
> > > > is one of:
> > > >  rw  for configuration data
> > > >  ro  for non-configuration data, output parameters to rpcs
> > > >  and actions, and notification parameters
> > > > 
> > > > NEW:
> > > > 
> > > > is one of:
> > > >  rw  for configuration data nodes
> > > >  ro  for non-configuration data nodes, output parameters to rpcs
> > > >  and actions, and notification parameters
> > > 
> > > I think this is ok.  But that means that we also have to add:
> > > 
> > >--  for a choice or case node
> > > 
> > > But in order to be consistent, we should probably have:
> > > 
> > >--  for a choice, case, input or output node
> > 
> > But unlike the three other statements, "choice" can have the config
> > substatement, so "rw/ro" makes sense there.
> 
> I don't think so - that config statement does not a define a property of
> the choice node (it can obviously neither be read nor written), only a
> default for descendant data nodes, as described in section 7.21.1 of RFC
> 7950.

It is not a default - if a choice has "config false", then no descendant can be
"config true". One of the benefits of having rw/ro in the ascii tree is to see
where a state data subtree actually starts.

Lada

> 
> --Per
> 
> > Lada
> > 
> > > 
> > > 
> > > This means that the correct tree syntax for choice and case will be:
> > > 
> > >  +-- (subnet)?
> > > +-- :(prefix-length)
> > > |  +--rw prefix-length?   uint8
> > > +-- :(netmask)
> > >+--rw netmask? yang:dotted-quad
> > > 
> > > 
> > > /martin
> > > 
> > > 
> > > > The document (as far as I searched for it) does not clearly say that
> > > > 'node' means 'schema node'. In hindsight, it might have been useful to
> > > > explicitely import terminology from RFC 7950 and to use it carefully
> > > > (RFC 7950 has 'schema node' and 'data node' but here we largely talk
> > > > about 'nodes' - and my assumption is that this means 'schema nodes'.)
> > > 
> > > ___
> > > 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
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] choice/case in tree diagrams

2018-03-05 Thread Per Hedeland 
On 2018-03-05 15:41, Ladislav Lhotka wrote:
> On Mon, 2018-03-05 at 15:26 +0100, Martin Bjorklund wrote:
>> Juergen Schoenwaelder  wrote:
>>> On Mon, Mar 05, 2018 at 02:54:18PM +0100, Martin Bjorklund wrote:
>
> So it seems the running code got it right. ;-)

 As the author of that code, I think that was purely by accident...

 But I'm not convinced it is the correct solution.  We have one example
 in the other thread where someone was confused by the "rw" flag and
 thought that it implied that the node would be present in the data
 tree.

>>>
>>> So what does rw mean?
>>>
>>> (i)  The schema node has a rw property.
>>> (ii) The schema node can be instantiated and the instantiated data node
>>>  has a rw property.
>>>
>>> I think it is difficult to have both at the same time. If the tree is
>>> a representation of schema nodes, then (i) seems to make more
>>> sense. That said, the explanation in 2.6 is somewhat vague since it
>>> says 'data' and not 'nodes' (like everywhere else):
>>>
>>> OLD:
>>>
>>> is one of:
>>>  rw  for configuration data
>>>  ro  for non-configuration data, output parameters to rpcs
>>>  and actions, and notification parameters
>>>
>>> NEW:
>>>
>>> is one of:
>>>  rw  for configuration data nodes
>>>  ro  for non-configuration data nodes, output parameters to rpcs
>>>  and actions, and notification parameters
>>
>> I think this is ok.  But that means that we also have to add:
>>
>>--  for a choice or case node
>>
>> But in order to be consistent, we should probably have:
>>
>>--  for a choice, case, input or output node
> 
> But unlike the three other statements, "choice" can have the config
> substatement, so "rw/ro" makes sense there.

I don't think so - that config statement does not a define a property of
the choice node (it can obviously neither be read nor written), only a
default for descendant data nodes, as described in section 7.21.1 of RFC
7950.

--Per

> Lada
> 
>>
>>
>> This means that the correct tree syntax for choice and case will be:
>>
>>  +-- (subnet)?
>> +-- :(prefix-length)
>> |  +--rw prefix-length?   uint8
>> +-- :(netmask)
>>+--rw netmask? yang:dotted-quad
>>
>>
>> /martin
>>
>>
>>> The document (as far as I searched for it) does not clearly say that
>>> 'node' means 'schema node'. In hindsight, it might have been useful to
>>> explicitely import terminology from RFC 7950 and to use it carefully
>>> (RFC 7950 has 'schema node' and 'data node' but here we largely talk
>>> about 'nodes' - and my assumption is that this means 'schema nodes'.)
>>
>> ___
>> 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] choice/case in tree diagrams

2018-03-05 Thread Ladislav Lhotka 
On Mon, 2018-03-05 at 15:26 +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Mon, Mar 05, 2018 at 02:54:18PM +0100, Martin Bjorklund wrote:
> > > > 
> > > > So it seems the running code got it right. ;-)
> > > 
> > > As the author of that code, I think that was purely by accident...
> > > 
> > > But I'm not convinced it is the correct solution.  We have one example
> > > in the other thread where someone was confused by the "rw" flag and
> > > thought that it implied that the node would be present in the data
> > > tree.
> > > 
> > 
> > So what does rw mean?
> > 
> > (i)  The schema node has a rw property.
> > (ii) The schema node can be instantiated and the instantiated data node
> >  has a rw property.
> > 
> > I think it is difficult to have both at the same time. If the tree is
> > a representation of schema nodes, then (i) seems to make more
> > sense. That said, the explanation in 2.6 is somewhat vague since it
> > says 'data' and not 'nodes' (like everywhere else):
> > 
> > OLD:
> > 
> > is one of:
> >  rw  for configuration data
> >  ro  for non-configuration data, output parameters to rpcs
> >  and actions, and notification parameters
> > 
> > NEW:
> > 
> > is one of:
> >  rw  for configuration data nodes
> >  ro  for non-configuration data nodes, output parameters to rpcs
> >  and actions, and notification parameters
> 
> I think this is ok.  But that means that we also have to add:
> 
>--  for a choice or case node
> 
> But in order to be consistent, we should probably have:
> 
>--  for a choice, case, input or output node

But unlike the three other statements, "choice" can have the config
substatement, so "rw/ro" makes sense there.

Lada

> 
> 
> This means that the correct tree syntax for choice and case will be:
> 
>  +-- (subnet)?
> +-- :(prefix-length)
> |  +--rw prefix-length?   uint8
> +-- :(netmask)
>+--rw netmask? yang:dotted-quad
> 
> 
> /martin
> 
> 
> > The document (as far as I searched for it) does not clearly say that
> > 'node' means 'schema node'. In hindsight, it might have been useful to
> > explicitely import terminology from RFC 7950 and to use it carefully
> > (RFC 7950 has 'schema node' and 'data node' but here we largely talk
> > about 'nodes' - and my assumption is that this means 'schema nodes'.)
> 
> ___
> 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

Re: [netmod] choice/case in tree diagrams

2018-03-05 Thread Martin Bjorklund 
Juergen Schoenwaelder  wrote:
> On Mon, Mar 05, 2018 at 02:54:18PM +0100, Martin Bjorklund wrote:
> > > 
> > > So it seems the running code got it right. ;-)
> > 
> > As the author of that code, I think that was purely by accident...
> > 
> > But I'm not convinced it is the correct solution.  We have one example
> > in the other thread where someone was confused by the "rw" flag and
> > thought that it implied that the node would be present in the data
> > tree.
> >
> 
> So what does rw mean?
> 
> (i)  The schema node has a rw property.
> (ii) The schema node can be instantiated and the instantiated data node
>  has a rw property.
> 
> I think it is difficult to have both at the same time. If the tree is
> a representation of schema nodes, then (i) seems to make more
> sense. That said, the explanation in 2.6 is somewhat vague since it
> says 'data' and not 'nodes' (like everywhere else):
> 
> OLD:
> 
> is one of:
>  rw  for configuration data
>  ro  for non-configuration data, output parameters to rpcs
>  and actions, and notification parameters
> 
> NEW:
> 
> is one of:
>  rw  for configuration data nodes
>  ro  for non-configuration data nodes, output parameters to rpcs
>  and actions, and notification parameters

I think this is ok.  But that means that we also have to add:

   --  for a choice or case node

But in order to be consistent, we should probably have:

   --  for a choice, case, input or output node


This means that the correct tree syntax for choice and case will be:

 +-- (subnet)?
+-- :(prefix-length)
|  +--rw prefix-length?   uint8
+-- :(netmask)
   +--rw netmask? yang:dotted-quad


/martin


> The document (as far as I searched for it) does not clearly say that
> 'node' means 'schema node'. In hindsight, it might have been useful to
> explicitely import terminology from RFC 7950 and to use it carefully
> (RFC 7950 has 'schema node' and 'data node' but here we largely talk
> about 'nodes' - and my assumption is that this means 'schema nodes'.)

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

Re: [netmod] choice/case in tree diagrams

2018-03-05 Thread Vladimir Vassilev 

On 03/05/2018 02:54 PM, Martin Bjorklund wrote:


Juergen Schoenwaelder  wrote:

On Mon, Mar 05, 2018 at 02:14:26PM +0100, Vladimir Vassilev wrote:

On 03/05/2018 01:50 PM, Juergen Schoenwaelder wrote:


I prefer that the choice/case nodes do not have any flags since they
are not having a config true/false property on their own. And less
clutter is better.

'choice' statements have 'config' substatement while 'case' do not. I myself
figured that out while I was implementing tree diagrams support.

I would prefer the current pyang output and a change to the yang-tree
document to specify that nodes without config substatement do not have
.


So it seems the running code got it right. ;-)

As the author of that code, I think that was purely by accident...

But I'm not convinced it is the correct solution.  We have one example
in the other thread where someone was confused by the "rw" flag and
thought that it implied that the node would be present in the data
tree.
+1. There are indeed very few 'config false;' statements in 'choice's in 
use and they do not justify the clutter and confusion of 'choice' 
representations in all tree diagrams. With that clarification I am not 
against the change specified in alternative 2.


Vladimir

/martin


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

Re: [netmod] choice/case in tree diagrams

2018-03-05 Thread Juergen Schoenwaelder 
On Mon, Mar 05, 2018 at 02:54:18PM +0100, Martin Bjorklund wrote:
> > 
> > So it seems the running code got it right. ;-)
> 
> As the author of that code, I think that was purely by accident...
> 
> But I'm not convinced it is the correct solution.  We have one example
> in the other thread where someone was confused by the "rw" flag and
> thought that it implied that the node would be present in the data
> tree.
>

So what does rw mean?

(i)  The schema node has a rw property.
(ii) The schema node can be instantiated and the instantiated data node
 has a rw property.

I think it is difficult to have both at the same time. If the tree is
a representation of schema nodes, then (i) seems to make more
sense. That said, the explanation in 2.6 is somewhat vague since it
says 'data' and not 'nodes' (like everywhere else):

OLD:

is one of:
 rw  for configuration data
 ro  for non-configuration data, output parameters to rpcs
 and actions, and notification parameters

NEW:

is one of:
 rw  for configuration data nodes
 ro  for non-configuration data nodes, output parameters to rpcs
 and actions, and notification parameters

The document (as far as I searched for it) does not clearly say that
'node' means 'schema node'. In hindsight, it might have been useful to
explicitely import terminology from RFC 7950 and to use it carefully
(RFC 7950 has 'schema node' and 'data node' but here we largely talk
about 'nodes' - and my assumption is that this means 'schema nodes'.)

/js

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

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

[netmod] [Errata Verified] RFC7950 (5274)

2018-03-05 Thread RFC Errata System 
The following errata report has been verified for RFC7950,
"The YANG 1.1 Data Modeling Language". 

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5274

--
Status: Verified
Type: Technical

Reported by: Kent Watsen 
Date Reported: 2018-03-04
Verified by: Benoit Claise (IESG)

Section: 7.16.3

Original Text
-
   A corresponding XML instance example of the complete notification:

 
   2008-07-08T00:01:00Z
   
 fault
 
   /ex:interface[ex:name='Ethernet0']
 
 major
   
 

Corrected Text
--
   A corresponding XML instance example of the complete notification
   follows.  This example reports an event for an interface from the
   "example-foo" module defined in Section 13.1.1.

 
   2008-07-08T00:01:00Z
   
 fault
 
   /ex:interface[ex:name='Ethernet0']
 
 major
   
 


Notes
-
The "ex" prefix is not declared.  The "example-foo" module in 13.1.1 is the 
only module in the draft that matches the given instance-identifier.  An 
alternative fix would be to use a different module and a matching 
instance-identifier.

--
RFC7950 (draft-ietf-netmod-rfc6020bis-14)
--
Title   : The YANG 1.1 Data Modeling Language
Publication Date: August 2016
Author(s)   : M. Bjorklund, Ed.
Category: PROPOSED STANDARD
Source  : Network Modeling
Area: Operations and Management
Stream  : IETF
Verifying Party : IESG

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

Re: [netmod] choice/case in tree diagrams

2018-03-05 Thread Martin Bjorklund 
Juergen Schoenwaelder  wrote:
> On Mon, Mar 05, 2018 at 02:14:26PM +0100, Vladimir Vassilev wrote:
> > On 03/05/2018 01:50 PM, Juergen Schoenwaelder wrote:
> > 
> > > I prefer that the choice/case nodes do not have any flags since they
> > > are not having a config true/false property on their own. And less
> > > clutter is better.
> >
> > 'choice' statements have 'config' substatement while 'case' do not. I myself
> > figured that out while I was implementing tree diagrams support.
> > 
> > I would prefer the current pyang output and a change to the yang-tree
> > document to specify that nodes without config substatement do not have
> > .
> >
> 
> So it seems the running code got it right. ;-)

As the author of that code, I think that was purely by accident...

But I'm not convinced it is the correct solution.  We have one example
in the other thread where someone was confused by the "rw" flag and
thought that it implied that the node would be present in the data
tree.


/martin

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

Re: [netmod] choice/case in tree diagrams

2018-03-05 Thread Juergen Schoenwaelder 
On Mon, Mar 05, 2018 at 02:14:26PM +0100, Vladimir Vassilev wrote:
> On 03/05/2018 01:50 PM, Juergen Schoenwaelder wrote:
> 
> > I prefer that the choice/case nodes do not have any flags since they
> > are not having a config true/false property on their own. And less
> > clutter is better.
>
> 'choice' statements have 'config' substatement while 'case' do not. I myself
> figured that out while I was implementing tree diagrams support.
> 
> I would prefer the current pyang output and a change to the yang-tree
> document to specify that nodes without config substatement do not have
> .
>

So it seems the running code got it right. ;-)

/js

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

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

Re: [netmod] [Technical Errata Reported] RFC7950 (5274)

2018-03-05 Thread Martin Bjorklund 
Hi,

This errata is correct and should be accepted.

I think the actual URI to use is less important, so the proposed URI
is fine.


/martin


RFC Errata System  wrote:
> The following errata report has been submitted for RFC7950,
> "The YANG 1.1 Data Modeling Language".
> 
> --
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5274
> 
> --
> Type: Technical
> Reported by: Kent Watsen 
> 
> Section: 7.16.3
> 
> Original Text
> -
>A corresponding XML instance example of the complete notification:
> 
>  xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
>2008-07-08T00:01:00Z
>
>  fault
>  
>/ex:interface[ex:name='Ethernet0']
>  
>  major
>
>  
> 
> Corrected Text
> --
>A corresponding XML instance example of the complete notification
>follows.  This example reports an event for an interface from the
>"example-foo" module defined in Section 13.1.1.
> 
>  xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
>2008-07-08T00:01:00Z
>
>  fault
>  
>/ex:interface[ex:name='Ethernet0']
>  
>  major
>
>  
> 
> 
> Notes
> -
> The "ex" prefix is not declared.  The "example-foo" module in 13.1.1 is the 
> only module in the draft that matches the given instance-identifier.  An 
> alternative fix would be to use a different module and a matching 
> instance-identifier.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> --
> Title   : The YANG 1.1 Data Modeling Language
> Publication Date: August 2016
> Author(s)   : M. Bjorklund, Ed.
> Category: PROPOSED STANDARD
> Source  : Network Modeling
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
> 

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

Re: [netmod] choice/case in tree diagrams

2018-03-05 Thread Vladimir Vassilev 

On 03/05/2018 01:50 PM, Juergen Schoenwaelder wrote:


I prefer that the choice/case nodes do not have any flags since they
are not having a config true/false property on their own. And less
clutter is better.
'choice' statements have 'config' substatement while 'case' do not. I 
myself figured that out while I was implementing tree diagrams support.


I would prefer the current pyang output and a change to the yang-tree 
document to specify that nodes without config substatement do not have 
.


Vladimir


/js

On Mon, Mar 05, 2018 at 12:26:27PM +0100, Martin Bjorklund wrote:

Hi,

Lifting this issue to its own thread.

With this snippet:

 choice subnet {
   case prefix-length {
 leaf prefix-length {
   type uint8;
 }
   }
   case netmask {
 leaf netmask {
   type yang:dotted-quad;
 }
   }
 }

pyang prints choice/case nodes like this:

  +--rw (subnet)?
 +--:(prefix-length)
 |  +--rw prefix-length?   uint8
 +--:(netmask)
+--rw netmask? yang:dotted-quad

With the syntax defined in the yang-tree document:

   --   

it means that the choice node has  just like any other node (in
this case "rw"), but the case node has "" as , and no space
after the "--".

This is clearly inconsistent, and something needs to be fixed.

The current yang-tree document doesn't say that choice/case should be
treated differently than other nodes.

Alternatives:

   1)  The document is correct, this is a bug in pyang, the output
   should be:

  +--rw (subnet)?
 +--rw :(prefix-length)
 |  +--rw prefix-length?   uint8
 +--rw :(netmask)
+--rw netmask? yang:dotted-quad

   2)  Since the choice/case nodes are not present in the data tree,
   they should not have any flags.  The document should be fixed to
   allow empty flags so we have:

  +-- (subnet)?
 +-- :(prefix-length)
 |  +--rw prefix-length?   uint8
 +-- :(netmask)
+--rw netmask? yang:dotted-quad


Note that the document is currently in AUTH48.

Something needs to be done in the document though, b/c it shows the
current pyang output in an example.



/martin

___
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] choice/case in tree diagrams

2018-03-05 Thread Juergen Schoenwaelder 
I prefer that the choice/case nodes do not have any flags since they
are not having a config true/false property on their own. And less
clutter is better.

/js

On Mon, Mar 05, 2018 at 12:26:27PM +0100, Martin Bjorklund wrote:
> Hi,
> 
> Lifting this issue to its own thread.
> 
> With this snippet:
> 
> choice subnet {
>   case prefix-length {
> leaf prefix-length {
>   type uint8;
> }
>   }
>   case netmask {
> leaf netmask {
>   type yang:dotted-quad;
> }
>   }
> }
> 
> pyang prints choice/case nodes like this:
> 
>  +--rw (subnet)?
> +--:(prefix-length)
> |  +--rw prefix-length?   uint8
> +--:(netmask)
>+--rw netmask? yang:dotted-quad
> 
> With the syntax defined in the yang-tree document:
> 
>   --   
> 
> it means that the choice node has  just like any other node (in
> this case "rw"), but the case node has "" as , and no space
> after the "--".
> 
> This is clearly inconsistent, and something needs to be fixed.
> 
> The current yang-tree document doesn't say that choice/case should be
> treated differently than other nodes.
> 
> Alternatives:
> 
>   1)  The document is correct, this is a bug in pyang, the output
>   should be:
> 
>  +--rw (subnet)?
> +--rw :(prefix-length)
> |  +--rw prefix-length?   uint8
> +--rw :(netmask)
>+--rw netmask? yang:dotted-quad
> 
>   2)  Since the choice/case nodes are not present in the data tree,
>   they should not have any flags.  The document should be fixed to
>   allow empty flags so we have:
> 
>  +-- (subnet)?
> +-- :(prefix-length)
> |  +--rw prefix-length?   uint8
> +-- :(netmask)
>+--rw netmask? yang:dotted-quad
> 
> 
> Note that the document is currently in AUTH48.
> 
> Something needs to be done in the document though, b/c it shows the
> current pyang output in an example.
> 
> 
> 
> /martin
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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

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

[netmod] choice/case in tree diagrams

2018-03-05 Thread Martin Bjorklund 
Hi,

Lifting this issue to its own thread.

With this snippet:

choice subnet {
  case prefix-length {
leaf prefix-length {
  type uint8;
}
  }
  case netmask {
leaf netmask {
  type yang:dotted-quad;
}
  }
}

pyang prints choice/case nodes like this:

 +--rw (subnet)?
+--:(prefix-length)
|  +--rw prefix-length?   uint8
+--:(netmask)
   +--rw netmask? yang:dotted-quad

With the syntax defined in the yang-tree document:

  --   

it means that the choice node has  just like any other node (in
this case "rw"), but the case node has "" as , and no space
after the "--".

This is clearly inconsistent, and something needs to be fixed.

The current yang-tree document doesn't say that choice/case should be
treated differently than other nodes.

Alternatives:

  1)  The document is correct, this is a bug in pyang, the output
  should be:

 +--rw (subnet)?
+--rw :(prefix-length)
|  +--rw prefix-length?   uint8
+--rw :(netmask)
   +--rw netmask? yang:dotted-quad

  2)  Since the choice/case nodes are not present in the data tree,
  they should not have any flags.  The document should be fixed to
  allow empty flags so we have:

 +-- (subnet)?
+-- :(prefix-length)
|  +--rw prefix-length?   uint8
+-- :(netmask)
   +--rw netmask? yang:dotted-quad


Note that the document is currently in AUTH48.

Something needs to be done in the document though, b/c it shows the
current pyang output in an example.



/martin

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

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

2018-03-05 Thread 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