[netmod] unresolved module prefixes in grouping definitions

[Vladimir Vassilev]

Hi,

Should YANG validation fail if a module defines a grouping that contains 
unresolved module prefix or should this generate only warning. In case 
the grouping is not instantiated that is.



For example ietf-netconf-cli...@2022-05-24.yang does not import 
ietf-keystore and has no prefix 'ks'. However it defines a /ks:keystore 
leafref in one grouping.



/Vladimir

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

Re: [netmod] WGLC on draft-ietf-netmod-rfc6991-bis-11

[Vladimir Vassilev]

On 18/02/2022 18.11, Andy Bierman wrote:



On Fri, Feb 18, 2022 at 8:39 AM Martin Björklund > wrote:


Hi,

I didn't find any discussion about the new percent types in the list
archives.  Do we really need three types for percent?  We can now
express 4294967295 percent, but not 10.5 percent.



IMO it is a mistake to have too many ways to do the same thing.
We already have the "units" statement to add details like "percent" 
and "centiseconds".

(And there are RFCs already that define types this way.)

uint8 and int32 and uint32 for percent? Plus the units approach?


+1

How about adding decimal64 as an option? Then 10.5 is solved.

/Vladimir

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

Re: [netmod] [bmwg] WG Adoption Call for draft-vassilev-bmwg-network-interconnect-tester-06

[Vladimir Vassilev]

On 09/09/2021 12.05, tom petch wrote:

From: bmwg  on behalf of MORTON JR., AL 

Sent: 08 September 2021 14:35

BMWG:

A WG Adoption Call for the Internet-Draft on

   A YANG Data Model for Network Interconnect Tester Management
draft-vassilev-bmwg-network-interconnect-tester-06

will be open from 8 September through 6 October, 2021.

Please weigh-in on this topic by providing:

+ whether or not you believe the working group should adopt this Internet-Draft
as a work item, for eventual publication as an Informational RFC.
+ your current comments on the draft from your adoption call review
(recent comments on the list should be referenced).
+ whether or not you are willing to review new versions of the draft during
development.



Oppose

I commented in January and some of my comments have been addressed, some have 
not.

The one I regard as most significant is that this uses two character prefix for 
the YANG modules.  Prefix must be unique across the entire IETF, everything 
from every WG, everything not from a WG, so while brevity is attractive, I see 
them as belonging with modules that will be widely used, widely known - 
interfaces comes to mind. I do not see this in this category,

I have yet to see a YANG doctor approve of a two-character prefix but I have 
seen opposition.



There is no problem to add longer prefixes. "tg:" -> "nttg:", "ta:" -> 
"ntta:" where "nt" stands for network test.


The intention with this draft is to provide "widely used, widely known" 
modules. The equivalent of ping and tcpdump functionality in YANG terms 
but also very deterministic and precise method for specification of test 
traffic for the dataplane. If the IETF and the authors manage to pull 
this off these modules will be the base modules augmented by vendors of 
network test equipment and very likely regular networking equipment will 
have implementation for verification and troubleshooting purposes.


There is reference code that implements RFC2544 as a simple python 
script using the model specified in the draft - 
https://github.com/vlvassilev/litenc/blob/master/tntapi/example/ietf-network-interconnect-tester/rfc2544.py 



and a reference device side implementation with open-source and 
open-hardware design  - 
https://www.hackster.io/lightside-instruments/network-programmability-kit-for-ultra96-07435c



significant part of this work was done at IETF Hackathon events.


/Vladimir




The author's response was to do it later n the process, that it would mean 
changing code.  Well the later in the process the more code there will be to 
change, more work, more mistakes from anyone involved..

There are other glitches in the  YANG module but I see this as the one to fix 
before considering any other.

Tom Petch


Send your comments to this list @b...@ietf.org

A URL for this Internet-Draft is [0]

Al
bmwg co-chair

[0] 
https://datatracker.ietf.org/doc/html/draft-vassilev-bmwg-network-interconnect-tester-06.txt



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

Re: [netmod] Murray Kucherawy's No Objection on draft-ietf-netmod-geo-location-08: (with COMMENT)

[Vladimir Vassilev]

Hi,

So here is the implementation ...

$ apt-get install yangcli

$ yangcli --server=lightside-instruments.com --ncport=10830 --user=user 
--password=ietf111 --display-mode=xml --run-command="xget /geo-location" 
--batch-mode


...


  
    http://example.com/ns/geo-location;>
  59.914566671000
  10.749260676000
    
  



The implementation 
https://github.com/vlvassilev/yuma123/tree/master/example-modules/geo-location



The target system is this 
https://www.hackster.io/lightside-instruments/network-programmability-kit-for-ultra96-07435c 
hosted at Bitraf - makerspace in Oslo.



/Vladimir


On 20/05/2021 11.33, Vladimir Vassilev wrote:


On 20/05/2021 10.43, Christian Hopps wrote:


Murray Kucherawy via Datatracker  writes:


I support Lars' and Francesca's DISCUSS positions.

The shepherd writeup says: "There are no known implementations known 
to the
Shepherd.  No vendors have indicated their plan to implement the 
specification.
 It was originally forwarded to support DT's Terra Stream project."  
I'm

tempted to ask why this is slotted for Standards Track publication.


It's a grouping, it's meant to be incorporated into other YANG 
modules rather than have each module come up with their own version 
of a geo-location object.


So, it's wont be "implemented" directly by any vendor until it is 
published and can start to be used in other module definitions. There 
definitely is interest in this use in the netmod WG.



Hi,

I intend to use the grouping in our implementation. We can do that at 
the upcoming Hackathon event and validate the module with some running 
code.


/Vladimir



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

Re: [netmod] Murray Kucherawy's No Objection on draft-ietf-netmod-geo-location-08: (with COMMENT)

[Vladimir Vassilev]

On 20/05/2021 10.43, Christian Hopps wrote:


Murray Kucherawy via Datatracker  writes:


I support Lars' and Francesca's DISCUSS positions.

The shepherd writeup says: "There are no known implementations known 
to the
Shepherd.  No vendors have indicated their plan to implement the 
specification.

 It was originally forwarded to support DT's Terra Stream project."  I'm
tempted to ask why this is slotted for Standards Track publication.


It's a grouping, it's meant to be incorporated into other YANG modules 
rather than have each module come up with their own version of a 
geo-location object.


So, it's wont be "implemented" directly by any vendor until it is 
published and can start to be used in other module definitions. There 
definitely is interest in this use in the netmod WG.



Hi,

I intend to use the grouping in our implementation. We can do that at 
the upcoming Hackathon event and validate the module with some running code.


/Vladimir

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

Re: [netmod] Compatibility of config=false data

[Vladimir Vassilev]

On 21/04/2021 17.10, Andy Bierman wrote:


IMO mandatory-stmt has no meaning for config=false.


This is not spelled out in the current version of YANG. Instead one can 
assume that using config=false, mandatory=false leafs is the correct way 
to model optional information fields. There is nothing formal in RFC7950 
that contradicts that. This interpretation seems to be one solution when 
the implementation has to handle different equipment instances where 
some support certain information fields and others do not. An 
alternative solution would require the overhead of defining an extra 
leaf for each optional leaf indicating if the information is present or 
not or adding an invalid value to the value space of the leaf 
representing the optional information.


That said I do not think this optional information fields modelling 
technique was the intention in the majority of published modules that do 
not specify mandatory-stmt in config=false nodes. It is just that 
RFC7950 has mandatory=false specified as default and this works better 
for config=true nodes then config=false nodes.


/Vladimir

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

Re: [netmod] warn: Module's revisions are not unique (2018-06-28).

[Vladimir Vassilev]

On 17/03/2021 19.21, Andy Bierman wrote:



On Wed, Mar 17, 2021 at 8:36 AM Vladimir Vassilev 
<mailto:vladi...@lightside-instruments.com>> wrote:



On 16/03/2021 13.36, Vladimir Vassilev wrote:
> Hei,
>
> Many drafts and RFCs are flagged with warnings by the tracker
> validation tools:
>
> ...
> yanglint SO 1.6.7: yanglint --verbose -p {tmplib} -p {rfclib} -p
> {draftlib} -p {ianalib} -p {cataloglib} {model} -i:
> warn: Module's revisions are not unique (2018-06-28).
>
> ...
>
> Does anyone know what causes this warning?

Seems the warning is issued when iana-if-t...@2020-01-10.yang is
processed. It contains 2 revision (history) statements with identical
dates 2018-06-28.

IMO Multiple revision statements with the same date are valid so the
tool reporting the warning has to be fixed.



I disagree.  Our compiler has a similar warning.

The YANG Library treats entries with the exact same module name and 
revision-date as
the same module.  The protocols that currently advertise YANG module 
capabilities
all use module name and revision-date to identify a unique module 
revision.


A compiler warning simply means "Are you sure you meant to do this?"
This is usually a cut-and-paste error.



If the tools could some how indicate that the warning is for an imported 
module and not the one validated it would be easier to differentiate 
between that case and the case the warning is caused by an imported 
standard module like iana-if-type.



Vladimir




Vladimir


Andy

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



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

Re: [netmod] warn: Module's revisions are not unique (2018-06-28).

[Vladimir Vassilev]

On 16/03/2021 13.36, Vladimir Vassilev wrote:

Hei,

Many drafts and RFCs are flagged with warnings by the tracker 
validation tools:


...
yanglint SO 1.6.7: yanglint --verbose -p {tmplib} -p {rfclib} -p 
{draftlib} -p {ianalib} -p {cataloglib} {model} -i:

warn: Module's revisions are not unique (2018-06-28).

...

Does anyone know what causes this warning?


Seems the warning is issued when iana-if-t...@2020-01-10.yang is 
processed. It contains 2 revision (history) statements with identical 
dates 2018-06-28.


IMO Multiple revision statements with the same date are valid so the 
tool reporting the warning has to be fixed.



Vladimir

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

[netmod] warn: Module's revisions are not unique (2018-06-28).

[Vladimir Vassilev]

Hei,

Many drafts and RFCs are flagged with warnings by the tracker validation 
tools:


...
yanglint SO 1.6.7: yanglint --verbose -p {tmplib} -p {rfclib} -p {draftlib} -p 
{ianalib} -p {cataloglib} {model} -i:
warn: Module's revisions are not unique (2018-06-28).

...

Does anyone know what causes this warning?

Vladimir

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

Re: [netmod] submodules the hidden benefits

[Vladimir Vassilev]

On 06/08/2020 00.43, Mahesh Jethanandani wrote:


A contrarian view:

I find the use of sub-modules helpful when I want to use separate 
files to maintain part of the module that is logically separate, while 
maintaining/restricting the use of them to a single namespace.


The fact that tools have a problem with trying to compile a sub-module 
can be addressed in the tools themselves.


The real problem is that the use of sub-modules complicates the 
interface between the tools. If your tools have to support dynamic 
loading of modules and not only a pre-compiled static schema context 
this problem becomes evident.


/Vladimir

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

Re: [netmod] submodules the hidden benefits

[Vladimir Vassilev]

On 05/08/2020 18.48, Juergen Schoenwaelder wrote:


I personally meanwhile believe that sub-modules add complexity with
little extra value but this view surely is not shared by others.


+1. IMO removing sub-modules from YANG 2.0 should be on the list of 
proposed changes.


/Vladimir

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

Re: [netmod] rfc6991bis: yang:xpath1.0

[Vladimir Vassilev]

On 17/07/2020 21.14, Juergen Schoenwaelder wrote:


- How do we deal with xpath expressions in other encodings
such as JSON. Do we assume an xpath context populated with
module names such that module names can be used to qualify
path expressions. This may need discussion and/or a new
definition.

- This interacts with the definition of node-instance-identifier.

- Options: (i) Leave this definition as it is. (ii) Detail how this
type work with encodings that use module names instead of prefixes
to qualify names.

- Proposal: ?



How about leaving the xpath1.0 type definition as it is and specifying a 
canonical form for the node-instance-identifier where namespace prefixes 
must be module names.




/js



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

Re: [netmod] JSON to XML lossy conversion

[Vladimir Vassilev]

On 17/07/2020 09.11, Ladislav Lhotka wrote:



On 17. 07. 20 8:57, Michal Vaško wrote:

Hi Carsten,
you had an interesting idea to have tools that could warn about these problems 
(although that is hardly a proper solution) but it is not really possible 
because the problem may occur whenever there is union with a 'string' and 
'int8' - 'int32', 'uint8' - 'uint32', or 'boolean', in any order. Meaning in 
lots of, if not most, unions. And I have considered only XML and JSON, I have 
not looked into CBOR, which may make it even worse.

What you can do is to define a metadata annotation specifying the union
member for a particular instance, and implement it in your tools. This
would be a solution independent of instance representation.



IMO this does not solve the problem that XML can not encode all values 
of the value space in certain awkward unions (JSON and CBOR can't do 
that either only the constraints are alternative supersets).


If the XML representation rules in the YANG definition were provided as 
an inherent constraint to the value space of the union type there was 
not going to be ambiguity and there would have been a bug in any 
encoding that does not enforce this exact constraint. This is not 
spelled out in RFC7950 but is a good rule of thumb to avoid unions that 
have value space that can not be represented in XML.


The alternative is to rework the XML representation to not have such 
limitation in a next version of YANG (e.g. adding XML attributes with 
the active member type index and name).


That said I think there is one underestimated feature of the union type 
being entirely mapped to a string also for integer types as it is in the 
current XML encoding definition. Without requirement for resolving which 
member type the data actually is representing but just validating there 
is at least one match allows implementations to encode the data without 
resolving a possibly complex logical relationship. For example a union 
of interface index and leafref to interface name (for whatever reason 
someone would design such a union). You really do not need to know if 
there is an interface named "2" in the candidate configuration when you 
send  in XML. With JSON you have to resolve this.


/Vladimir




Lada


Regards,
Michal
  

In my view, if it is a bug, it is in the design of the union type in YANG - 
there is no general way to signal the actual union member type for an instance.

Right.  The ambiguity is normally not a problem for a type choice (which is 
just a union of the possible values of all types given), unless what specific 
alternative was chosen is intended to carry semantics.


I believe it is a good thing that some encodings allow for at least partial 
signalling.

Note that similar issues may arise even more often in CBOR, see e.g. comments 
for section 5.12 in

https://mailarchive.ietf.org/arch/msg/core/Zrb2yhSSdlouS6PI9qfsA1bsDB4/

In the original YANG (XML-only), everything was represented as a text string, 
so the ambiguity was the highest we see now.  YANG-JSON and YANG-CBOR provide 
progressively more disambiguating information, so the interpretation (which 
chosen alternative) may be different from the one after converting to YANG-XML.

It gets slightly worse if the non-text type has a conversion to text that is 
not fully nailed down; I don’t know if that is a problem with the current set 
of YANG types, but any new type could of course worsen the situation.

The onus is now on the author of the YANG module to make sure that the varying 
levels of ambiguity do not cause a problem.  I would be interested to know 
whether there is any tool support for this.

Grüße, Carsten

  
  



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

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

[Vladimir Vassilev]

Hi,


This version (-03) of the draft has not updated the 
ietf-yang-ty...@2019-11-04.yang module name while the revision is 
updated to 2020-06-26 (same goes for ietf-inet-types). This causes the 
ietf.org validation to fail for all active drafts that directly or 
indirectly import ietf-yang-types.


The validation tools do not catch that problem for 
draft-ietf-netmod-rfc6991-bis-03 itself. Only when it is imported. And 
looking into the output of the validation script:

...

draft-ietf-netmod-rfc6991-bis-03.txt:
...
 # read ietf-yang-ty...@2020-06-26.yang (CL)
...

Seems like the validation script is too smart and corrects the file name 
replacing 2019-11-04 with 2020-06-26 when extracting the modules from the RFC 
without error or warning message.

/Vladimir

On 26/06/2020 17.01, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

This draft is a work item of the Network Modeling WG of the IETF.

Title : Common YANG Data Types
Author : Juergen Schoenwaelder
Filename : draft-ietf-netmod-rfc6991-bis-03.txt
Pages : 48
Date : 2020-06-26

Abstract:
This document introduces a collection of common data types to be used
with the YANG data modeling language. This document obsoletes RFC
6991.


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



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

Re: [netmod] hex-string as built-in type in future versions of YANG

[Vladimir Vassilev]

On 06/11/2019 15.10, Schönwälder, Jürgen wrote:
> On Wed, Nov 06, 2019 at 01:29:41PM +0000, Vladimir Vassilev wrote:
>> [2] Some of the types are based on strings with complex lexical
>> representation with canonical form specified in description statement
>> which is neither scalable nor automation friendly. For example the
>> "ethertype-type" type (just getting started):
>>
>> ... from ieee802-dot1q-ty...@2018-03-07.yang
>>
>>     typedef ethertype-type {
>>       type string {
>>     pattern "[0-9a-fA-F]{2}-[0-9a-fA-F]{2}";
>>       }
>>       description
>>     "The EtherType value represented in the canonical order defined
>>     by IEEE 802. The canonical representation uses uppercase
>>     characters.";
>>       reference
>>     "9.2 of IEEE Std 802-2014";
>>     }
>> ...
>>
>> IMO typedefs (not types) with constrains specified in a description
>> statement especially if they are not part of ietf-yang-types (RFC6991)
>> should be avoided. Those types are bad enough even when they are defined
>> in ietf-yang-types e.g. "mac-address" AA:BB:CC:DD:EE:FF which is valid
>> for rpc "input" data has to be treated as aa:bb:cc:dd:ee:ff (which is
>> the canonical representation). The difference comes from the fact that
>> "mac-address" is seamlessly converted to lowercase in many tools (not
>> all). Those tools do not support the types defined in
>> ieee802-dot1q-types in the same way. So there is no "to uppercase"
>> seamless conversion for ethertype-type and "aB-cD" and "AA-CD" are
>> treated as different values and you will have to figure out how your
>> implementation can fix this on your own.
>   typedef mac-address {
> type string {
>   pattern '[0-9a-fA-F]{2}(:[0-9a-fA-F]{2}){5}';
> }
> description
>  "The mac-address type represents an IEEE 802 MAC address.
>   The canonical representation uses lowercase characters.
>
>   In the value set and its semantics, this type is equivalent
>   to the MacAddress textual convention of the SMIv2.";
> reference
>  "IEEE 802: IEEE Standard for Local and Metropolitan Area
> Networks: Overview and Architecture
>   RFC 2579: Textual Conventions for SMIv2";
>   }
>
> The problem here is that two organizations have rather different
> preferences when it comes to uppercase and lowercase letters.
>   
>> IMO ietf-yang-types:mac-address (and many others
>> ieee802-dot1q-types:ethertype-type included) can be derived from
>> ietf-yang-types:hex-string instead of string. It would be even better if
>> "hex-string" is defined as a new built-in type in YANG next with an
>> optional "width" sub-statement constraining the number of bits represented.
>>
>> There are relevant discussions in
>> https://github.com/netmod-wg/yang-next/issues/19  and
>> https://github.com/netmod-wg/yang-next/issues/46 (posted the last
>> paragraph of this proposal there).
> Creating a hex-string built-in type in order to settle the debate
> lowercase vs. uppercase? Note sure this is a strong technical reason
> for creating a new built-in type. ;-)


There is no technical reason at all to have MAC addresses represented as 
pattern constrained strings and not "binary" of length 6 (as it was in 
SMIv2 MIBs) either. There is no technical reason for ethertype to be 
represented as pattern constrained string and not "binary" of length 2 
or "uint16". It is likely done because of the sane lexical 
representation requirement derived from NETCONF design requirement to be 
human readable on the wire and this is not the case when the data is 
base64 encoded or in the better case represented as decimal when humans 
are used to its hex-string representation.

This is what this proposed type offers - readable and writable 
representation (more readable and writable by humans then the base64 
representation of binary).

That said defining new uint* and binary built-in sub-statement 
{lexical-representation hex-string;} enabling alternative lexical 
representation might be the right solution:

typedef mac-address {
   type binary {
 length 6;
 lexical-representation hex-string;
   }
}

typedef ether-type {
   type uint16 {
 lexical-representation hex-string;
   }
}

/Vladimir


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

[netmod] hex-string as built-in type in future versions of YANG

[Vladimir Vassilev]

Moving a netmod relevant topic from a thread on the bmwg mailing list 
https://mailarchive.ietf.org/arch/msg/bmwg/GwkVykKmOX7DFokCFynJVy_ZwZ8

On 29/10/2019 13.32, tom petch wrote:
> Picking up the point below about vlan, this is where the IETF is not
> doing the job it might.  'vlan' appears in many YANG modules with
> several flavours thereof; yes, we might get a better resolution on the
> netmod list but really, apart from our IEEE liaison, I do not know where
> to go for the best advice on this.  I saw this issue surface recently on
> I2RS which, thinking about it, makes sense and there, the outcome was
>   import ieee802-dot1q-types {...  reference
>  "IEEE Std 802.1Qcp-2018: Bridges and Bridged
>   Networks - Amendment: YANG Data Model.";
> i.e. anything vlan we import from the IEEE module.  I did query making
> an IETF module normatively dependent on an IEEE module and the ADs said
> that that was fine so that is the direction in which I think that the
> IETF should go.

I can think of at least 2 issues with importing ieee802-dot1q-types.yang 
in IETF modules. 1. the unclear license under which third party 
organizations can distribute it. 2. Its design

[1] The IETF has liaison with IEEE but the IETF modules are distributed 
under Simplified BSD License while the IEEE ones are not.  It is not 
clear to me what is the effective IEEE license for third party 
organizations that need to distribute the IEEE modules together with the 
importing IETF ones. If the cost of the 5 simple ethernet frame field 
types - ethertype, vlanid, tpid, pcp, cfi is embedding dependency on the 
conservative IEEE licensing policies I think the cost is too high.

[2] Some of the types are based on strings with complex lexical 
representation with canonical form specified in description statement 
which is neither scalable nor automation friendly. For example the 
"ethertype-type" type (just getting started):

... from ieee802-dot1q-ty...@2018-03-07.yang

   typedef ethertype-type {
     type string {
   pattern "[0-9a-fA-F]{2}-[0-9a-fA-F]{2}";
     }
     description
   "The EtherType value represented in the canonical order defined
   by IEEE 802. The canonical representation uses uppercase
   characters.";
     reference
   "9.2 of IEEE Std 802-2014";
   }
...

IMO typedefs (not types) with constrains specified in a description 
statement especially if they are not part of ietf-yang-types (RFC6991) 
should be avoided. Those types are bad enough even when they are defined 
in ietf-yang-types e.g. "mac-address" AA:BB:CC:DD:EE:FF which is valid 
for rpc "input" data has to be treated as aa:bb:cc:dd:ee:ff (which is 
the canonical representation). The difference comes from the fact that 
"mac-address" is seamlessly converted to lowercase in many tools (not 
all). Those tools do not support the types defined in 
ieee802-dot1q-types in the same way. So there is no "to uppercase" 
seamless conversion for ethertype-type and "aB-cD" and "AA-CD" are 
treated as different values and you will have to figure out how your 
implementation can fix this on your own.

IMO ietf-yang-types:mac-address (and many others 
ieee802-dot1q-types:ethertype-type included) can be derived from 
ietf-yang-types:hex-string instead of string. It would be even better if 
"hex-string" is defined as a new built-in type in YANG next with an 
optional "width" sub-statement constraining the number of bits represented.

There are relevant discussions in 
https://github.com/netmod-wg/yang-next/issues/19  and 
https://github.com/netmod-wg/yang-next/issues/46 (posted the last 
paragraph of this proposal there).

/Vladimir

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

Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

[Vladimir Vassilev]

On 22/08/2019 12.13, Rob Wilton (rwilton) wrote:


Hi Vladimir,

Thanks for your detailed review.  Sorry for the slow reply, I've been away.  
I'm also about to be away again for a couple of days.

Please see my comments inline ...

I'll also track these issues to closure on 
https://github.com/netmod-wg/interface-extensions-yang/issues


-Original Message-
From: netmod  On Behalf Of Vladimir Vassilev
Sent: 13 August 2019 17:05
To: Kent Watsen ; netmod@ietf.org
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

I have reviewed the draft. I have the following (19) IMO useful proposals:

1. Dedicated module (ietf-if-oper-status-debounce.yang) for the oper-
status debouncing/dampening functionality currently in ietf-interfaces-
common.yang.

I don't think that we want a proliferation of too many separate YANG modules 
for small features.  Each of the areas of different functionality within this 
module are already conditional on if-feature, so I don't think that there is a 
strong justification to separating this out as a separate module.


I still think that especially the "dampening" mechanism is not common 
enough and is quite complex to be added to ietf-interfaces-common. If a 
feature is not common or does not enable the use of generic modeling 
mechanism (like sub-interfaces etc.) it should not be in 
ietf-interfaces-common. I do not think "dampening" (maybe at some point 
we should go back to damping instead e.g. rfc2439 ... seems there is 
difference between dampening and damping and damping seems to be the 
correct one) is that common to deserve a place in ietf-interfaces-common.





2. In sec "3.1 Carrier delay" use of the under-defined "Carrier"
definition can be replaced with direct reference to the oper-status leaf
(which is what is actually targeted by the algorithm) "Operational status
transition debouncing".

I think that different vendors have different names for this technology.  I've 
just used the one that our products use.  I think that this is just a name, 
rather than something that has to be defined.  I could add a comment that this 
feature is sometimes called hold time?


I looked for precedents -  "carrier-delay" leaf Cisco, 
"debouncing-interval" leaf Juniper, "interface-phys-holdtime-config" 
leaf OpenConfig.


I think "Carrier" is confusing since what is delayed actually is the 
transition of the oper-status.



3. "timer-running" and "suppressed" leafs are both "config false" and have
"default" statements. Although this is valid YANG I do not think the
"default" statements are intended.

I think that this is a more general question that needs a bit more discussion.  
Here, I am using defaults for the config false node to document what the normal 
value is expected.

Well not a real issue but I thought it was an unusual use of default.




4. Dedicated module (ietf-if-loopback.yang) for the loopback functionality
currently in ietf-interfaces-common.yang.

Same answer as for 1. I don't think that we should have too many really small 
modules.
If the loopback was modeled as a boolean leaf (as in OpenConfig) I would 
have agreed. However even small modules that define base identities 
benefit from dedicated namespace. For me ietf-if-loopback.yang will pay 
off since loopback='internal' is better then 
loopback='loopback-internal' and there are going to be many test cases 
that use that line. An last but not least I never had problems with too 
much modularity.



5. Less verbose loopback identities. With dedicated module the
(loopback-* identities can be shortened skipping the prefix).

I think that it is normal to bind the identity names to the common base 
identity.  I don't see that the length of the identities should really be an 
issue.
For me the length of identities does matter since I often use command 
line tools. But it is mostly the irritation caused by the tautology 
loopback='loopback-internal' that everyone writing network interconnect 
testcases is going to be stuck with forever if we leave the loopback 
control model as part of ietf-interfaces-common and not separate 
ietf-if-loopback. What do others think?



6. The draft introduces "loopback-internal", "loopback-line" and
"loopback-connector" loopback identities. What is confusing is that
"internal loopback" is historically the opposite of "external loopback"
which is a loopback with a connector. I think terminology already in use
like "near-end" and "far-end" is less confusing.

The internal/line loopback configuration has been used in parts of the industry 
for at least 20 years, so this terminology is already in use.

I'm not sure that "near-end" and "far-end" would be less confusing.  Assuming that "loopback 
far-end" was equivalent to "lo

Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

[Vladimir Vassilev]

I have reviewed the draft. I have the following (19) IMO useful proposals:

1. Dedicated module (ietf-if-oper-status-debounce.yang) for the 
oper-status debouncing/dampening functionality currently in 
ietf-interfaces-common.yang.


2. In sec "3.1 Carrier delay" use of the under-defined "Carrier" 
definition can be replaced with direct reference to the oper-status leaf 
(which is what is actually targeted by the algorithm) "Operational 
status transition debouncing".


3. "timer-running" and "suppressed" leafs are both "config false" and 
have "default" statements. Although this is valid YANG I do not think 
the "default" statements are intended.


4. Dedicated module (ietf-if-loopback.yang) for the loopback 
functionality currently in ietf-interfaces-common.yang.


5. Less verbose loopback identities. With dedicated module the 
(loopback-* identities can be shortened skipping the prefix).


6. The draft introduces "loopback-internal", "loopback-line" and 
"loopback-connector" loopback identities. What is confusing is that 
"internal loopback" is historically the opposite of "external loopback" 
which is a loopback with a connector. I think terminology already in use 
like "near-end" and "far-end" is less confusing.


7. I am not sure standardizing the "loopback-connector" identity is 
justified. All usecases of connecting a loopback connector I can think 
of require the system to not be aware there is special external loopback 
connector on the interface.


8. Some interfaces that implement "loopback-internal" do not implement 
"loopback-line" - e.g. classical ethernetCsmacd (Carrier-sense multiple 
access with collision detection) has a physical layer that by design can 
not implement such loopback. Maybe introducing a dedicated feature to 
enable the "loopback-line" is a good idea.


9. Appropriate entry in the "11. Security Considerations" noting the 
possibility of DoS attacks and broadcast traffic storms resulting from 
loopbacks:


OLD:

   The following leaf could cause the interface to go down, and stop
   processing any ingress or egress traffic on the interface:

   o  /if:interfaces/if:interface/loopback

NEW:

   The following leaf could cause the interface to go down, and stop
   processing any ingress or egress traffic on the interface. It could
   cause broadcast traffic storms.

   o  /if:interfaces/if:interface/loopback


10. Introducing config true "forwarding-mode" leaf breaks clients that 
support e.g. rfc8344 ietf-ip (which has its dedicated forwarding leafs 
e.g. /ietf-interfaces:interfaces/interface/ietf-ip:ipv4/forwarding ) by 
introducing this new module with a new leaf they know nothing about. I 
support this leaf as config false. If NETCONF was not transactional a 
global leaf enabling the forwarding configuration would be a feature. 
But NETCONF is transactional.


11. The "forwarding-mode" leaf has the following set of identities 
{optical-layer, l2-forwarding, network-layer}. We could make the 
identity names shorter and consistent. l1,l2,l3 or 
physical,data-link,network.


12. I do not agree we need this text. Normally NETCONF devices should 
accept transactions to any valid configuration:


OLD:
   ...
   Normally devices will not allow the parent-interface leaf to be
   changed after the interfce has been created.  If an implementation
   did allow the parent-interface leaf to be changed then it could cause
   all traffic on the affected interface to be dropped.  The affected
   leaf is:

   o  /if:interfaces/if:interface/parent-interface
   ...

NEW:
   ...
   Changing the parent-interface leaf could cause
   all traffic on the affected interface to be dropped.
   The affected leaf is:

   o  /if:interfaces/if:interface/parent-interface
   ...

13. The in-drop-unknown-dest-mac-pkts changes the behavior of the 
in-unicast-pkts,in-multicast-pkts and in-broadcast-pkts. I do not agree 
any discarded packets in the forwarding process should be subtracted 
from the interface counters.


Here is the current description:

OLD:
    For consistency, frames counted against this drop
    counters are also counted against the IETF interfaces
    statistics.  In particular, they are included in
    in-octets and in-discards, but are not included in
    in-unicast-pkts, in-multicast-pkts or in-broadcast-pkts,
    because they are not delivered to a higher layer.
NEW:
    The implementation of this counter does not
    change the behavior of the counters defined in
    IETF interfaces statistics.



14. I propose the in-pkts and out-pkts counters standardized too. 
https://github.com/YangModels/yang/blob/master/vendor/cisco/xe/1641/ietf-interfaces-ext.yang. 
And yes someone forgot to update the boilerplate text.


15. I propose that new "ietf-interfaces-common:in-discards-overflow" 
counter is added. Currently the "ietf-interfaces:in-discards" can 
contain both discards like the 

Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

[Vladimir Vassilev]

On 11/08/2019 13.50, Rob Wilton (rwilton) wrote:


Hi Vladimir,

Thanks for the comments.

Regarding increasing the L2 MTU if 802.1Q tags are present, this is because of 
how IEEE 802.3 defines the MTU of an Ethernet interface (at least for a single 
802.1Q tag).
Where does IEEE 802.3 define "MTU of an Ethernet interface" (me being 
positive IEEE 802.3 or 802.1Q do not use MTU definition at all)?


If you have a mix of single and double tagged sub-intefaces, it also means that 
the IP MTU for all of those sub-interfaces can be the same.

E.g. if you set the L2 MTU of a physical interface to 1514 (excluding FCS 
bytes) then the IP MTU for each of the sub-interfaces would be 1500 bytes 
regardless of whether they are configured to match single or double VLAN tags.

Conversely, if you have a strict L2 MTU that doesn't have this flexibility then 
a single tagged sub-interface would end up with an IP MTU of 1496, and a double 
tagged sub-interface would end up with an IP MTU of 1492, complicating L3 
configuration.


The problem can become very complicated  if we introduce new definition 
of MTU (I still do not agree L2 MTU is a thing).


Why the ifMtu object from IF-MIB is not mapped to config false 
/ietf-interfaces:interfaces/interface/ietf-interfaces-common:mtu in 
ietf-intefaces-common.yang and instead we need something else?


From RFC 2863:

 ifMtu OBJECT-TYPE
SYNTAX  Integer32
MAX-ACCESS  read-only
STATUS  current
DESCRIPTION
"The size of the largest packet which can be sent/received
on the interface, specified in octets.  For interfaces that
are used for transmitting network datagrams, this is the
size of the largest network datagram that can be sent on the
interface."
::= { ifEntry 4 }
IMO this sounds as useful today as it did before.

From RFC 8343 "4.  Relationship to the IF-MIB":

   The ifMtu object from the IF-MIB is not mapped to the
   "ietf-interfaces" module.  It is expected that interface-type-
   specific YANG modules provide interface-type-specific MTU leafs by
   augmenting the "ietf-interfaces" model.

I am aware of that text too but I do not agree mapping ifMtu which is 
interface type independent to /interfaces/interface/mtu is not necessay 
and can be replaced by introducing "interface-type-specific MTU leafs".


Vladimir



BTW, I'll be on PTO for a week, so please expect a delay in response.

Thanks,
Rob



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

Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

[Vladimir Vassilev]

On 07/08/2019 16.14, Rob Wilton (rwilton) wrote:

Hi Acee,

Thanks.  This was also discussed in the NETMOD WG meeting (I know that you had 
a conflict).

My reading of the consensus in the room was that the histogram statistics 
should be deferred at this time.  In particular, it seems like it would take 
some time/effort to agree on exactly how these counters should be modelled.  I 
also said that I would contact the IEEE 802.3 WG chair to see if we could 
progress a histogram model within the IETF.  I have sent an email out, but not 
heard anything back yet.

There was consensus in the room to add a sub-interface demux drop counter into 
the current module.

Lou also proposed that I rename "l2-mtu" to something like "max-frame-size" for 
consistency (I need to check the recording).
I think avoiding the MTU confusion was the correct decision. The MTU 
definition from RFC791 is consistently used in all RFCs known to me.


In addition to renaming the leaf there is contradiction between the 
description and range statements in draft-ietf-netmod-intf-ext-yang-07:




...

 leaf l2-mtu {
   if-feature "configurable-l2-mtu";
   type uint16 {
 range "64 .. 65535";
   }
   description
 "The maximum size of layer 2 frames that may be transmitted
  or received on the interface (excluding any FCS overhead).
  In the case of Ethernet interfaces it also excludes the
  4-8 byte overhead of any known (i.e. explicitly matched by
  a child sub-interface) 802.1Q VLAN tags.";
   reference "RFC XXX, Section 3.5 Layer 2 MTU";
 }

...



Obviously minimum Ethernet frame is 64 bytes when FCS bytes are 
included. I also do not think there is consensus that 4-8 bytes should 
be subtracted if there are sub-interfaces with VLAN encapsulation 
configured since this complicates the logic.


IMO There have been too few reviews of this work. I will go through the 
draft and the relevant mailing list threads during the weekend and post 
my review.


/Vladimir


It also looks like I should generate and add -state trees to the appendix.

Thanks,
Rob


-Original Message-
From: Acee Lindem (acee)
Sent: 05 August 2019 18:52
To: Rob Wilton (rwilton) ; Kent Watsen 
; netmod@ietf.org
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

Hi Rob,
It seems these counters have been considered at great length. I agree we should 
move forward with the model as it is today.
Thanks,
Acee

On 7/17/19, 11:36 AM, "Rob Wilton (rwilton)"  wrote:

 Hi Acee,
 
 Thanks for the review, and apologies for the delayed reply.
 
 Regarding your stats question, there was some effort to handle this as part of defining the Ethernet interface YANG (IEEE 802.3.2-2019) (https://github.com/YangModels/yang/tree/master/standard/ieee/published/802.3) that I was involved in the earlier parts of.  Please see the attached XLS that was my earlier effort to rationalize the different ethernet interfaces counters between RFC 7223, Ethernet YANG, Etherlike MIB, RMON MIBs, and the counters exposed in the 802.3 clause 30 management API.
 
 For physical Ethernet interfaces (and anything that looks very similar to a physical Ethernet interface) then I think that we should be well covered by the combination of what is in ietf-interfaces, and IEEE 802.3.2.
 
 There are also some counters that apply to all Ethernet-like interfaces (really anything using Ethernet framing, but not an Ethernet physical layer).  The only counter currently defined in this category is in-drop-unknown-dest-mac-pkts in ietf-interfaces-ethernet-like.  Arguably we could also add a drop counter for frames that could not be demuxed to a sub-interface because it didn't match any of the sub-interface match expressions.
 
 There was one set of counters that 802.3.2 didn't want to include in their YANG module which related to the histogram frame statistics.  E.g. counters like the following (taken from IOS XR):
 
 Input pkts 65-127 bytes = 0

 Input pkts 128-255 bytes= 0
 Input pkts 256-511 bytes= 0
 Input pkts 512-1023 bytes   = 0
 Input pkts 1024-1518 bytes  = 0
 Input pkts 1519-Max bytes   = 0
 
 Output pkts 65-127 bytes= 0

 Output pkts 128-255 bytes   = 0
 Output pkts 256-511 bytes   = 0
 Output pkts 512-1023 bytes  = 0
 Output pkts 1024-1518 bytes = 0
 Output pkts 1519-Max bytes  = 0
 
 The 802.3 YANG WG had two issues with including counters like these:

 (1) They didn't really want to define histogram counter values for MTUs 
that are above the officially sanctioned MTU of 1514/1518 in the Ethernet 
specification, even though a lot of hardware supports up to 9K+.
 (2) The bucket ranges, at least once you get past the "512-1023" bucket, 
seem to somewhat vary by ASIC vendor.
 (3) IEEE 802.3 has a well defined internal management 

Re: [netmod] Question regarding RFC 8344

[Vladimir Vassilev]

On 7/11/19 7:04 PM, Peter Schneider wrote:

Hi,

I stumbled on an incompatibility between the IP Management YANG Module 
and the real world:
In the 'container ipv4', the leaf 'mtu' is declared as uint16 in the 
range 68..max, which is effective the range 68..65535, as noted in rfc 
7950  .
On the other side, the default MTU size of the loopback interface in 
Linux is 65536 since several years.


I don't think there is a problem with RFC 8344 since the ipv4 protocol 
MTU can not exceed 65535 bytes (RFC 791). The maximum payload supported 
by an interface which is the case with the default value of the lo 
interface MTU on your Linux distribution (seems this can be configured 
to up to 2147483647 octets at least on mine) has to be greater then the 
MTUs of all protocols (ipv4,ipv6 etc.) supported on that interface but 
they do not need to be equal. It is indeed recommended that the maximum 
"length of the data field of a packet" is used as defined in RFC 894 
e.g. 1500 for ethernet but you can choose or be constrained (like in 
this case) to not do so.


Currently there is no IETF RFC module that has data definition for 
control of the interface MTU used as an upper limit for all protocol MTUs.


FYI there is a /interfaces/interface/l2-mtu leaf proposed in 
draft-ietf-netmod-intf-ext-yang-07 where an uint16 type should probably 
be changed to uint32.


IMO  "/interfaces/interface/mtu" leaf is needed that actually 
corresponds to the maximum length of the data field of a packet and 
already referred to in popular software like Linux as "interface MTU" 
(there is no standard this is based on just running software as far as I 
am aware) should be added in addition to the l2-mtu leaf. Then in your 
case this leaf would be configured to 65536 for the lo interface while 
the /interfaces/interface/ipv4/mtu can be less then that.


/ Vladimir

Depending on the used netconf client, the client either reports 
(correctly) an error when getting / configuring the loopback 
interface, or silently reduces /raises the shown resp. configured 
value for the mtu.


Are there any statements available on this issue?

Kind Regards,

Peter Schneider
--
Email Signature of href="mailto:peter.schnei...@kontron.com;>peter.schnei...@kontron.com 
*Peter Schneider*

Software Engineer R
*Kontron*
Heinrich-Barth-Strasse 1-1a | 66115 Saarbrücken | Germany
P: +49 681 95916 206
_peter.schneider@kontron.com_ 

Website  | Blog  | 
Twitter  | LinkedIn 
 | YouTube 
 | Facebook 



*Kontron Europe GmbH*
Die gesetzlichen Pflichtangaben finden Sie hier 
.
Please find our mandatory legal statements hier 
.
Mit dem Öffnen dieses E-Mails stimmen Sie Kontrons Richtlinien zur 
elektronischen Kommunikation 
 zu.
By opening this email you are agreeing to Kontron's Electronic 
Communications Policy 



___
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] xpath expressions in JSON

[Vladimir Vassilev]

Hi,

Seems this discussion affects 10 draft modules using the xpath1.0 type. 
The proposed boilerplate description text that was not added to some RFC 
modules like ietf-netconf-monitor...@2010-10-04.yang


should be as consistent as possible (or skipped based on the 
ietf-netconf-monitoring precedent) until a better alternative is 
available. Here is an example of a better alternative.


   typedef ypath1.0 {
    type xpath1.0;
    description
 "This type represents subset of XPATH 1.0 expressions
  that apply to a data tree conforming to a YANG model.

  Each encoding should allow conversion to an encoding
  independent lexical representation where data node
  prefixes are resolved to and substituted with module
  names.

  When a schema node is defined that uses this type, the
  description of the schema node MUST specify the
  context in which the expression is evaluated if it
  is different from the default context.

  The default context is as follows:

    o  The set of variable bindings is empty.

    o  The function library is the core function library, and
   the XPath functions defined in section 10 in RFC 7950.

    o  The context node is the leaf node.

  ";
    reference
 "XPATH: XML Path Language (XPath) Version 1.0";
  }

That said I do not object to short-term application of alternative A as 
long as a long-term solution is on its way for future modules.


Vladimir

On 10/18/18 12:30 PM, Martin Bjorklund wrote:

Hi,

Going back to the most urgent issue, what is this WG's recommendation
for the subscribed-notifications draft in NETCONF wrt/ their usage of
yang:xpath1.0 in filters?

To summarize:

We already have

   o  instance-identifier in XML uses prefixes from the XML document
   o  instance-identifier in JSON uses module names as prefixes
   o  XPath in NETCONF filter uses prefixes from the XML document
   o  XPath in JSON query filter uses module names as prefixes


Alternative A:
--

Use different encodings for "stream-xpath-filter" as well, depending
on if it is XML or JSON.

We would do in SN:

 o  If the node is encoded in XML, the set of namespace
declarations are those in scope on the
'stream-xpath-filter' leaf element.

 o  If the node is encoded in JSON, the set of namespace
declarations is the set of prefix and namespace pairs
for all supported YANG modules, where the prefix is
the YANG module name and the namespace is as defined
by the "namespace" statement in the YANG module.

Pro: the format is consistent within each encoding.

Con: unclear how to handle other encodings.
Con: we keep using context-depending encodings.

We could probably add that CBOR uses the same representation as JSON.

Example in XML:

   
 /if:interfaces/if:interface/ip:ipv4
   

Example in JSON:

   "stream-xpath-filter":
 "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"



Alternative B:
--

Use a non-context depending encoding, with the module name as prefix.

We would do in SN:

 o  The set of namespace
declarations is the set of prefix and namespace pairs
for all supported YANG modules, where the prefix is
the YANG module name and the namespace is as defined
by the "namespace" statement in the YANG module.

Pro: the format is independent from the protocol encoding

Con: in XML, this leaf is treated differently from other XPath
  expressions, such as get-config filter and nacm rules.

Example in XML:

   
 /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4
   

Example in JSON:

   "stream-xpath-filter":
 "/ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip:ipv4"


My proposal is A.  I think it is more important with consistency
within each encoding than across encodings.

(This said, I would like to have a context-independent encoding of all
YANG types in the future.  But not now.)




/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] Review comments for module-tags-02

[Vladimir Vassilev]

Hi,

Adding  -state modules to all new drafts seems like unnecessary 
overhead. Even mentioning NMDA in a draft that has no logical 
relationship to NMDA also seems like unnecessary overhead.


Not a great set of alternatives. The positive thing is that vendors that 
do not have to worry about existing applications should really have no 
problem responding to the pressure.


Vladimir

On 10/17/18 4:39 PM, Christian Hopps wrote:

I'll chime in as an operator here, I do not feel there is a need to support 
non-NMDA implementations with this brand new work that won't be finished let 
alone start being used for another so many months (at best). There's nothing 
wrong with simply requiring NMDA for various modules going forward. Indeed I'd 
like more modules to require NMDA if only to add pressure to get it deployed by 
vendors.

Thanks,
Chris.


On Oct 17, 2018, at 10:23 AM, Juergen Schoenwaelder 
 wrote:

The WG needs to agree whether a -state module in the Appendix is
needed. I just commented on the proposal to add a subtree, which
violates the guidelines.

/js

On Wed, Oct 17, 2018 at 01:13:06PM +, Rohit R Ranade wrote:

Either defining a new module in an Appendix or a subtree, I am OK with either 
and both of us concur that the draft needs the changes.

-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
Sent: 17 October 2018 18:18
To: Rohit R Ranade 
Cc: Christian Hopps ; netmod@ietf.org
Subject: Re: [netmod] Review comments for module-tags-02

Obviously, this is now a slightly different statement. There are NMDA 
transition guidelines that have been discussed at length and finally been 
integated into

https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20#section-4.23.3

This section 4.23.3 says under case (a):

   Both the NMDA and the non-NMDA modules SHOULD
   be published in the same document, with NMDA modules in the document
   main body and the non-NMDA modules in a non-normative appendix.

In other words, you do not pollute a new NMDA module with non-NMDA subtrees but 
instead you create an additional module that goes into an appendix and is only 
relevant for transition purposes. I think Rob created tools to generate such 
things. Section 4.23.3.1 also provides some guidelines for creating temporary 
non NMDA modules.

/js

On Wed, Oct 17, 2018 at 12:22:39PM +, Rohit R Ranade wrote:

If the server does not yet support NETCONF-NMDA / RESTCONF-NMDA drafts, then we 
will need this separate subtree to show the system defined tags.

-Original Message-
From: Juergen Schoenwaelder
[mailto:j.schoenwael...@jacobs-university.de]
Sent: 17 October 2018 17:22
To: Rohit R Ranade 
Cc: Christian Hopps ; netmod@ietf.org
Subject: Re: [netmod] Review comments for module-tags-02

On Wed, Oct 17, 2018 at 11:46:03AM +, Rohit R Ranade wrote:


I think we need to define a subtree for non-NMDA clients to get the
operational tags.

It is not much of a change for a _client_ to read a different datastore hence I 
do not think this is needed.

/js

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

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

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


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


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

Re: [netmod] xpath expressions in JSON

[Vladimir Vassilev]

On 10/15/18 4:25 PM, Ladislav Lhotka wrote:


Martin Bjorklund  writes:


Ladislav Lhotka  wrote:

On Wed, 2018-10-10 at 19:23 -0700, Andy Bierman wrote:


On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) 
wrote:

On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
netmod-boun...@ietf.org on behalf of m...@tail-f.com> wrote:

 Ladislav Lhotka  wrote:
 > Martin Bjorklund  writes:
 >
 > > Hi,
 > >
 > > While reviewing restconf-notif, I saw this example:
 > >
 > >{
 > >   "ietf-subscribed-notifications:input": {
 > >  "stream": "NETCONF",
 > >  "stream-xpath-filter": "/ds:foo/",
 > >  "dscp": "10"
 > >   }
 > >}
 > >
 > > Note the "stream-xpath-filter".  It has a prefix in the XPath
string.
 > > How are prefixes declared when JSON is used?
 > >
 > > The leaf "stream-xpath-filter" says:
 > >
 > >   o  The set of namespace declarations are those in
scope on
 > >  the 'stream-xpath-filter' leaf element.
 > >
 > > (I think I provided that text...)
 > >
 > > This assumes that the encoding is XML, or at leas that the encoding
 > > can somehow transfer namespace declarations.
 >
 > It can't. There are two options:
 >
 > 1. have different representations of this value in XML and JSON,
 >analogically to instance indentifiers (sec. 6.11 in RFC 7951).
 >
 > 2. use a module name rather than a prefix in XML, too.
 >
 > I would suggest #2.
 But that means making non-backwards compatible change to the XML
representation?

Not really. It means NETMOD WG would be creating its own special variant of
XPath.

The thing is that XPath is "XML Path Language", so using it outside XML is
problematic.

Not necessarily.  Section 5 of the XPath 1.0 spec defins the "data
model" where an XPath expression is applied.  We could make a formal
specification of how a YANG data tree maps to this data model (pretty
straightforward...).  I think experience from implementations over the
last 8 years show that this in fact works quite well.

Except some parts that don't apply. For example, siblings nodes in XPath
are ordered, whereas in YANG 'foo[1]' may give unpredictable results.


Not all XPath expressions map to something meaningful in the context of 
YANG data.  However a subset of them do.


IMO introducing yang:ypath1.0 makes sense but it is practical to define 
it as a subset of yang:xpath1.0. Martins proposal 2) for an encoding 
independent solution where the prefixes are restricted to be module 
names works. Proposal 1) seems to be a step back clogging YANG with 
encoding specific details.


Vladimir



This is probably OK in YANG modules but not so much if XPath expressions
are used as configuration data.

Lada



/martin




Lada


 Hmm, so you mean change the leaf "stream-xpath-filter" to say:

  o  The set of namespace declarations has one member for each
 YANG module supported by the server.  This member maps
 from the YANG module name to the YANG module namespace.

 This means that in the XPath expression, the module name
 serves as the prefix.

  and then also give an example of this.

 This is probably what we need to do in all places where yang:xpath1.0
 is used, going forward.  Maybe even define a new type
 yang:xpath1.0-2 (name?) with the set of namespace declarations
 built-in.


We should avoid making off-the-shelf implementations of standards like XPath
unusable.
At the very least this should be only available if the server supports it
(with a capability URI)

  

 So we need an update to RFC7951?

Regards,
Reshad.



Andy
  

 /martin





 >
 > Lada
 >
 > >
 > > How is this supposed to work with JSON?
 > >
 > >
 > > /martin
 > >
 > > ___
 > > 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 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] xpath expressions in JSON

[Vladimir Vassilev]

On 10/11/18 11:43 AM, Vladimir Vassilev wrote:


+1. This is one of the two necessary changes to make the 
instance-identifier type canonical. Proposed changes RFC 7950:


OLD:

9.13.2.  Lexical Representation

   An instance-identifier value is lexically represented as a string.
   All node names in an instance-identifier value MUST be qualified with
   explicit namespace prefixes, and these prefixes MUST be declared in
   the XML namespace scope in the instance-identifier's XML element.

   Any prefixes used in the encoding are local to each instance
   encoding.  This means that the same instance-identifier may be
   encoded differently by different implementations.

9.13.3.  Canonical Form

   Since the lexical form depends on the XML context in which the value
   occurs, this type does not have a canonical form.

NEW:

9.13.2.  Lexical Representation

   An instance-identifier value is lexically represented as a string.
   All node names in an instance-identifier value MUST be qualified with
   explicit namespace prefixes where the module name is used as prefix.

   All predicates must appear in alphabetical order.


9.13.3.  Canonical Form

   Since the lexical form is encoding independent and tere is prescribed

   alphabetical order of the predicates the type has a canonical form.


The order of the keys does not need to be alphabetical. It can be the 
order of the keys specified in the YANG module but currently there is no 
requirement for order at all.


Vladimir




Vladimir







/martin





 Hmm, so you mean change the leaf "stream-xpath-filter" to say:

  o  The set of namespace declarations has one member 
for each
 YANG module supported by the server.  This member 
maps
 from the YANG module name to the YANG module 
namespace.


 This means that in the XPath expression, the 
module name

 serves as the prefix.

  and then also give an example of this.

 This is probably what we need to do in all places where 
yang:xpath1.0

 is used, going forward.  Maybe even define a new type
 yang:xpath1.0-2 (name?) with the set of namespace declarations
 built-in.



We should avoid making off-the-shelf implementations of standards like
XPath unusable.
At the very least this should be only available if the server 
supports it

(with a capability URI)




 So we need an update to RFC7951?

Regards,
Reshad.



Andy



 /martin





 >
 > Lada
 >
 > >
 > > How is this supposed to work with JSON?
 > >
 > >
 > > /martin
 > >
 > > ___
 > > 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 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


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

Re: [netmod] xpath expressions in JSON

[Vladimir Vassilev]

On 10/11/18 11:21 AM, Andy Bierman wrote:


So you must mean the full module name will be used at every node:

 
/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name='eth0']


Length is the only real problem I see with the solution. The lexical 
representation of identityref type has made a compromise accepting 
prefix instead of module name. This has its own unsolved issues but 
those could be addressed by a limitation not allowing modules with 
identical prefix statements to define homonyme data nodes and identities 
(which is not the case currently). If this is done module name can be 
replaced with prefix and the instance-identifiers will be shorter and 
encoding independent but still Xpath 1.0 compatible:


 /if:interfaces/if:interface[if:name='eth0']

Vladimir

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

Re: [netmod] xpath expressions in JSON

[Vladimir Vassilev]

On 10/11/18 8:39 AM, Martin Bjorklund wrote:

Andy Bierman  wrote:

On Wed, Oct 10, 2018 at 6:59 PM, Reshad Rahman (rrahman) 
wrote:


On 2018-10-10, 9:59 AM, "netmod on behalf of Martin Bjorklund" <
netmod-boun...@ietf.org on behalf of m...@tail-f.com> wrote:

 Ladislav Lhotka  wrote:
 > Martin Bjorklund  writes:
 >
 > > Hi,
 > >
 > > While reviewing restconf-notif, I saw this example:
 > >
 > >{
 > >   "ietf-subscribed-notifications:input": {
 > >  "stream": "NETCONF",
 > >  "stream-xpath-filter": "/ds:foo/",
 > >  "dscp": "10"
 > >   }
 > >}
 > >
 > > Note the "stream-xpath-filter".  It has a prefix in the XPath
string.
 > > How are prefixes declared when JSON is used?
 > >
 > > The leaf "stream-xpath-filter" says:
 > >
 > >   o  The set of namespace declarations are those in
scope on
 > >  the 'stream-xpath-filter' leaf element.
 > >
 > > (I think I provided that text...)
 > >
 > > This assumes that the encoding is XML, or at leas that the encoding
 > > can somehow transfer namespace declarations.
 >
 > It can't. There are two options:
 >
 > 1. have different representations of this value in XML and JSON,
 >analogically to instance indentifiers (sec. 6.11 in RFC 7951).
 >
 > 2. use a module name rather than a prefix in XML, too.
 >
 > I would suggest #2.
 But that means making non-backwards compatible change to the XML
representation?


Not really. It means NETMOD WG would be creating its own special variant of
XPath.

Not at all.  What I propose is perfectly fine, legal XPath 1.0.

XPath 1.0 says that an XPath expression is evaluated in a context.
One item in the context is a set of mappings from  to ,
where  is used to lookup prefixes used in the XPath
expression, e.g. in "/foo:interfaces" "foo" is the prefix.

It is perfectly fine to say that the prefix mapping set is this:

"ietf-interfaces" -> "urn:ietf:params:xml:ns:yang:ietf-interfaces"
"ietf-ip" -> "urn:ietf:params:xml:ns:yang:ietf-ip"

and use that to evaluate the expression

   /ietf-interfaces:interfaces/ietf-interfaces:interface/ietf-ip/ipv4


+1. This is one of the two necessary changes to make the 
instance-identifier type canonical. Proposed changes RFC 7950:


OLD:

9.13.2.  Lexical Representation

   An instance-identifier value is lexically represented as a string.
   All node names in an instance-identifier value MUST be qualified with
   explicit namespace prefixes, and these prefixes MUST be declared in
   the XML namespace scope in the instance-identifier's XML element.

   Any prefixes used in the encoding are local to each instance
   encoding.  This means that the same instance-identifier may be
   encoded differently by different implementations.

9.13.3.  Canonical Form

   Since the lexical form depends on the XML context in which the value
   occurs, this type does not have a canonical form.

NEW:

9.13.2.  Lexical Representation

   An instance-identifier value is lexically represented as a string.
   All node names in an instance-identifier value MUST be qualified with
   explicit namespace prefixes where the module name is used as prefix.

   All predicates must appear in alphabetical order.


9.13.3.  Canonical Form

   Since the lexical form is encoding independent and tere is prescribed

   alphabetical order of the predicates the type has a canonical form.


Vladimir







/martin





 Hmm, so you mean change the leaf "stream-xpath-filter" to say:

  o  The set of namespace declarations has one member for each
 YANG module supported by the server.  This member maps
 from the YANG module name to the YANG module namespace.

 This means that in the XPath expression, the module name
 serves as the prefix.

  and then also give an example of this.

 This is probably what we need to do in all places where yang:xpath1.0
 is used, going forward.  Maybe even define a new type
 yang:xpath1.0-2 (name?) with the set of namespace declarations
 built-in.



We should avoid making off-the-shelf implementations of standards like
XPath unusable.
At the very least this should be only available if the server supports it
(with a capability URI)




 So we need an update to RFC7951?

Regards,
Reshad.



Andy



 /martin





 >
 > Lada
 >
 > >
 > > How is this supposed to work with JSON?
 > >
 > >
 > > /martin
 > >
 > > ___
 > > 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
  

Re: [netmod] YANG versioning requirements

[Vladimir Vassilev]

Hi Robert,

On 10/3/18 11:44 AM, Robert Wilton wrote:


Hi Vladimir,

At IETF 102, when I was presenting on the YANG versioning requirements 
(draft-verdt-netmod-yang-versioning-reqs-00), I think you raised a 
concern about requirement 2.2:


2.2 A mechanism SHOULD be defined to determine whether data nodes 
between two arbitrary YANG module revisions have (i) not changed, (ii) 
changed in a backward compatible way, (iii) changed in a non-backward 
compatible way.


IIRC, I think that your specific concern is that this leads to a 
complex solution, which I understand, but I still think that this 
requirement should remain for several reasons:


(1) It is only marked as a SHOULD rather than a MUST. I.e. it is 
desirable that a solution is able to achieve this but is not strictly 
required.


I agree with your point in (1). As long as 2.2 is optional there is no 
problem.





(2) Some tooling for this already exists.  RFC 7950 section 11 already 
defines what constitutes a backwards compatible change, and pyang is 
already capable of comparing two module revisions to partially 
determine what non backwards compatible changes exist between two 
module revisions



(3) Having considered all the various potential solutions to the 
versioning problem, my opinion is that there is only one solution that 
is generically capable of accurately telling a client of what the 
impact is when updating between two releases.  That solution is to 
compare the complete schema for both releases (considering module 
versions, deviations, and features), potentially filtering the 
comparison output by the subset of the schema actually used by the client.


So, whilst I still think a simpler solution may be helpful to 
communicate what sort of changes are contained in a module, I still 
think that the full complex solution will eventually be required to 
truly solve this problem in a robust way.


My point was that the need of complete schema comparison as described in 
(3) is needed for 2.2 but not for 2.1 and thus it will probably make 
sense to decouple the solutions. I am looking forward to see what your 
solution ideas are.




 Hence, are you OK with this requirement text remaining as is, or do 
you still want to see it changed?

Yes I am OK with the text.


Regards,

Vladimir




Thanks,
Rob








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

Re: [netmod] [Detnet] Fwd: New Version Notification for draft-vassilev-netmod-network-bridge-00.txt

[Vladimir Vassilev]

Hi Janos,

The concept defined in this draft goes outside the scope of 802.1Q. 
Taking a subset of the OpenFlow 1.0 spec and defining corresponding 
node-side YANG model with transactional flow table (/flows) and  
optional support for controller introducing single RPC (transmit-packet) 
and notification (packet-received) corresponding to OFPT_PACKET_OUT and 
OFPT_PACKET_IN messages seemed like a natural evolution of the SDN 
concept for the specification of alternative to OpenFlow southbound 
protocol (e.g. over NETCONF). With OpenFlow-derived flow model 
addressing 1. forwarding (switching) and adding a  2. flexible scheduler 
model referencing the flows a complete bridge model is presented. It can 
be implemented seamlessly on all OpenFlow 1.0 and above supporting 
hardware and more importantly extensions (to flow forwarding or 
scheduling) to the OpenFlow spec can be specified in YANG.


A device implementing this model can implement the 802.1Q family of 
models with proper controller software (STP, LLDP etc. which is readily 
available) but it is not limited to that.


We have been following closely the models developed by the IEEE TSN and 
we have both reused terminology and ensured all of those standard 
solutions can be represented with the generic scheduler model part of 
this draft. The IEEE YANG model is great reference but is not suitable 
for all applications especially when more flexibility is required and 
being able to augment a module to document our vendor specific 
extensions. The 802.1Q are limited in certain ways to 802.1Q (for 
example fixed to 8 traffic classes either priority or time slots).


Attempts to make 802.1Q configuration more generic and a subset to a 
more generic forwarding configuration mechanism are not unprecedented  
(see 
https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/ 
). Here virtual interfaces instead of flows are introduced.


IMO a standard flows model is needed starting from something with 
running software and trying to find consensus. I see this goal is 
already part of the detnet focus 
https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model and 
https://datatracker.ietf.org/doc/draft-geng-detnet-conf-yang


Requesting comments on the ietf netmod list seemed like a good place to 
start to allow for open discussion and if we manage to identify anything 
that falls into the scope of IEEE 802.1Q except the name "bridge" I 
would be glad to contribute there. Same goes for the detnet WG.


Vladimir


On 08/03/2018 05:59 PM, János Farkas wrote:

Hi Vladimir,

Bridging including bridge management belong to IEEE 802.1: 
https://1.ieee802.org/. You may consider contributing to IEEE 802.1. 
The next Interim is hosed by your company in Oslo: 
https://1.ieee802.org/meetings.


IEEE 802.1Qcp is the basic bridge management specification, which is 
an approved draft standard to be published soon: 
http://standards.ieee.org/findstds/standard/802.1Qcp-2018.html. (The 
archived web page of the finished project: 
https://1.ieee802.org/tsn/802-1qcp.)


The pages of the ongoing projects are available via the TSN page: 
https://1.ieee802.org/tsn/#Ongoing_TSN_Projects, including P802.1Qcw 
(https://1.ieee802.org/tsn/802-1qcw/), which specifies YANG for 
various bridge scheduling mechanisms.


Best regards,
Janos


On 7/17/2018 4:26 PM, Vladimir Vassilev wrote:

Hi,

I have submitted a draft 
https://datatracker.ietf.org/doc/draft-vassilev-netmod-network-bridge/ 
that proposes a model for network bridge management based on the 
concept of flows. The model has 2 components 1. Forwarding based on 
flows. 2. Scheduling/QoS based on gate controller topologies that 
provide a new and very generic way of modeling and managing the 
actual scheduler design and map the flows to scheduler topology inputs.


There is similar work on the flow based forwarding in detnet however 
I am not sure detnet is the right workgroup to be defining the flow 
model.  I think the flow concept is important and general. It is as 
significant as the concept of interfaces and is not only relevant to 
detnet. Let me know what is your opinion of the draft and the 
proposed network bridge concept.


Vladimir

 Forwarded Message 
Subject: New Version Notification for 
draft-vassilev-netmod-network-bridge-00.txt

Date: Sat, 14 Jul 2018 22:04:06 -0700
From: internet-dra...@ietf.org
To:     Vladimir Vassilev 



A new version of I-D, draft-vassilev-netmod-network-bridge-00.txt
has been successfully submitted by Vladimir Vassilev and posted to the
IETF repository.

Name:    draft-vassilev-netmod-network-bridge
Revision:    00
Title:    A YANG Data Model for Network Bridge Management
Document date:    2018-07-14
Group:    Individual Submission
Pages:    44
URL: 
https://www.ietf.org/internet-drafts/draft-vassilev-netmod-network-bridge-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-vassilev-netmod-network-bridge/
Htmliz

[netmod] Fwd: New Version Notification for draft-vassilev-netmod-network-bridge-00.txt

[Vladimir Vassilev]

Hi,

I have submitted a draft 
https://datatracker.ietf.org/doc/draft-vassilev-netmod-network-bridge/ 
that proposes a model for network bridge management based on the concept 
of flows. The model has 2 components 1. Forwarding based on flows. 2. 
Scheduling/QoS based on gate controller topologies that provide a new 
and very generic way of modeling and managing the actual scheduler 
design and map the flows to scheduler topology inputs.


There is similar work on the flow based forwarding in detnet however I 
am not sure detnet is the right workgroup to be defining the flow 
model.  I think the flow concept is important and general. It is as 
significant as the concept of interfaces and is not only relevant to 
detnet. Let me know what is your opinion of the draft and the proposed 
network bridge concept.


Vladimir

 Forwarded Message 
Subject: 	New Version Notification for 
draft-vassilev-netmod-network-bridge-00.txt

Date:   Sat, 14 Jul 2018 22:04:06 -0700
From:   internet-dra...@ietf.org
To: Vladimir Vassilev 



A new version of I-D, draft-vassilev-netmod-network-bridge-00.txt
has been successfully submitted by Vladimir Vassilev and posted to the
IETF repository.

Name:   draft-vassilev-netmod-network-bridge
Revision:   00
Title:  A YANG Data Model for Network Bridge Management
Document date:  2018-07-14
Group:  Individual Submission
Pages:  44
URL:
https://www.ietf.org/internet-drafts/draft-vassilev-netmod-network-bridge-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-vassilev-netmod-network-bridge/
Htmlized:   
https://tools.ietf.org/html/draft-vassilev-netmod-network-bridge-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-vassilev-netmod-network-bridge


Abstract:
   This document introduces new YANG model of a network bridge.

  



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

The IETF Secretariat

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

Re: [netmod] choice/case in tree diagrams

[Vladimir Vassilev]

On 03/05/2018 06:40 PM, Per Hedeland wrote:

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.
When I think about it  do not have any information contents  
outside of the context of a data tree and its schema. So if we are 
removing clutter we should probably start there by specifying that 
 should be ommited under rpc,notification and action.


Vladlimir


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


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

Re: [netmod] choice/case in tree diagrams

[Vladimir Vassilev]

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


Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> 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

[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] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02

[Vladimir Vassilev]

On 02/07/2018 11:02 PM, Andy Bierman wrote:


Hi,

Many good points.
IMO it will be difficult to agree on the details of this draft
without agreeing on the problem statement first.
As a process issue, this seems like an important step.

+1

It is usually handled with WG charter text, but NETMOD
has a free pass on new YANG modules somehow.

I am interested in these tags as a new type of standard selection filter.
It can be applied to data retrieval, NACM rules, YANG push subtree 
selection,

and probably many more use-cases.  So the problem statement
might be:

   There is a need for standardized mechanisms to classify YANG data 
nodes with tags,
   which can be used in protocol operations to select matching data 
nodes, based on tag values.
   This work includes the management and assignment of tags, and their 
generalized use

   within protocol operations.
A practical usecase example in addition to this text could really help. 
I suspect Phil is right that "the authors
have more in their heads than they've put into the draft" but even with 
this text an example is needed to illistrate the purpose of this work.


Vladimir



Andy


On Wed, Feb 7, 2018 at 10:59 AM, Phil Shafer > wrote:


Andy Bierman writes:
>The draft avoids discussion of any useful operations based on tags.

Nor does it really clearly say "what" is being tagged. The absract
talks about "used to help classify and organize modules", but the
Introduction lacks any expansion on this.  There's really no clear
problem statement or a clear definition of why we need tags or what
one would use them for.

It would also be helpful to understand why "#hashtag" and the string
format ("ietf:routing", "vendor:super-duper:...") are chosen over
YANG identities.  It seems like identity naming standards and
inheritance
would be good features.

Also it's not clear why these would be configurable rather that
controlled by the module author.  I'd rather have the OAM standard
YANG module say something like:

    module ietf-oam {
        import "ietf-category" { prefix ietf-category; }

        identify ietf-oam {
            base ietf-category:ietf-standard;
            description "This module category represents something
                         OAM related.";
        }

        ietf-category:module-category ietf-oam;
        ...
    }

The draft says:

   Implementations that do not support the reset rpc statement
(whether
   at all, or just for a particular rpc or module) MUST respond
with an
   YANG transport protocol-appropriate rpc layer error when such a
   statement is received.

The entire idea of NETCONF/YANG is that the client _knows_ what it
can safely send instead of tossing spaghetti at the wall until
something sticks.  Avoid programming-by-error-detection, which
creates fragile infrastructure.

Use "feature" to control optional portions of a YANG module.  I'd
suggest one feature for "reset" support and another for "read-only",
since IMHO the idea of someone munging the categories of standard
modules is, well, disconcerting.

"Local" tags are not well explained.  The idea of a user/admin
tagging modules means that something is broken.  Users shouldn't
understand YANG modules.  Users use applications, some of which are
home-grown.  Is "local" appropriate for my "audit interfaces" script?

6.1 is missing the list "module-tags".

9.1 advocates putting vital information in the description string,
which is IMHO not a good idea.  We want to put as much information
in machine-readable format as possible, so I can ask ietf.org

questions like "give me a list of ietf-oam-related yang modules"
and get a nice list.

It also talks about "SHOULD" and "MAY" tags without giving any
clue as to why or when this would be appropriate or useful.

So my vote would be that this document needs some significant work
and expansion before it's a supportable draft.  I think the authors
have more in their heads than they've put into the draft and I'd
like to see the rest of their thoughts.

Thanks,
 Phil




___
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] [Netconf] LC of NDMA NETCONF/RESTCONF drafts

[Vladimir Vassilev]

Hello,

There is a YANG error in ietf-netconf-n...@2018-01-17.yang:

Error: XPath expression 'derived-from-or-self(../datastore, 
"or:operational")' with invalid identity param 'or:operational'

ietf-netconf-nmda.yang:148.63: error(348): invalid XPath expression syntax

Error: XPath expression 'derived-from-or-self(../datastore, 
"or:operational")' with invalid identity param 'or:operational'

ietf-netconf-nmda.yang:178.63: error(348): invalid XPath expression syntax

The correct datastore identity is ds:operational. The same error was 
reported for the previous version of the draft.



 Forwarded Message 
Subject: [netmod] validation of draft-ietf-netconf-nmda-netconf-01
Date: Mon, 13 Nov 2017 19:48:49 +0100
From:     Vladimir Vassilev <vladi...@transpacket.com>
To: netmod@ietf.org <netmod@ietf.org>

Hello,

There is a validation error reported for
ietf-netconf-datasto...@2017-08-24.yang:

Error: XPath expression 'derived-from-or-self(../datastore,
"or:operational")' with invalid identity param 'or:operational'
ietf-netconf-datasto...@2017-08-24.yang:140.63: error(348): invalid
XPath expression syntax


Vladimir

On 01/17/2018 07:39 PM, Mahesh Jethanandani wrote:

The authors of draft-ietf-netconf-nmda-netconf and 
draft-ietf-netconf-nmda-restconf have posted updates to their drafts, and 
believe that the documents are ready for LC.

This starts a 2 week LC on the two drafts that will end on January 31. Please 
send your comments on this thread. Comments like “I have reviewed the documents 
and believe they are ready for publication”, or “I have concerns about the 
document because …” are welcome and useful for the authors.

Authors please indicate whether you are aware of any IPR for either of the 
drafts.

Thanks.

Mahesh & Kent

___
Netconf mailing list
netc...@ietf.org
https://www.ietf.org/mailman/listinfo/netconf


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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Vladimir Vassilev]

On 01/16/2018 09:06 PM, Juergen Schoenwaelder wrote:

On Tue, Jan 16, 2018 at 08:19:38PM +0100, Vladimir Vassilev wrote:

As for the automated validation of the tree diagrams as an added value to
the human readability I have the following thoughts. I would like to be able
to compare unlimited line length tree outputs generated by different YANG
compilers for equality. This is mainly a way to have some partial common
denominator output for validating YANG is correctly compiled which we did
not have until now. For example as soon as I have support for Schema mount I
would compare the tree output with another tool known to work and add some
testcases based on that. I do not see any automated alternative for doing
this except writing NETCONF chat scripts (also module specific), or writing
not only YANG module specific but also API specific test cases as 3rd
option. 1) does not compromise this automated validation option since space
sequences can be collapsed to single space. If the alignment algorithm was
creating a possibility for nontrivial output variation then I would have
supported strongly 3) but this is not the current case.


If you want to make sure a YANG compiler is correct, simply write a
backend that generates a serialized YANG module in canonical
form. They YANG modules should be the same. Determining YANG compiler
correctness by comparing tree diagrams does not seem to be a
convincing approach since tree diagrams by design leave many details
out.
The advantage I see is that 'uses' and 'augments' are resolved in the 
tree output. For example one can not cach bug in the reolution of the 
configure flag in a uses expanded under case with "configure false;" by 
generating YANG with unresolved 'uses'.  Another example - one can not 
represent the result of multiple modules augmenting e.g. /interfaces 
with a YANG module. The only universal representation is the YANG tree.


Vladimir

/js



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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Vladimir Vassilev]

On 01/16/2018 06:34 PM, joel jaeggli wrote:



On 1/16/18 8:01 AM, Robert Wilton wrote:


On 16/01/2018 15:40, Martin Bjorklund wrote:

Vladimir Vassilev <vladi...@transpacket.com> wrote:



Does anyone else have an opinion on this?  I can see three
alternatives:

    1) allow any number of addtional spaces
    2) allow any number of addtional spaces + define a suggested
   alignment algorithm
    3) mandate the alignment algorithm

Definition of symbols should be precise/consistent, so that readers
can consistently interpret tree diagrams.

I think that flexibility in layout should be OK, but the draft should
provide guideline to ensure the output is readable, and likely to be
broadly consistent (since consistency aids readability).

If the IETF data modeling group is trying to specify text output
precisely enough that it can be screen scraped then we may want to
consider whether we are focusing on the right solution ;-)

I would hope that we are not, as the diagrams are programmatically
generated if you wanted to for example validate them one should do that
from the sources.

Approaches that result in the most easily human readable, followed by
consistency between tools is probably better for that. That said this is
almost the indentation wars so the proscriptive it gets the more dissent
you can probably find (e.g. 3).

To make it clear I think 1) works with the text proposed by Martin.

As said I posted the pyang alignment algorithm description in a sort of 
2) variant only for reference on the mailing list since I implemented 
that too. Starting indentation war was not my intention.


As for the automated validation of the tree diagrams as an added value 
to the human readability I have the following thoughts. I would like to 
be able to compare unlimited line length tree outputs generated by 
different YANG compilers for equality. This is mainly a way to have some 
partial common denominator output for validating YANG is correctly 
compiled which we did not have until now. For example as soon as I have 
support for Schema mount I would compare the tree output with another 
tool known to work and add some testcases based on that. I do not see 
any automated alternative for doing this except writing NETCONF chat 
scripts (also module specific), or writing not only YANG module specific 
but also API specific test cases as 3rd option. 1) does not compromise 
this automated validation option since space sequences can be collapsed 
to single space. If the alignment algorithm was creating a possibility 
for nontrivial output variation then I would have supported strongly 3) 
but this is not the current case.


Vladimir



In summary, (2) is my preference, followed by (1), followed by (3).

Thanks,
Rob



/martin



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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Vladimir Vassilev]

On 01/16/2018 11:56 AM, Martin Bjorklund wrote:


Vladimir Vassilev <vladi...@transpacket.com> wrote:

Hi,

I have reviewed and implemented (apart from schema mount specific
functionality) draft-ietfetf-netmod-yang-tree-diagrams-04 and found
the following issues:

==sec 2.6.  Node Representation==

1. To correctly reflect the current pyang output one needs to add '--'
between  and .
OLD:
      
NEW:
     --

Ok.


There is also undocumented alignment space count function before
 that pyang uses to align the  fields of child data leafs
with common ancestor. If this is specified in the draft the tree
output can be deterministic and for me this is an advantage. This is
currently one of the few underspecified pieces of the tree format so I
had to check pyang implementation in oder to generate same alignment
space counts and binary identical tree output results.

I think that we at least should write that there may be more than one
space between  and :

   There may be any number of additional space characters between
and .
For the sake of the argument (at least having this on the mailing list 
as reference):


   should be aligned at a common offset for all sibling nodes
  from the start of  by adding trailing spaces. The recommended
  offset is 3 plus the length of the longest node name among all 
sibling nodes

  including those siblings defined under choice and case nodes.

This is what pyang does now. It is not a perfect solution but it allows 
identical output down to the bit.




I also just realized that we need to add text to the line wrapping
section about line breaks between  and :

OLD:

Internet Drafts and RFCs limit the number of characters that may in a
line of text to 72 characters.  When the tree representation of a
node results in line being longer than this limit the line should be
broken between  and .  The type should be indented so
that the new line starts below  with a white space offset of at
least two characters.

NEW:

Internet Drafts and RFCs limit the number of characters in a line
of text to 72 characters.  When the tree representation of a node
results in line being longer than this limit the line should be
broken between  and , or between  and
.  The new line should be indented so that it starts
below  with a white space offset of at least two characters.



2. It is unclear which  option should be used for rpc and
action input/output and child nodes and the notification child
nodes. pyang uses '-w' for input and input/* and 'ro' for output and
output/*:

     module: ietf-netconf-partial-lock
   rpcs:
     +---x partial-lock
     |  +---w input
     |  |  +---w select*   string
     ...

I'll do:

OLD:

 is one of:
  rw  for configuration data
  ro  for non-configuration data
  -u  for uses of a grouping
  -x  for rpcs and actions
  -n  for notifications
  mp  for nodes containing a "mount-point" extension statment

NEW:

 is one of:
  rw  for configuration data
  ro  for non-configuration data, output parameters to rpcs
  and actions, and notification parameters
  -w  for input parameters to rpcs and actions
  -u  for uses of a grouping
  -x  for rpcs and actions
  -n  for notifications
  mp  for nodes containing a "mount-point" extension statment

OK



pyang also uses '--' as  for augmentation data nodes for
actions input.

I think that this is a bug in pyang, which I have now fixed.

OK



     ...
   augment
/rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input:
     + destination-address?   inet:ipv4-address
     ...


3. pyang is prefixing choice node names with the parent 
e.g. +--ro (next-hop-options) while case nodes are not prefixed. I
guess this is a bug in pyang since it is not specified in the draft
but choice nodes prefixed with parent  are  also present in the
sec 4 and 4.1 examples?

[ignoring based on latest email from Vladimir]


4. This bit I found confusing. I propose this change to unambiguously
describe the current pyang format.

OLD:
  *  for a leaf-list or list
  [] for a list's keys
NEW:
  *  for a leaf-list or list without keys
  * [] for a list with keys

Hmm, wouldn't it be better to use [] for a list w/o keys?
Yes I also agree this improves readability at the cost of slight 
redundancy increase and modification to format of diagrams already used 
in RFCs. Your call.


Vladimir



/martin




Vladimir

On 01/01/2018 11:01 PM, joel jaeggli wrote:

Greetings,

We hope  the new year is a time to make great progess on outstanding
documents before preparation for the  London IETF begins in earnest.

This starts a two-week working group last call on:

   YANG Tree Diagrams
draft-ietf-netmod-yang-tree-diagrams

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-di

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Vladimir Vassilev]

On 01/15/2018 09:41 PM, Vladimir Vassilev wrote:

Hi,

I have reviewed and implemented (apart from schema mount specific 
functionality) draft-ietfetf-netmod-yang-tree-diagrams-04 and found 
the following issues:


==sec 2.6.  Node Representation==

1. To correctly reflect the current pyang output one needs to add '--' 
between  and .

OLD:
     
NEW:
    --

There is also undocumented alignment space count function before 
 that pyang uses to align the  fields of child data leafs 
with common ancestor. If this is specified in the draft the tree 
output can be deterministic and for me this is an advantage. This is 
currently one of the few underspecified pieces of the tree format so I 
had to check pyang implementation in oder to generate same alignment 
space counts and binary identical tree output results.



2. It is unclear which  option should be used for rpc and 
action input/output and child nodes and the notification child nodes. 
pyang uses '-w' for input and input/* and 'ro' for output and output/*:


    module: ietf-netconf-partial-lock
  rpcs:
    +---x partial-lock
    |  +---w input
    |  |  +---w select*   string
    ...

pyang also uses '--' as  for augmentation data nodes for 
actions input.


    ...
  augment /rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input:
    + destination-address?   inet:ipv4-address
    ...


3. pyang is prefixing choice node names with the parent  e.g. 
+--ro (next-hop-options) while case nodes are not prefixed. I guess 
this is a bug in pyang since it is not specified in the draft but 
choice nodes prefixed with parent  are  also present in the sec 
4 and 4.1 examples?
Ignore 3. choice had a config substatement which explains the presence 
of .


4. This bit I found confusing. I propose this change to unambiguously 
describe the current pyang format.


OLD:
 *  for a leaf-list or list
 [] for a list's keys
NEW:
 *  for a leaf-list or list without keys
 * [] for a list with keys

Vladimir

On 01/01/2018 11:01 PM, joel jaeggli wrote:

Greetings,

We hope  the new year is a time to make great progess on outstanding
documents before preparation for the  London IETF begins in earnest.

This starts a two-week working group last call on:

  YANG Tree Diagrams
draft-ietf-netmod-yang-tree-diagrams

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/

Please send email to the list indicating your support or concerns.

We are particularly interested in statements of the form:

   * I have reviewed this draft and found no issues.
   * I have reviewed this draft and found the following issues: ...


Thank you,
NETMOD WG Chairs


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


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

Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

[Vladimir Vassilev]

Hi,

I have reviewed and implemented (apart from schema mount specific 
functionality) draft-ietfetf-netmod-yang-tree-diagrams-04 and found the 
following issues:


==sec 2.6.  Node Representation==

1. To correctly reflect the current pyang output one needs to add '--' 
between  and .

OLD:
     
NEW:
    --

There is also undocumented alignment space count function before  
that pyang uses to align the  fields of child data leafs with 
common ancestor. If this is specified in the draft the tree output can 
be deterministic and for me this is an advantage. This is currently one 
of the few underspecified pieces of the tree format so I had to check 
pyang implementation in oder to generate same alignment space counts and 
binary identical tree output results.



2. It is unclear which  option should be used for rpc and action 
input/output and child nodes and the notification child nodes. pyang 
uses '-w' for input and input/* and 'ro' for output and output/*:


    module: ietf-netconf-partial-lock
  rpcs:
    +---x partial-lock
    |  +---w input
    |  |  +---w select*   string
    ...

pyang also uses '--' as  for augmentation data nodes for actions 
input.


    ...
  augment /rt:routing-state/rt:ribs/rt:rib/rt:active-route/rt:input:
    + destination-address?   inet:ipv4-address
    ...


3. pyang is prefixing choice node names with the parent  e.g. 
+--ro (next-hop-options) while case nodes are not prefixed. I guess this 
is a bug in pyang since it is not specified in the draft but choice 
nodes prefixed with parent  are  also present in the sec 4 and 
4.1 examples?


4. This bit I found confusing. I propose this change to unambiguously 
describe the current pyang format.


OLD:
 *  for a leaf-list or list
 [] for a list's keys
NEW:
 *  for a leaf-list or list without keys
 * [] for a list with keys

Vladimir

On 01/01/2018 11:01 PM, joel jaeggli wrote:

Greetings,

We hope  the new year is a time to make great progess on outstanding
documents before preparation for the  London IETF begins in earnest.

This starts a two-week working group last call on:

  YANG Tree Diagrams
draft-ietf-netmod-yang-tree-diagrams

https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/

Please send email to the list indicating your support or concerns.

We are particularly interested in statements of the form:

   * I have reviewed this draft and found no issues.
   * I have reviewed this draft and found the following issues: ...


Thank you,
NETMOD WG Chairs


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

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

[Vladimir Vassilev]

On 12/21/2017 02:20 PM, Juergen Schoenwaelder wrote:


On Thu, Dec 21, 2017 at 02:03:45PM +0100, Vladimir Vassilev wrote:

On 12/21/2017 11:34 AM, Robert Wilton wrote:


Hi Vladimir,

First point of clarification is that this is not about running/intended
at all.  The contents of running/intended do not change in anyway
depending on whether hardware is present or absent.

The section is only concerned with how the configuration is applied in
operational, and basically says that you cannot apply configuration for
resources that are missing (which seems reasonable).  E.g. I cannot
configure an IP address on a physical interface that isn't there.  Or if
the physical interface gets removed then the configuration associated
with that interface is also removed from operational.

Operational isn't validated and data model constraints are allowed to be
broken (ideally transiently).

I want to focus on this. IMO giving up schema validitiy for any datastore is
unacceptable price. Pre-NMDA devices had full model support in operational
data (all YANG constrains part of the model without discrimination were
enforced).

There was a long debate about the value of returning the true
operational state. What do you do if the operational state is invalid?
A server can reject configuration changes if they lead to invalid
state, a server can not reject reality.
IMO if the model can represent reality then data conforming to the model 
can. If not a better model is needed not a hack that breaks the 
datastore conformance to the YANG model. I do not see how 
/interfaces/interface/oper-status=not-present was not representing the 
reality of a system with removed line card that is configured and ready 
to resume operation as soon as the line card is reconnected.

If this is about to change it will compromise interoperability
and a significant portion of the client implementation workload that can be
automated will need to be coded in hand and tested. Unresolved leafrefs,
undefined behaviour of different implementations removing different
configuration nodes in violation of YANG semantic constraints (which I do
not think can be so clearly separated from the syntactic constraints when
one considers types like leafref, instance-identifier etc.) and the
corresponding side effects based on the server implementators own creativity
is eventually going to create more problems.

1. IMO the only acceptable solution is to have YANG valid operational
datastore at all times. operational like any other datastore MUST be valid
YANG data tree and it has to be a system implementation task to consider all
complications resulting from the removal of the resources leading to any
data transformations. If this is difficult or impossible other mechanisms to
flag missing resources should be used (e.g.
/interfaces/interface/oper-status=not-present) This sounds like a useful
contract providing the value of a standard the alternative does not.

As said above, it is impossible to report valid operational state if
the operational state is not valid according to the models.


2. Even with the change in 1. I do not see the removal of intended
configuration nodes from operational as a solution worth implementing on our
servers. I do not see a real world plug-and-play scenario that can be
automatically solved without specific additions to the models e.g.
/interfaces/interface/oper-status=not-present is oversimplified solution but
it needs to be extended exactly as much as the solution provided by the
removal of config true; nodes without the sacrifice of YANG validity of
operational.

Your thinking is likely wrong.  reports the operational
state. It may have little in common with . Trying to derive
operational from intended is likely a not well working approach.
The proposal for this solution ("derive operational from intended" e.g. 
merge /interfaces-state in /interfaces) comes from the revised 
datastores draft not me.


By definition config true; data represents intent. Reusing the model of 
a config true; data to represent state absent of intent (e.g. 
/interfaces/interface with origin="or:system") is a hack. The hack works 
fine without compromising the conformance of operational to the YANG 
model as long as certain conditions are met. I am pointing out that one 
of the conditions is to keep all of the intended configuration data 
present in 'operational' and handle missing resources with conventional 
means e.g. /interfaces/interface/oper-status=not-present instead of 
adding the straw that breaks the camel's back.



3. Solutions like /interfaces/interface/admin-state stop working. With the
interface removed you can no longer figure if the if-mib has or does not
have the interface enabled so an operator has to use SNMP or wait for a
replacement line card to be connected to figure this bit of information.

At least on my boxes, if I remove a line card, the interface also
disappears in SNMP tables. Stuff that is operationally n

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

[Vladimir Vassilev]

On 12/21/2017 11:34 AM, Robert Wilton wrote:


Hi Vladimir,

First point of clarification is that this is not about 
running/intended at all.  The contents of running/intended do not 
change in anyway depending on whether hardware is present or absent.


The section is only concerned with how the configuration is applied in 
operational, and basically says that you cannot apply configuration 
for resources that are missing (which seems reasonable).  E.g. I 
cannot configure an IP address on a physical interface that isn't 
there.  Or if the physical interface gets removed then the 
configuration associated with that interface is also removed from 
operational.


Operational isn't validated and data model constraints are allowed to 
be broken (ideally transiently).
I want to focus on this. IMO giving up schema validitiy for any 
datastore is unacceptable price. Pre-NMDA devices had full model support 
in operational data (all YANG constrains part of the model without 
discrimination were enforced). If this is about to change it will 
compromise interoperability and a significant portion of the client 
implementation workload that can be automated will need to be coded in 
hand and tested. Unresolved leafrefs, undefined behaviour of different 
implementations removing different configuration nodes in violation of 
YANG semantic constraints (which I do not think can be so clearly 
separated from the syntactic constraints when one considers types like 
leafref, instance-identifier etc.) and the corresponding side effects 
based on the server implementators own creativity is eventually going to 
create more problems.


1. IMO the only acceptable solution is to have YANG valid operational 
datastore at all times. operational like any other datastore MUST be 
valid YANG data tree and it has to be a system implementation task to 
consider all complications resulting from the removal of the resources 
leading to any data transformations. If this is difficult or impossible 
other mechanisms to flag missing resources should be used (e.g. 
/interfaces/interface/oper-status=not-present) This sounds like a useful 
contract providing the value of a standard the alternative does not.


2. Even with the change in 1. I do not see the removal of intended 
configuration nodes from operational as a solution worth implementing on 
our servers. I do not see a real world plug-and-play scenario that can 
be automatically solved without specific additions to the models e.g. 
/interfaces/interface/oper-status=not-present is oversimplified solution 
but it needs to be extended exactly as much as the solution provided by 
the removal of config true; nodes without the sacrifice of YANG validity 
of operational.


3. Solutions like /interfaces/interface/admin-state stop working. With 
the interface removed you can no longer figure if the if-mib has or does 
not have the interface enabled so an operator has to use SNMP or wait 
for a replacement line card to be connected to figure this bit of 
information. My interpretation of the MAY as requirement level in sec. 
5.3. The Operational State Datastore () is that 
plug-and-play solutions can be implemented without this limited approach 
that has the same problem as the pre-NMDA only now we have to have 
/interfaces-state to keep config false; data relevant to hardware that 
is configured but not present:


   configuration data nodes supported in a configuration datastore
   MAY be omitted from  if a server is not able to
   accurately report them.

I realize this discussion comes late. I have stated my objections to 
this particular part of the NMDA draft earlier.


Vladimir

  But I agree that there could be configuration that is referencing 
those missing resources, and depending on implementation then that 
configuration may need to become not applied as well.  Or perhaps the 
failure is reported in a different way (e.g. IGP neighbor is down).


I also agree that this is non trivial, but the systems that I am 
familiar with have always had to deal with this issue.  At the data 
model level I don't think that this is any more complex than the 
existing 'when' statement processing that has exactly the same issues 
if a "when" statement becomes invalid during a config change and 
requires the associated configuration to be deleted (which again can 
recursively require configuration to be removed).


Alternative solutions are:
 - mandate that nobody physically removes a linecard if there is still 
configuration referencing it, but it is hard to enforce this in 
software :-)
 - freeze the config from any further changes if a linecard is removed 
that makes the config invalid, but this doesn't seem like a robust 
solution ...


I think that the existing solution is the best approach.

A couple of further comments inline below as well ...

On 20/12/2017 21:44, Vladimir Vassilev wrote:

Hello,

On 12/20/2017 05:40 PM, Benoit Claise wrote:


Dear all,

In order not to be the 

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

[Vladimir Vassilev]

Hello,

On 12/20/2017 05:40 PM, Benoit Claise wrote:


Dear all,

In order not to be the bottleneck in the process and assuming that the 
document will be in "publication requested" pretty soon, here is my AD 
review of draft-ietf-netmod-revised-datastores-08


-


5.3.2. Missing Resources

Configuration in  can refer to resources that are not
available or otherwise not physically present.  In these situations,
these parts of  are not applied.  The data appears in
 but does not appear in .


I have some concerns with this section.

Systems implementing this are expected to remove config true; nodes 
while figuring the necessary changes to ensure the remaining set of 
config true; nodes in operational validates against the operational 
datastore model. The implementation of this is not a trivial task at 
all. In order to remove configuration nodes considered inactive on the 
fly one needs to remove all references to those nodes in mandatory 
leafrefs in the best case and a potentially long and complex dependency 
chain of YANG constrain-statements (Xpath etc.) have to be resolved in a 
worse case. It is difficult to automate this. It requires significant 
effort to track and remove/fix all those dependencies just to come up 
with valid configuration that represents the configuration without the 
"inactive" nodes which in many usecases is completely unjustified 
implementation effort.


In addition in many cases it is not desirable to remove config true; 
nodes that depended on a removed resource. For example:


1. A configuration instance of a filter with mandatory interface-ref 
ingress and egress ports has to be removed from the operational 
datastore if the egress port is removed as a physical resource. This in 
effect removes the config false; statistics that might be still of 
interest counting the matched  traffic while the filter does not have 
physical egress port to send the packets.


2. Alarm that is configured with mandatory reference to the missing 
resource containing a counter of the elapsed time since the resource 
went missing etc.


I do not find any text in the draft addressing the concerns above. I do 
not propose a change yet but I hope to hear what others think about that.


Vladimir


I understand what you want to say.
Let me take an example. I have a router with a Line Card configured 
and working well. if I remove the LC, the configuration should still 
be in the  and  but not in .
However, based on figure below, the notion of "inactive" nodes might 
be misleading. Indeed, people might read that the LC is inactive, so 
the LC configuration should not be in 

  +-+ +---+
  |  | |  |
  |  (ct, rw)   |<---+   +--->| (ct, rw)  |
  +-+|   |+---+
 |   |   |   |
 | +---+ |
 +>|  |<+
   | (ct, rw)  |
   +---+
 |
 |// configuration transformations,
 |// e.g., removal of "inactive"
 |// nodes, expansion of templates
 v
   ++
   |  | // subject to validation
   | (ct, ro)   |
   ++
I understand that "inactive nodes" has a different meaning.

Proposal:
OLD: removal of "inactive" nodes
NEW: removal of the nodes marked as "inactive"

- In the C.1 example,


  bar

  
eth0

  true
  1000

100

  2001:db8::10
  64


  2001:db8::1:100
  64

  
I guess it "or:dynamic" should be replaced by "or:learned"

Justification:

  identity learned {
base origin;
description
  "Denotes configuration learned from protocol interactions with
   other devices, instead of via either the intended
   configuration datastore or any dynamic configuration
   datastore.

   Examples of protocols that provide learned configuration
   include link-layer negotiations, routing protocols,_and DHCP._";

_Editorial:_

- number the figures

- section 8.2
    This document registers two YANG modules in the YANG Module Names
registry [RFC6020 ].  Following the format 
in [RFC6020 ], the the
following registrations are requested:

duplicated "the the"
  
Regards, Benoit (OPS AD)



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


___
netmod mailing list
netmod@ietf.org

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc8022bis-01

[Vladimir Vassilev]

On 12/17/2017 05:57 PM, Acee Lindem (acee) wrote:

Hi Lou, et al,

The only issue we are struggling with is whether we need to specify the
version in the ietf-interfaces import. We have noted that
draft-ietf-netmod-rfc7277bis-01.txt does not import by revision.

We also have so nits:

1. Add an informative reference for
[I-D.ietf-netmod-yang-tree-diagrams].
2. Based on a comment from Vladimir, we added the prefix for
ietf-routing.yang, “rt:”, to several references within ietf-routing.yang.
Was this necessary? Of course, the model compiles with or without the
prefix.
I reverted this in a follow-up comment on the same thread. I believe the 
local prefixes are redundant.


Vladimir


Thanks,
Acee

On 12/15/17, 3:55 PM, "netmod on behalf of Lou Berger"
 wrote:


All,
This last call is closed.

We note that there was an update during the LC and that no comments were
received during the LC period.  As this is simply a mechanical update
that has been discussed in the WG we plan to proceed with the
publication process.

Authors,
Please let/us the WG know when you have published a version ready for
publication.  Also please let the WG know what has changed in the
document since the start of LC (rev -01)

Thank you,
NetMod Chairs



On 11/29/2017 12:26 PM, Lou Berger wrote:

All,

This starts a two-week working group last call on
draft-ietf-netmod-rfc8022bis-01.

Please recall that this update's intention is to
modify the YANG module to be in line with the NMDA
guidelines [1].  Reviewing the diff between the two
drafts [2] should reveal just this.

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.

[1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
[2]
https://tools.ietf.org/rfcdiff?difftype=--hwdiff=rfc8022.txt=dr
aft-ietf-netmod-rfc8022bis-01.txt

Thank you,
Netmod Chairs


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

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


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

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00

[Vladimir Vassilev]

On 12/16/2017 10:46 AM, Martin Bjorklund wrote:


Hi,

Vladimir Vassilev <vladi...@transpacket.com> wrote:

On 12/13/2017 04:26 PM, Vladimir Vassilev wrote:

Hi,

On 12/13/2017 03:47 PM, Martin Bjorklund wrote:


Hi,

Thanks for reporting this.  I'll add the missing origin.  But why did
you think forwarding and mtu should be removed?

1. IMO since  is not present in the  container in the
Appendix A () example and does not have default value in
the model I still think it should be removed.

Alternatively the ipv4/mtu node can be a good example of a
origin="or:system" configuration.

Yes.


    In fact, I think I
missed ,

2. IMO both fixes adding  or removing  should be
OK depending on the RFC6243 defined with-defaults capability
'basic-mode' parameter advertised by the server. I was running the
example with basic-mode=explicit

Right.  I now have this:

   

   
 true
 false
 1500
 
   192.0.2.1
   24
   static
 
 
   192.0.2.2
   00:01:02:03:04:05
 
   
   
 true
 false
 1280
 ...

Do you think this is ok?

Yes. The or:default data makes the example even better.

1. However there is one more default value missing 
(/interfaces/interface[name='eth0']/enabled) for the example to be 
consistent
2. ... and in the last diff I unintentionally omitted the get-data 
output node  required namespace addition (this is also applicable 
to draft-ietf-netmod-7223bis-01):


diff -u before2.xml after2.xml
--- before2.xml    2017-12-18 11:41:54.029279321 +0100
+++ after2.xml    2017-12-18 11:36:25.973850340 +0100
@@ -1,4 +1,4 @@
- 
+ 
    
    eth0
    ianaift:ethernetCsmacd
+   true
    
    
  true


Vladimir



/martin


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

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00

[Vladimir Vassilev]

On 12/13/2017 04:26 PM, Vladimir Vassilev wrote:

Hi,

On 12/13/2017 03:47 PM, Martin Bjorklund wrote:


Hi,

Thanks for reporting this.  I'll add the missing origin.  But why did
you think forwarding and mtu should be removed?
1. IMO since  is not present in the  container in the 
Appendix A () example and does not have default value in 
the model I still think it should be removed.
Alternatively the ipv4/mtu node can be a good example of a 
origin="or:system" configuration.

   In fact, I think I
missed ,
2. IMO both fixes adding  or removing  should be 
OK depending on the RFC6243 defined with-defaults capability 
'basic-mode' parameter advertised by the server. I was running the 
example with basic-mode=explicit


Vladimir


  so here's my diff:

--- ex-get-data-reply.xml
+++ ex-get-data-reply.xml
@@ -13,6 +13,7 @@
  
    
+  true
    false
    1500
    
@@ -20,12 +21,13 @@
  24
  static
    
-  
+  
  192.0.2.2
  00:01:02:03:04:05

    
  
  
+  true
    false
    1280
    



/martin



Vladimir Vassilev <vladi...@transpacket.com> wrote:

Hello,

The previous post was intended for the rfc7223bis Last Call (wrong
subject line).

I just completed similar validation through a testcase for the
examples in rfc7277bis ("Appendix A.  Example: NETCONF 
reply" and "Appendix B.  Example: NETCONF  Reply")

Here there are some inconsistencies between the  output
and the expected  output. A missing origin bug is probably
more significant then the rest. The following patch fixes the
inconsistencies and the testcase passes:

--- before.txt    2017-12-12 20:39:09.037576425 +0100
+++ after.txt    2017-12-12 20:37:46.425656680 +0100
@@ -7,14 +7,12 @@
 ianaift:ethernetCsmacd
 
 
- false
- 1500
   
 192.0.2.1
 24
 static
   
- 
+ 
 192.0.2.2
 
   00:01:02:03:04:05
@@ -22,7 +20,6 @@
   
 
 
- false
   1280
   
 2001:db8::10


In contrast to rfc7223bis-00 I have not reviewed rfc7277bis-00 and
this is only a report of a detected issue.

Vladimir

On 12/11/2017 05:35 PM, Vladimir Vassilev wrote:

Hello,

I've reviewed this document and believe it is ready for publication.

The focus of my review this time was on validating the module and the
example modules and example data through running code. I implemented
NMDA for the open source tools we use and added a testcase that
reproduces the result specified in "Appendix E. Example: NETCONF
 Reply" after loading the configuration specified in
"Appendix D.  Example: NETCONF  Reply" and providing the
config false; data and system originated configuration as needed. I
can confirm the implementation validated the example modules and the
example data producing identical output.

IMO the examples are demonstrating well the concept of NMDA and its
application for the ietf-interfaces module.

I had an issue with a bug in ietf-netconf-datasto...@2017-08-24.yang I
had to fix in order to use the  RPC. The bug is already
reported on the mailing-list.

diff ietf-patched/ietf-netconf-datasto...@2017-08-24.yang
ietf-draft/ietf-netconf-datasto...@2017-08-24.yang
140c140
< when 'derived-from-or-self(../datastore, "ds:operational")';
---

 when 'derived-from-or-self(../datastore, "or:operational")';

Vladimir


On 11/28/2017 08:29 PM, Kent Watsen wrote:

All,

This starts a two-week working group last call on
draft-ietf-netmod-rfc7277bis-00.

Please recall that this update's intention is to
modify the YANG module to be in line with the NMDA
guidelines [1].  Reviewing the diff between the two
drafts [2] should reveal just this.

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

[1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
[2]
https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7277bis-00.txt 



Thank you,
Netmod Chairs

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

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

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


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

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00

[Vladimir Vassilev]

Hi,

On 12/13/2017 03:47 PM, Martin Bjorklund wrote:


Hi,

Thanks for reporting this.  I'll add the missing origin.  But why did
you think forwarding and mtu should be removed?
1. IMO since  is not present in the  container in the 
Appendix A () example and does not have default value in the 
model I still think it should be removed.

   In fact, I think I
missed ,
2. IMO both fixes adding  or removing  should be OK 
depending on the RFC6243 defined with-defaults capability 'basic-mode' 
parameter advertised by the server. I was running the example with 
basic-mode=explicit


Vladimir


  so here's my diff:

--- ex-get-data-reply.xml
+++ ex-get-data-reply.xml
@@ -13,6 +13,7 @@
  
  
  

+  true
false
1500

@@ -20,12 +21,13 @@
  24
  static

-  
+  
  192.0.2.2
  00:01:02:03:04:05

  
  
+  true
false
1280




/martin



Vladimir Vassilev <vladi...@transpacket.com> wrote:

Hello,

The previous post was intended for the rfc7223bis Last Call (wrong
subject line).

I just completed similar validation through a testcase for the
examples in rfc7277bis ("Appendix A.  Example: NETCONF 
reply" and "Appendix B.  Example: NETCONF  Reply")

Here there are some inconsistencies between the  output
and the expected  output. A missing origin bug is probably
more significant then the rest. The following patch fixes the
inconsistencies and the testcase passes:

--- before.txt    2017-12-12 20:39:09.037576425 +0100
+++ after.txt    2017-12-12 20:37:46.425656680 +0100
@@ -7,14 +7,12 @@
     ianaift:ethernetCsmacd
     
     
- false
- 1500
   
     192.0.2.1
     24
     static
   
- 
+ 
     192.0.2.2
     
   00:01:02:03:04:05
@@ -22,7 +20,6 @@
   
     
     
- false
   1280
   
     2001:db8::10


In contrast to rfc7223bis-00 I have not reviewed rfc7277bis-00 and
this is only a report of a detected issue.

Vladimir

On 12/11/2017 05:35 PM, Vladimir Vassilev wrote:

Hello,

I've reviewed this document and believe it is ready for publication.

The focus of my review this time was on validating the module and the
example modules and example data through running code. I implemented
NMDA for the open source tools we use and added a testcase that
reproduces the result specified in "Appendix E. Example: NETCONF
 Reply" after loading the configuration specified in
"Appendix D.  Example: NETCONF  Reply" and providing the
config false; data and system originated configuration as needed. I
can confirm the implementation validated the example modules and the
example data producing identical output.

IMO the examples are demonstrating well the concept of NMDA and its
application for the ietf-interfaces module.

I had an issue with a bug in ietf-netconf-datasto...@2017-08-24.yang I
had to fix in order to use the  RPC. The bug is already
reported on the mailing-list.

diff ietf-patched/ietf-netconf-datasto...@2017-08-24.yang
ietf-draft/ietf-netconf-datasto...@2017-08-24.yang
140c140
< when 'derived-from-or-self(../datastore, "ds:operational")';
---

     when 'derived-from-or-self(../datastore, "or:operational")';

Vladimir


On 11/28/2017 08:29 PM, Kent Watsen wrote:

All,

This starts a two-week working group last call on
draft-ietf-netmod-rfc7277bis-00.

Please recall that this update's intention is to
modify the YANG module to be in line with the NMDA
guidelines [1].  Reviewing the diff between the two
drafts [2] should reveal just this.

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

[1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
[2]
https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7277bis-00.txt

Thank you,
Netmod Chairs

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

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

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


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

Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis

[Vladimir Vassilev]

On 12/13/2017 08:40 AM, Martin Bjorklund wrote:


Vladimir Vassilev <vladi...@transpacket.com> wrote:

On 12/12/2017 08:20 PM, Martin Bjorklund wrote:


Hi,

Vladimir Vassilev <vladi...@transpacket.com> wrote:

On 12/08/2017 04:06 PM, Juergen Schoenwaelder wrote:

On Fri, Dec 08, 2017 at 04:03:06PM +0100, Martin Bjorklund wrote:

Vladimir Vassilev <vladi...@transpacket.com> wrote:

On 11/15/2017 06:29 PM, Robert Wilton wrote:


I don't think that this is really a good idea.  You would end up
returning server metadata in addition to the configuration.

Obviously RFC 7895 defines only config false; data and I was not
proposing a change to that. But I agree something has to be added to
complete the solution. Special purpose datastore identities can be
defined that return instance of yang-library data when read with
. (Datastores with yang-library config false; only data not
represented in 'operational')

Adding this special yang-library-datastore to the proposed
ietf-datastores container e.g.

module: ietf-datastores
+--ro datastores
|  +--ro datastore* [name]
| +--ro name  identityref
| +--ro yang-library-datastore  identityref


I don't understand this proposal.  How would a client learn the
library for ?  For ?

My interpretation is that the client reads the datastores list from
 and the list entries give you the identity of a separate
datastore that gives you the content of the yang library for that
datastore. (For each datastore, you have a separate datastore to
report its yang library.)

Yes. The default value for yang-library-datastore leaf is
ds:operational (the only possible one for the ds:operational
datastore). This is backward compatible. If one needs different model
for 'running', etc. then a new datastore identity has to be defined
and set in place of the default value. Then this identity can be used
to read the yang-library data with .

Ah, ok.  This is a clever solution, but quite complicated.  It
requires several round trips for a client to learn all library
instances.  Also, w/o any changes, it is not clear which module-set-id
is sent in the capability, and a client must query all module-set-ids
in all (meta)datastores in order to just check if it has the latest
version or not.  It is also not clear how the existing notification
"yang-library-change" would work when there are multiple instances
involved.

How about this?
module: ietf-datastores
...
   augment /yanglib:yang-library-change:
     + datastore?   identityref

This has the same issue as augementing a datastore leaf-list into the
current /modules-state/modules list would have - old clients won't
understand this new node.
IMO it is different. Augmenting the data tree under /modules-state can 
potentially compromise the bootstrap resolution of the model context 
(depending on whether ignoring the data with unknown namespaces does 
change the original model semantics). However I do not see any issue 
with the case of the proposed augmentation to yang-library-change 
notification. Correctly implemented client needs to read /modules-state 
and make sure there are no unsupported modules,features etc. (e.g. 
ietf-datastores is supported) before going further (e.g. subscribing to 
notifications editing configuration etc.).

/martin


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

Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis

[Vladimir Vassilev]

On 12/13/2017 08:19 AM, Vladimir Vassilev wrote:

On 12/12/2017 08:20 PM, Martin Bjorklund wrote:


Hi,

Vladimir Vassilev <vladi...@transpacket.com> wrote:


On 12/08/2017 04:06 PM, Juergen Schoenwaelder wrote:

On Fri, Dec 08, 2017 at 04:03:06PM +0100, Martin Bjorklund wrote:

Vladimir Vassilev <vladi...@transpacket.com> wrote:

On 11/15/2017 06:29 PM, Robert Wilton wrote:


I don't think that this is really a good idea.  You would end up
returning server metadata in addition to the configuration.

Obviously RFC 7895 defines only config false; data and I was not
proposing a change to that. But I agree something has to be added to
complete the solution. Special purpose datastore identities can be
defined that return instance of yang-library data when read with
. (Datastores with yang-library config false; only data 
not

represented in 'operational')

Adding this special yang-library-datastore to the proposed
ietf-datastores container e.g.

module: ietf-datastores
+--ro datastores
|  +--ro datastore* [name]
| +--ro name  identityref
| +--ro yang-library-datastore  identityref


I don't understand this proposal.  How would a client learn the
library for ?  For ?

My interpretation is that the client reads the datastores list from
 and the list entries give you the identity of a separate
datastore that gives you the content of the yang library for that
datastore. (For each datastore, you have a separate datastore to
report its yang library.)

Yes. The default value for yang-library-datastore leaf is
ds:operational (the only possible one for the ds:operational
datastore). This is backward compatible. If one needs different model
for 'running', etc. then a new datastore identity has to be defined
and set in place of the default value. Then this identity can be used
to read the yang-library data with .

Ah, ok.  This is a clever solution, but quite complicated.  It
requires several round trips for a client to learn all library
instances.  Also, w/o any changes, it is not clear which module-set-id
is sent in the capability,
The module-set-id sent in capabilities has to be the one for operational 
since the client needs to get started by reading /datastores-state.

and a client must query all module-set-ids
in all (meta)datastores in order to just check if it has the latest
version or not.
Adding a /datastores-state/datastore/module-set-id leaf in operational 
can resolve this problem.


At the current point I think all issues raised are addressed with the 
following model (notice the added anydata option which can replace the 
use of yang-library-datastore and if implemented as an alternative can 
make retrieval as a single tree):


module: ietf-datastores
    +--ro datastores-state
   +--ro datastore* [name]
   +--ro module-set-id string
   +--ro (model)?
  +--:(same-as-operational)
  +--:(constrained-to-operational)
  |  +--ro not-implemented* [name revision]
  | +--ro name    -> /yanglib:module-state/module/name
  | +--ro revision    -> /yanglib:module-state/module/revision
  +--:(unconstrained-datastore-instance)
  |  +--ro yang-library-datastore    identityref
  +--:(unconstrained-anydata)
 +--ro yang-library? 

  augment /yanglib:yang-library-change:
    + datastore?   identityref

Vladimir


  It is also not clear how the existing notification
"yang-library-change" would work when there are multiple instances
involved.

How about this?
module: ietf-datastores
...
  augment /yanglib:yang-library-change:
    + datastore?   identityref

Vladimir

   So I don't think that this solution will actually work w/o
an update to 7895 - but not updating 7895 was the whole reason for
doing this.


/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] [Netconf] Alternative YANG library structure for 7895bis

[Vladimir Vassilev]

On 12/12/2017 08:20 PM, Martin Bjorklund wrote:


Hi,

Vladimir Vassilev <vladi...@transpacket.com> wrote:


On 12/08/2017 04:06 PM, Juergen Schoenwaelder wrote:

On Fri, Dec 08, 2017 at 04:03:06PM +0100, Martin Bjorklund wrote:

Vladimir Vassilev <vladi...@transpacket.com> wrote:

On 11/15/2017 06:29 PM, Robert Wilton wrote:


I don't think that this is really a good idea.  You would end up
returning server metadata in addition to the configuration.

Obviously RFC 7895 defines only config false; data and I was not
proposing a change to that. But I agree something has to be added to
complete the solution. Special purpose datastore identities can be
defined that return instance of yang-library data when read with
. (Datastores with yang-library config false; only data not
represented in 'operational')

Adding this special yang-library-datastore to the proposed
ietf-datastores container e.g.

module: ietf-datastores
+--ro datastores
|  +--ro datastore* [name]
| +--ro name  identityref
| +--ro yang-library-datastore  identityref


I don't understand this proposal.  How would a client learn the
library for ?  For ?

My interpretation is that the client reads the datastores list from
 and the list entries give you the identity of a separate
datastore that gives you the content of the yang library for that
datastore. (For each datastore, you have a separate datastore to
report its yang library.)

Yes. The default value for yang-library-datastore leaf is
ds:operational (the only possible one for the ds:operational
datastore). This is backward compatible. If one needs different model
for 'running', etc. then a new datastore identity has to be defined
and set in place of the default value. Then this identity can be used
to read the yang-library data with .

Ah, ok.  This is a clever solution, but quite complicated.  It
requires several round trips for a client to learn all library
instances.  Also, w/o any changes, it is not clear which module-set-id
is sent in the capability, and a client must query all module-set-ids
in all (meta)datastores in order to just check if it has the latest
version or not.  It is also not clear how the existing notification
"yang-library-change" would work when there are multiple instances
involved.

How about this?
module: ietf-datastores
...
  augment /yanglib:yang-library-change:
    + datastore?   identityref

Vladimir

   So I don't think that this solution will actually work w/o
an update to 7895 - but not updating 7895 was the whole reason for
doing this.


/martin



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

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00

[Vladimir Vassilev]

Hello,

The previous post was intended for the rfc7223bis Last Call (wrong 
subject line).


I just completed similar validation through a testcase for the examples 
in rfc7277bis ("Appendix A.  Example: NETCONF  reply" and 
"Appendix B.  Example: NETCONF  Reply")


Here there are some inconsistencies between the  output and 
the expected  output. A missing origin bug is probably more 
significant then the rest. The following patch fixes the inconsistencies 
and the testcase passes:


--- before.txt    2017-12-12 20:39:09.037576425 +0100
+++ after.txt    2017-12-12 20:37:46.425656680 +0100
@@ -7,14 +7,12 @@
    ianaift:ethernetCsmacd
    
    
- false
- 1500
  
    192.0.2.1
    24
    static
  
- 
+ 
    192.0.2.2
    
  00:01:02:03:04:05
@@ -22,7 +20,6 @@
  
    
    
- false
  1280
  
    2001:db8::10


In contrast to rfc7223bis-00 I have not reviewed rfc7277bis-00 and this 
is only a report of a detected issue.


Vladimir

On 12/11/2017 05:35 PM, Vladimir Vassilev wrote:

Hello,

I've reviewed this document and believe it is ready for publication.

The focus of my review this time was on validating the module and the 
example modules and example data through running code. I implemented 
NMDA for the open source tools we use and added a testcase that 
reproduces the result specified in "Appendix E. Example: NETCONF 
 Reply" after loading the configuration specified in 
"Appendix D.  Example: NETCONF  Reply" and providing the 
config false; data and system originated configuration as needed. I 
can confirm the implementation validated the example modules and the 
example data producing identical output.


IMO the examples are demonstrating well the concept of NMDA and its 
application for the ietf-interfaces module.


I had an issue with a bug in ietf-netconf-datasto...@2017-08-24.yang I 
had to fix in order to use the  RPC. The bug is already 
reported on the mailing-list.


diff ietf-patched/ietf-netconf-datasto...@2017-08-24.yang 
ietf-draft/ietf-netconf-datasto...@2017-08-24.yang

140c140
< when 'derived-from-or-self(../datastore, "ds:operational")';
---

    when 'derived-from-or-self(../datastore, "or:operational")';


Vladimir


On 11/28/2017 08:29 PM, Kent Watsen wrote:

All,

This starts a two-week working group last call on
draft-ietf-netmod-rfc7277bis-00.

Please recall that this update's intention is to
modify the YANG module to be in line with the NMDA
guidelines [1].  Reviewing the diff between the two
drafts [2] should reveal just this.

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

[1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
[2] 
https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7277bis-00.txt


Thank you,
Netmod Chairs

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


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


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

Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis

[Vladimir Vassilev]

On 12/11/2017 05:15 PM, Juergen Schoenwaelder wrote:

I do not fully understand why you think it is worth to preserve the
old YANG module library structure. Clearly, it won't be backwards
compatible since an NMDA implementation may list modules that are not
implemented in all datastores and an old client talking to a new
server will thus misunderstand what is exposed via the old YANG module
library structure. Your proposal "looks" backwards compatible but it
is not if one takes a closer look.

One can start making changes to say the conformance-type but then this
does not solve the problem since an old client does not know what a
new conformance type value means. The design team did look into the
option of keeping the old structure unchanged some weeks ago and we
finally arrived at the conclusion that it gets (i) ugly and (ii) does
not really provide backwards compatibility for a client written agains
the old YANG module library structure.

Note that with the new proposals on the table, it should be possible
to provide a backwards compatible view on YANG library for systems
that implement the exact same module set (with the exact same set of
features and deviations) on all datastores they support. But for
systems where this is not true, it seems better to use new
definitions instead of tweaking semantics.

Perhaps it helps if you can clearly phrase the objective of keeping
the old structure. What is the goal you want to achieve with that?
I prefer to call it the current structure for now. I will try to 
explain. My goal is to efficiently build transactional systems based on 
YANG models and open standards.


For this I need some reusable bricks. Such a brick is the rfc7895 
ietf-yang-libraray module. Even in a system with multiple YANG model 
contexts eventually processing breaks down to a single model context 
e.g. for example a YANG data validation task performed in a command line 
application comes down to:

 $ yang-data-validator yang-library-data.xml data.xml

The command can be called multiple times for different data and 
different contexts but it is the same very well tested simple tool. So 
my point is why can we not use one of the 2 newly introduced methods for 
instantiating this very well designed model for the needs of NMDA.


1. Use datastore for instantiation.
2. Use schema mount to mount rfc 7895 ietf-yang-library in the 
ietf-datastores list. (an alternative I assume is especially applicable 
to modules like ietf-yang-library that are self-contained)


In general having a solution that is flexible can easily be trimmed 
down. Adding special cases that are less flexible e.g. the 
(not-implemented-in leaf-list or none at all for the case of fully 
transactional systems with a single model context (no extra work for 
these)). The advantage is that even with the not-implemented-in 
leaf-list solution or other diff based the data processing tasks will 
eventually convert the differential information to a data structure 
implementing the rfc7895 ietf-yang-library data tree and the 
yang-data-validator application will be backward compatible and 
reusable. With changes that introduce a whole new level of abstraction 
in place of the simple list with module name and revision as keys one 
can't even reuse the groupings defined in that module and that is a 
problem I try to avoid.


Vladimir



/js

On Mon, Dec 11, 2017 at 04:53:30PM +0100, Vladimir Vassilev wrote:

On 12/11/2017 12:16 PM, Robert Wilton wrote:


Hi Vladimir,


On 09/12/2017 11:49, Vladimir Vassilev wrote:

On 12/08/2017 07:01 PM, Andy Bierman wrote:


Hi,

A library per datastore sounds too complicated.

I am not proposing that.

I'm slightly lost, because I thought that was exactly what you were
proposing! ;-)

I propose a solution that keeps ietf-yang-library a data model of a single
YANG context specification doing the datastore specific modeling in
ietf-datastores model instead. The solution can be both flexible
(independent yang-library data instances per datastore as my example was
focused on) or constrained ('not-implemented-in' modules leaf-list). Here is
everything that is needed:

module: ietf-datastores
     +--ro datastores-state
    +--ro datastore* [name]
    +--ro (model)?
   +--:(same-as-operational)
   +--:(constrained-to-operational)
   |  +--ro not-implemented-in*   ->
/yanglib:module-state/module/name
   +--:(unconstrained)
  +--ro yang-library-datastore?   identityref

YANG:
...
container datastores-state {
     config false;
     list datastore {
   key name;
     }
     choice model {
     case same-as-operational {
     }
     case constrained-to-operational {
   leaf-list not-implemented-in {
     type leafref {
   path "/yanglib:module-state/yanglib:module/yanglib:name";
     }
   }
     }
     case unconstrained {
   leaf yang-library-datast

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7277bis-00

[Vladimir Vassilev]

Hello,

I've reviewed this document and believe it is ready for publication.

The focus of my review this time was on validating the module and the example modules and example data through 
running code. I implemented NMDA for the open source tools we use and added a testcase that reproduces the 
result specified in "Appendix E. Example: NETCONF  Reply" after loading the 
configuration specified in "Appendix D.  Example: NETCONF  Reply" and providing the 
config false; data and system originated configuration as needed. I can confirm the implementation validated 
the example modules and the example data producing identical output.

IMO the examples are demonstrating well the concept of NMDA and its application 
for the ietf-interfaces module.

I had an issue with a bug in ietf-netconf-datasto...@2017-08-24.yang I had to fix in 
order to use the  RPC. The bug is already reported on the 
mailing-list.

diff ietf-patched/ietf-netconf-datasto...@2017-08-24.yang 
ietf-draft/ietf-netconf-datasto...@2017-08-24.yang
140c140
< when 'derived-from-or-self(../datastore, "ds:operational")';
---

when 'derived-from-or-self(../datastore, "or:operational")';


Vladimir


On 11/28/2017 08:29 PM, Kent Watsen wrote:

All,

This starts a two-week working group last call on
draft-ietf-netmod-rfc7277bis-00.

Please recall that this update's intention is to
modify the YANG module to be in line with the NMDA
guidelines [1].  Reviewing the diff between the two
drafts [2] should reveal just this.

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

[1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
[2] https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7277bis-00.txt

Thank you,
Netmod Chairs

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


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

Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis

[Vladimir Vassilev]

On 12/11/2017 12:16 PM, Robert Wilton wrote:


Hi Vladimir,


On 09/12/2017 11:49, Vladimir Vassilev wrote:

On 12/08/2017 07:01 PM, Andy Bierman wrote:


Hi,

A library per datastore sounds too complicated.

I am not proposing that.
I'm slightly lost, because I thought that was exactly what you were 
proposing! ;-)
I propose a solution that keeps ietf-yang-library a data model of a 
single YANG context specification doing the datastore specific modeling 
in ietf-datastores model instead. The solution can be both flexible 
(independent yang-library data instances per datastore as my example was 
focused on) or constrained ('not-implemented-in' modules leaf-list). 
Here is everything that is needed:


module: ietf-datastores
    +--ro datastores-state
   +--ro datastore* [name]
   +--ro (model)?
  +--:(same-as-operational)
  +--:(constrained-to-operational)
  |  +--ro not-implemented-in*   -> 
/yanglib:module-state/module/name

  +--:(unconstrained)
 +--ro yang-library-datastore?   identityref

YANG:
...
container datastores-state {
    config false;
    list datastore {
  key name;
    }
    choice model {
    case same-as-operational {
    }
    case constrained-to-operational {
  leaf-list not-implemented-in {
    type leafref {
  path "/yanglib:module-state/yanglib:module/yanglib:name";
    }
  }
    }
    case unconstrained {
  leaf yang-library-datastore {
    type identityref {
  base ds:datastore;
  }
    }
  }
    }
  }
...

IMO ietf-yang-library as defined in rfc7895 is modular and reusable. I 
do not see why this has to be compromised.


The fundamental point proposed is that the datastore relevant bits 
are kept in the ietf-datastores module instead of merging everything 
in a new ietf-yang-library entangled monster module. If needed 
ietf-datastores can augment ietf-yang-library but ietf-yang-library 
should be usable on its own without ietf-datastores. The solution is 
coherent and modular and addresses the problem statement.


The issue with this is that datastore augmentations to YANG library 
would end up changing the meaning of the existing YANG library nodes.  
E.g. an old client that ignores the datastore augmentations is going 
to get a nasty surprise when the server does not behave how it 
expects.  E.g. because the configuration node that it thinks should be 
there isn't there because it only supported in .


This was one of the reasons for changing YANG library.
A well written client that finds out unsupported newer versions of 
ietf-yang-library (which is reported in the capabilities) or any of the 
NMDA modules is deployed should not do any damage. How exactly did you 
solve the problem for the bad clients by changing the structure of 
yang-library in a incompatible way is something I do not understand.


In terms of the idea of just re-using YANG library but export a 
separate copy for each datastore I think that this has its own problems:
- I don't like the idea of returning meta-data along with 
configuration for a  on any of the configuration datastores.
There is no meta data. The datastores contain only the config false; 
/modules-state tree. I think I explained that very clearly.
- How does a client know whether the YANG library for  
applies to the whole server (as it does today) vs just applies to the 
 datastore (as it would for an NMDA server)?

All datastore models are "case same-as-operational" for such systems.
- It requires more handshaking between the client and server to get 
the schema, since a separate request would be required for each 
datastore that is supported.
Correct. Flexibility and modularity come at a price. IMO modularity is 
more important in this case. And there are solutions for the problem 
e.g. send all  requests before waiting for replies. NETCONF 
supports this.


So, for me, I think that the only way that this solution works, would 
be to define a new  RPC, but even then I think 
that it would make sense to combine the data together into a new YANG 
library structure.
As I said my focus is on keeping ietf-yang-library modular (single YANG 
model context).  or just adding datastore 
identities allowing the client to use  to achieve the 
retrieval of the data is of little importance to me.




At the end of the day, I don't think that a new YANG library is going 
to be were the real cost for supporting NMDA comes from.  I think that 
the real work is supporting  independently from  
both in the client and servers. But I also think that once servers 
start implementing this properly that it will simplify automation, 
because rather than a client having to guess what state a server is 
in, it can actually querey, or be notified of it, without having to 
write a lot of model specific code.

+1

Vladimir


Thanks,
Rob



I prefer the proposal that was made at th

Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis

[Vladimir Vassilev]

On 12/08/2017 07:01 PM, Andy Bierman wrote:


Hi,

A library per datastore sounds too complicated.

I am not proposing that.

The fundamental point proposed is that the datastore relevant bits are 
kept in the ietf-datastores module instead of merging everything in a 
new ietf-yang-library entangled monster module. If needed 
ietf-datastores can augment ietf-yang-library but ietf-yang-library 
should be usable on its own without ietf-datastores. The solution is 
coherent and modular and addresses the problem statement.

I prefer the proposal that was made at the IETF meeting that had
a 'not-implemented-in' leaf-list and a single module list.
This constraint is already specified in the text of the revised 
datastores draft. Clients conforming to the draft can expect servers to 
comply with the MUST requirement even if there is a separate 
yang-library data tree for each datastore the constraint of 
configuration stores mapping to 'operational' should be enforced 
according to the draft. There is no contradiction here.


That said I would be also be OK with ietf-datastores augmenting 
ietf-yang-library with such a leaf-list ('not-implemented-in' leaf-list) 
as a more constrained flavor of the same approach instead of going for 
independent copies of yang-library data. For any of that to happen 
change in ietf-datastores.yang is needed and change in the original 
rfc7895 ietf-yang-library is not needed at all.


Vladimir



Why is it interesting to have a separate module list for regular 
modules and imported modules?

I prefer to keep the conformance leaf and not change the module list.

NMDA needs to be possible to implement with a single schema tree such 
that a module
is implemented in all datastores, or a subset of all datastores.  
Otherwise it probably won't

get supported in clients.


Andy



On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen <kwat...@juniper.net 
<mailto:kwat...@juniper.net>> wrote:


CC-ing NETCONF, where the draft is being worked on.

Kent


On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote:
> On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote:
> >
> > Yes. The default value for yang-library-datastore leaf is
ds:operational
> > (the only possible one for the ds:operational datastore). This
is backward
> > compatible. If one needs different model for 'running', etc.
then a new
> > datastore identity has to be defined  and set in place of the
default value.
> > Then this identity can be used to read the yang-library data with
> > .
> >
>
> Sorry, but I have to ask this: How do I obtain the schema for the
> datastore (lets call it ) that reports the
schema for
> ? Is there another  datastore?
Will
> the recursion end? Perhaps it does since 
> might have itself listed as the schema defining datastore. I guess
> Lada will like these kind of meta and meta-meta datastores.

Not really. Metadata needn't be in datastores.

Lada

>
> /js
>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
netmod mailing list
netmod@ietf.org <mailto:netmod@ietf.org>

https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE=I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8=

<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod=DwICAg=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE=I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8=>


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




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


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

Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis

[Vladimir Vassilev]

On 11/15/2017 06:29 PM, Robert Wilton wrote:

I don't think that this is really a good idea.  You would end up 
returning server metadata in addition to the configuration.
Obviously RFC 7895 defines only config false; data and I was not 
proposing a change to that. But I agree something has to be added to 
complete the solution. Special purpose datastore identities can be 
defined that return instance of yang-library data when read with 
. (Datastores with yang-library config false; only data not 
represented in 'operational')


Adding this special yang-library-datastore to the proposed 
ietf-datastores container e.g.


module: ietf-datastores
+--ro datastores
|  +--ro datastore* [name]
| +--ro name  identityref
| +--ro yang-library-datastore  identityref

Notifications can indicate which yang-library-datastore is their origin 
(adding optional parameter in ietf-datastores through augmentation to 
the notifications in ietf-yang-library).




I still think that the YANG library proposal is the best solution.
The solution I propose has an obvious advantage for all designing 
systems that use single model for operational and the configuration 
datastores in terms of keeping the already implemented model and full 
backward compatibility without maintaining the obsolete /modules-state 
container in addition to any of the 3 proposals with additional 
indirection layers added. I am not sure if there are any disadvantages 
for the rest but I would like to read some arguments.


Vladimir


Thanks,
Rob


On 16/11/2017 01:21, Vladimir Vassilev wrote:

Hello,

I have a proposal based on  that provides an elegant 
solution to consider as a 3rd option.  It is based on keeping exactly 
the same model as in RFC 7895 and using  RPC to retrieve 
datastore specific yang-library instance data in a similar way one 
would use  to retrieve the datastore contents. In addition 
a top level config=false container e.g. /datastores with list of 
supported datastores that does not need to be part of the 
yang-library module:


module: ietf-datastores
+--ro datastores
|  +--ro datastore* [name]
| +--ro name  identityref

Vladimir

On 11/09/2017 05:51 PM, Robert Wilton wrote:


Hi,

Given some of the feedback related to the complexity of the YANG 
library bis structure, we have come up with two other possible 
structures for the YANG library data:


(1) A simplified structure to make YANG library meet the NMDA 
requirements, but that is closer to the existing YANG library 
structure, and arguably simpler.
(2) An enhanced version of the structure (1) above, that is also 
extended to allow the structure to be reused for schema-mount via an 
augmentation.


For reference, at the end of this email, I have also included the 
tree diagram of the existing YANG library, and the current YANG 
library bis draft (draft-ietf-netconf-rfc7895bis-02) version.


Considering the two new YANG library structures:



*(1) A simplified structure to make YANG library meet the NMDA 
requirements, but that is closer to the existing YANG library 
structure.*


The main changes are:
(i) Split "implemented modules" and "import-only-modules" into two 
separate lists, making the most important list (i.e. implemented 
modules) keyed by module name only and hence easier to reference.
(ii) Assume modules are implemented in all datastores by default 
(with a "not-implemented-in" leaflist of datastores that a module is 
not implemented in).
(iii) Assume that features are implemented in all datastores by 
default (with a "not-implemented-in" leaflist of datastores that a 
feature is not implemented in).

(iv) Deleted module-sets.
(v) Datastores are now just a list of supported datastores (that 
could potentially be extended with further per datastore properties 
in future).


Manually generated tree output for proposed YANG library:

module: ietf-yang-library
 +--ro yang-library
    +--ro modules
    |  +--ro module* [name]
    |  |  +--ro name   yang:yang-identifier
    |  |  +--ro revision?  revision-identifier
    |  |  +--ro schema?    inet:uri
    |  |  +--ro namespace  inet:uri
    |  |  +--ro submodule* [name]
    |  |  |  +--ro name    yang:yang-identifier
    |  |  |  +--ro revision?   yang:yang-identifier
    |  |  |  +--ro schema? inet:uri
    |  |  +--ro not-implemented-in*
    |  |  |  -> /yang-library/datastore/name
    |  |  +--ro feature* [name]
    |  |  |  +--ro name    yang:yang-identifier
    |  |  |  +--ro not-implemented-in*
    |  |  |  -> /yang-library/datastore/name
    |  |  +--ro deviation*
    |  | -> ../name
    |  |
    |  +--ro import-only-module* [name revision]
    | +--ro name yang:yang-identifier
    | +--ro revision    union
    | +--ro schema? inet:uri
    | +--ro namespace   inet:uri
    | +--ro submodule

Re: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00

[Vladimir Vassilev]

On 12/05/2017 10:06 PM, Eric Voit (evoit) wrote:


Hi Martin,

Several comments on the YANG model within rfc7223bis.

list interface {
 key "name";
 description
   "The list of interfaces on the device.  The status of an interface 
is available in this list in the
operational state...

A few questions on this.
(a) The description of the list defines behaviors of various list nodes which 
might or might not exist in different NMDA datastores.  It also suggests when 
certain elements should be populated in various datastores.  Is the precedence 
being set that datastore specific behaviors may be placed into descriptions?  
Is this type of documentation guidance something which explored in 
draft-dsdt-nmda-guidelines?
(b) Does status mean 'admin-status', 'oper-status' or both?  (I think 
'oper-status'.)
(c) should quotes be used around status?

leaf name {,   leaf type { 
There are NETCONF specific behaviors in the definition of these two leaves.   
It would be great to have this transport agnostic.  I realize that such a 
transport segmentation dissociates transport error handling from the nodes 
being handled.

leaf admin-status {...
incorrectly marked  as config false;
I think config false; is correct. The 'admin-status' leaf is a pre-NMDA 
workaround for IF-MIB implementations that coexist with the 
ietf-interfaces implementation e.g. reflect the value of ifAdminStatus 
independently configurable of the /interfaces/interface/enabled value. 
This is described in the description statement of 
/interfaces/interface/enabled.


This potentially could also be accomplished by using NMDA origin meta 
notation in operational showing /interfaces/interface/enabled is 
overwritten by origin that is not 'intended' e.g. or:origin=or:system or 
maybe custom origin or:origin=or-snmp:snmp?


IMO 'admin-status' is a too broad name for something that is only if-mib 
relevant. This is an example of something that can be solved with NMDA 
in a more general way without clogging the model with additional leaf 
but for backward compatibility and to avoid unnecessary confusion should 
be kept the way it is in draft-ietf-netmod-rfc7223bis-00.


Vladimir



Thanks,
Eric



-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Kent Watsen
发送时间: 2017年11月29日 3:29
收件人: netmod@ietf.org
抄送: netmod-cha...@ietf.org
主题: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00

All,

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

rfc7223bis-00.

Please recall that this update's intention is to modify the YANG module to

be in line with the NMDA guidelines [1].  Reviewing the diff between the
two drafts [2] should reveal just this.

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

[1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
[2]
https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7223bis-00.tx
t

Thank you,
Netmod Chairs


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

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

___
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] [Netconf] Alternative YANG library structure for 7895bis

[Vladimir Vassilev]

Hello,

I have a proposal based on  that provides an elegant solution 
to consider as a 3rd option.  It is based on keeping exactly the same 
model as in RFC 7895 and using  RPC to retrieve datastore 
specific yang-library instance data in a similar way one would use 
 to retrieve the datastore contents. In addition a top level 
config=false container e.g. /datastores with list of supported 
datastores that does not need to be part of the yang-library module:


module: ietf-datastores
+--ro datastores
|  +--ro datastore* [name]
| +--ro name  identityref

Vladimir

On 11/09/2017 05:51 PM, Robert Wilton wrote:


Hi,

Given some of the feedback related to the complexity of the YANG 
library bis structure, we have come up with two other possible 
structures for the YANG library data:


(1) A simplified structure to make YANG library meet the NMDA 
requirements, but that is closer to the existing YANG library 
structure, and arguably simpler.
(2) An enhanced version of the structure (1) above, that is also 
extended to allow the structure to be reused for schema-mount via an 
augmentation.


For reference, at the end of this email, I have also included the tree 
diagram of the existing YANG library, and the current YANG library bis 
draft (draft-ietf-netconf-rfc7895bis-02) version.


Considering the two new YANG library structures:



*(1) A simplified structure to make YANG library meet the NMDA 
requirements, but that is closer to the existing YANG library structure.*


The main changes are:
(i) Split "implemented modules" and "import-only-modules" into two 
separate lists, making the most important list (i.e. implemented 
modules) keyed by module name only and hence easier to reference.
(ii) Assume modules are implemented in all datastores by default (with 
a "not-implemented-in" leaflist of datastores that a module is not 
implemented in).
(iii) Assume that features are implemented in all datastores by 
default (with a "not-implemented-in" leaflist of datastores that a 
feature is not implemented in).

(iv) Deleted module-sets.
(v) Datastores are now just a list of supported datastores (that could 
potentially be extended with further per datastore properties in future).


Manually generated tree output for proposed YANG library:

module: ietf-yang-library
 +--ro yang-library
    +--ro modules
    |  +--ro module* [name]
    |  |  +--ro name   yang:yang-identifier
    |  |  +--ro revision?  revision-identifier
    |  |  +--ro schema?    inet:uri
    |  |  +--ro namespace  inet:uri
    |  |  +--ro submodule* [name]
    |  |  |  +--ro name    yang:yang-identifier
    |  |  |  +--ro revision?   yang:yang-identifier
    |  |  |  +--ro schema? inet:uri
    |  |  +--ro not-implemented-in*
    |  |  |  -> /yang-library/datastore/name
    |  |  +--ro feature* [name]
    |  |  |  +--ro name    yang:yang-identifier
    |  |  |  +--ro not-implemented-in*
    |  |  |  -> /yang-library/datastore/name
    |  |  +--ro deviation*
    |  | -> ../name
    |  |
    |  +--ro import-only-module* [name revision]
    | +--ro name yang:yang-identifier
    | +--ro revision    union
    | +--ro schema? inet:uri
    | +--ro namespace   inet:uri
    | +--ro submodule* [name]
    |    +--ro name    yang:yang-identifier
    |    +--ro revision    yang:revision-identifier
    |    +--ro schema? inet:uri
    +--ro datastore* [name] // Allows future per datastore properties.
    |  +--ro name  identityref
    +--ro checksum   string

--

*(2) An enhanced version of the structure (1) above, that is extended 
to allow the structure to be reused for schema-mount via an augmentation.*


This is similar to the structure above, except that the "the set of 
modules" is contained in a list of named schema (e.g. similar to the 
schema mount draft), allowing this structure to be re-used for schema 
mount.


Schema mount would be expected to augment yang-library to add in the 
additional schema mount information.  In the tree diagram, I have 
shown the schema-mount mount-point augmentation, but not including 
namespaces yet.


Every server would be required to provide at least one schema in the 
schema list, and the primary schema for the device would always be 
given the name "primary".


module: ietf-yang-library
 +--ro yang-library
    +--ro schema* [name]
    |  +--ro name   string
    |  +--ro checksum   string
    |  +--ro module* [name]
    |  |  +--ro name   yang:yang-identifier
    |  |  +--ro revision?  yang:revision-identifier
    |  |  +--ro schema?    inet:uri
    |  |  +--ro namespace  inet:uri
    |  |  +--ro submodule* [name]
    |  |  |  +--ro name    yang:yang-identifier
    |  |  |  +--ro revision?   yang:yang-identifier
    |  |  |  +--ro schema? inet:uri
    |  |  +--ro 

Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis

[Vladimir Vassilev]

On 11/15/2017 11:42 AM, Robert Wilton wrote:



On 15/11/2017 10:41, Vladimir Vassilev wrote:



On 11/15/2017 01:06 AM, Robert Wilton wrote:



On 14/11/2017 23:41, Vladimir Vassilev wrote:



On 11/13/2017 04:27 PM, Robert Wilton wrote:


Hi Vladimir,


On 12/11/2017 10:39, Vladimir Vassilev wrote:




On 11/11/2017 08:07 PM, Andy Bierman wrote:



On Fri, Nov 10, 2017 at 3:06 AM, Robert Wilton 
<rwil...@cisco.com <mailto:rwil...@cisco.com>> wrote:


    Hi Andy,

    The NMDA datastore draft
    (draft-ietf-netmod-revised-datastores-06) mandates two
    constraints that must apply:

    (1) All conventional datastores must have exactly the same
    schema.  Hence differences in deviations or features are 
allowed

    between these datastores. (sec 5.1, first paragraph)

    (2) The schema for operational must be a superset of all
    configuration datatstores, but that data nodes may be omitted
    (sec 5.3, third paragraph).


    This implies that only the following differences between
    datastores are allowed:
     (i) a feature can be disabled in conventional (and/or dynamic
    configuration datastores), but enabled in operational (e.g. for
    configurable router-id).

     (ii) deviations apply in all datastores, except that
      a) a deviation can remove nodes in the conventional 
datastores

    (if they were not configurable, like the feature example)
      b) a deviation can remove nodes in a dynamic datastore (e.g.
    like I2RS)
      c) a deviation can remove nodes from operational only if a
    server is unable to accurately report them.

    (iii) modules exist in all datastores, except:
      a) a module can be omitted from conventional datastores (e.g.
    if the module is not configurable)
      b) a module can be omitted from a dynamic datastore (e.g. 
like

    I2RS)
      c) a module can be omitted from operational only if a server
    is unable to accurately report the data nodes within the 
module.




I am not convinced that moving to a datastore-centric 
conformance model instead of server-centric

is a good idea.

+1
IMO yang-library:1.1 can and should be optional. As a first step 
NMDA modules and the minimal protocol support  etc. can 
be implemented without yang-library 1.0 to 1.1 transition (read 
server-centric to datastore-centric conformance model 
transition). draft-ietf-netconf-nmda-netconf-01.txt requires 
migration to yang-library:1.1. I do not see good argument to 
support this limitation and there are usecases that can benefit 
from NMDA with uniform datastore model design.


YANG library bis is the mechanism to indicate which datastores are 
available to the client.  E.g. a NMDA compatible client would 
attempt to read YANG library bis on the new path using the 
 RPC to determine whether NMDA is supported, and what 
datastores are supported.


The existing module-state path in YANG library is preserved, but 
marked as deprecated, so the intention is that it can be made 
backwards compatible to clients.
I agree draft-ietf-netconf-nmda-netconf-01 sec. 2.4. 'YANG Library 
Capability'  states exactly that. IMO this text can be changed and 
allow the case described above ( implementation with NMDA 
modules implemented as indicated by yang-library:1.0 uniform model 
applying to all datastores. For cases where the datastores do not 
have common model yang-library:1.1 should still be mandatory). In 
other words if yang-library:1.0 shows implemented 
ietf-netconf-datastores  and NMDA modules listed as 
implemented will not need yang-library:1.1 implementation which 
takes one obstacle out of the way to rolling NMDA module 
implementations.


Is there an argument making the proposed change unreasonable?

Yes, I think so.

In an NMDA implementation, the YANG library information reported in 
the new structure can be entirely accurate.  I.e. it can report 
which modules are available in which datastores.


Of course, it is not possible to represent this in the old YANG 
library, so the information that a NMDA server provides via the old 
YANG library could be inaccurate.  I.e. I think that it has to 
report all modules and deviations as being reported in all datastores.


Hence the only way that a client would be able to know that it is 
talking to an NMDA server with modules not implemented in some 
datastores, or with deviations in some datastores would be for it to 
query the new YANG library path.  The new YANG library structures 
that we are proposing below are intended to be easier for a client 
to determine this, e.g. by checking whether any of the 
"not-implemented-in" leaf-lists are populated.


So the aim for keeping the old YANG library path is to inter-operate 
with old clients that don't know about NMDA, and hence would not be 
expected to use the  or  RPCs.


Thanks,
Rob
I still do not see an argument against supporting  NMDA modules with 
yang-library:1.0 in the case when and only when there are no 
deviations and the implemented m

Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis

[Vladimir Vassilev]

On 11/15/2017 01:06 AM, Robert Wilton wrote:



On 14/11/2017 23:41, Vladimir Vassilev wrote:



On 11/13/2017 04:27 PM, Robert Wilton wrote:


Hi Vladimir,


On 12/11/2017 10:39, Vladimir Vassilev wrote:




On 11/11/2017 08:07 PM, Andy Bierman wrote:



On Fri, Nov 10, 2017 at 3:06 AM, Robert Wilton <rwil...@cisco.com 
<mailto:rwil...@cisco.com>> wrote:


    Hi Andy,

    The NMDA datastore draft
    (draft-ietf-netmod-revised-datastores-06) mandates two
    constraints that must apply:

    (1) All conventional datastores must have exactly the same
    schema.  Hence differences in deviations or features are allowed
    between these datastores. (sec 5.1, first paragraph)

    (2) The schema for operational must be a superset of all
    configuration datatstores, but that data nodes may be omitted
    (sec 5.3, third paragraph).


    This implies that only the following differences between
    datastores are allowed:
     (i) a feature can be disabled in conventional (and/or dynamic
    configuration datastores), but enabled in operational (e.g. for
    configurable router-id).

     (ii) deviations apply in all datastores, except that
      a) a deviation can remove nodes in the conventional datastores
    (if they were not configurable, like the feature example)
      b) a deviation can remove nodes in a dynamic datastore (e.g.
    like I2RS)
      c) a deviation can remove nodes from operational only if a
    server is unable to accurately report them.

    (iii) modules exist in all datastores, except:
      a) a module can be omitted from conventional datastores (e.g.
    if the module is not configurable)
      b) a module can be omitted from a dynamic datastore (e.g. like
    I2RS)
      c) a module can be omitted from operational only if a server
    is unable to accurately report the data nodes within the module.



I am not convinced that moving to a datastore-centric conformance 
model instead of server-centric

is a good idea.

+1
IMO yang-library:1.1 can and should be optional. As a first step 
NMDA modules and the minimal protocol support  etc. can 
be implemented without yang-library 1.0 to 1.1 transition (read 
server-centric to datastore-centric conformance model transition). 
draft-ietf-netconf-nmda-netconf-01.txt requires migration to 
yang-library:1.1. I do not see good argument to support this 
limitation and there are usecases that can benefit from NMDA with 
uniform datastore model design.


YANG library bis is the mechanism to indicate which datastores are 
available to the client.  E.g. a NMDA compatible client would 
attempt to read YANG library bis on the new path using the 
 RPC to determine whether NMDA is supported, and what 
datastores are supported.


The existing module-state path in YANG library is preserved, but 
marked as deprecated, so the intention is that it can be made 
backwards compatible to clients.
I agree draft-ietf-netconf-nmda-netconf-01 sec. 2.4. 'YANG Library 
Capability'  states exactly that. IMO this text can be changed and 
allow the case described above ( implementation with NMDA 
modules implemented as indicated by yang-library:1.0 uniform model 
applying to all datastores. For cases where the datastores do not 
have common model yang-library:1.1 should still be mandatory). In 
other words if yang-library:1.0 shows implemented 
ietf-netconf-datastores  and NMDA modules listed as 
implemented will not need yang-library:1.1 implementation which takes 
one obstacle out of the way to rolling NMDA module implementations.


Is there an argument making the proposed change unreasonable?

Yes, I think so.

In an NMDA implementation, the YANG library information reported in 
the new structure can be entirely accurate.  I.e. it can report which 
modules are available in which datastores.


Of course, it is not possible to represent this in the old YANG 
library, so the information that a NMDA server provides via the old 
YANG library could be inaccurate.  I.e. I think that it has to report 
all modules and deviations as being reported in all datastores.


Hence the only way that a client would be able to know that it is 
talking to an NMDA server with modules not implemented in some 
datastores, or with deviations in some datastores would be for it to 
query the new YANG library path.  The new YANG library structures that 
we are proposing below are intended to be easier for a client to 
determine this, e.g. by checking whether any of the 
"not-implemented-in" leaf-lists are populated.


So the aim for keeping the old YANG library path is to inter-operate 
with old clients that don't know about NMDA, and hence would not be 
expected to use the  or  RPCs.


Thanks,
Rob
I still do not see an argument against supporting  NMDA modules with 
yang-library:1.0 in the case when and only when there are no deviations 
and the implemented module sets are exactly identical for all datastores.





Vladimir



Thanks,
Rob

 I get it that i

[netmod] validation of draft-ietf-netconf-nmda-netconf-01

[Vladimir Vassilev]

Hello,

There is a validation error reported for 
ietf-netconf-datasto...@2017-08-24.yang:


Error: XPath expression 'derived-from-or-self(../datastore, 
"or:operational")' with invalid identity param 'or:operational'
ietf-netconf-datasto...@2017-08-24.yang:140.63: error(348): invalid 
XPath expression syntax


Vladimir


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

Re: [netmod] review of draft-acee-netmod-rfc8022bis-05

[Vladimir Vassilev]

On 11/03/2017 05:49 PM, Acee Lindem (acee) wrote:

Hi Vladimir,

Thanks for comments - see inline.

On 10/29/17, 8:43 PM, "netmod on behalf of Vladimir Vassilev"
<netmod-boun...@ietf.org on behalf of vladi...@transpacket.com> wrote:


Hello,

I have reviewed draft-acee-netmod-rfc8022bis-05. My conclusion is that
the YANG modules part of the draft have been successfully modified in
accordance with sec. '4.23.3 NMDA Transition Guidelines' of
draft-ietf-netmod-rfc6087bis-14. The modifications are coherent with the
ietf-interfa...@2017-08-17.yang module in
draft-ietf-netmod-rfc7277bis-00 and ietf...@2017-08-21.yang module in
draft-ietf-netmod-rfc7277bis-00.

Vladimir


Review of draft-acee-netmod-rfc8022bis-05.
Vladimir Vassilev
2017-10-30

'Abstract':
'Introduction 1':
  - Both Abstract and Sec 1. contain duplicated text which can be removed

>from Abstract. The text in Sec 1. can be simplified:

OLD:
This version of these YANG modules uses new names for these YANG
models.  The main difference from the first version is that this
version fully conforms to the Network Management Datastore
Architecture (NMDA).  Consequently, this document obsoletes RFC 8022.
NEW:
This version of the Routing Management data model supports the Network
Management Datastore Architecture (NMDA)
[I-D.ietf-netmod-revised-datastores].

The Abstract and Introduction sections are independent and the information
is pertinent to both.



'7.  Routing Management YANG Module':

  - Why should address-family identity be different e.g. mandatory
"false"; for system created RIBs? I think this needs some explanation
(Page 21):
...
uses address-family {
  description
"Address family of the RIB.

 It is mandatory for user-controlled RIBs.  For
 system-controlled RIBs it can be omitted; otherwise, it
 must match the address family of the corresponding state
 entry.";
  refine "address-family" {
mandatory "false";
  }
}
...

I will discuss this with my co-authors.

  - Suggested change of 'base address-family;' -> 'base
rt:address-family;' for identity ipv4 and ipv6 (ref.
draft-ietf-netmod-rfc6087bis-14#section-4.2):

 o The local module prefix MUST be used instead of no prefix in
 all "default" statements for an "identityref" or
"instance-identifier"
 data type

I added “rt:” where it was missing to the identityref statements. This
will be in the next revision.
I made this one sound credible but later noticed I quoted irrelevant 
text from draft-ietf-netmod-rfc6087bis-14 ('default' is not 'base'). And 
the text in RFC7950 '5.4.  Resolving Grouping, Type, and Identity Names' 
states that static scoping applies to identifiers in type statements 
which overrules 7.13 'The "uses" statement'.


My bad. The change is redundant.

'8.  IPv4 Unicast Routing Management YANG Module'
(ietf-ipv4-unicast-rout...@2017-10-14.yang):
'9.  IPv6 Unicast Routing Management YANG Module'
(ietf-ipv6-unicast-rout...@2017-10-14.yang):


  - The ietf-ipv4-unicast-routing and ietf-ipv6-unicast-routing modules
import the ietf-routing without revision (ref. rfc6087#section-4.6):


 o The revision-date substatement within the imports statement SHOULD
be
 present if any groupings are used from the external module."

Since these modules are all in the same draft, I’d rather leave out the
revision date as it is cleaner without it. Let me discuss with my
co-authors.


'Appendix D. Data Tree Example':

  - The example in the Appendix D. has not been updated and it must be
extended in order to demonstrate a usecase of operational datastore of
configuration data with different origin (intended, system, etc.)
similar to the 'Appendix C. Example Data' of
draft-ietf-netmod-revised-datastores-05.

Actually, none of the examples accessed operational state date in RFC
8022. However, I agree that this should be added and we’ll work on it.


Nits:
  - s/Figures 1/Figure 1/
  - s/systemindependently/system independently/

Thanks for catching - I fixed these in the -01 version of
draft-ietf-netmod-rfc8022bis-01.txt.

Thanks,
Acee

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


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

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

[Vladimir Vassilev]

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

Hi,

Jan Kundrát  wrote:

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

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

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

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

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

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

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

+1

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



/martin





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

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

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

With kind regards,
Jan

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


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


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

[netmod] review of draft-acee-netmod-rfc8022bis-05

[Vladimir Vassilev]

Hello,

I have reviewed draft-acee-netmod-rfc8022bis-05. My conclusion is that 
the YANG modules part of the draft have been successfully modified in 
accordance with sec. '4.23.3 NMDA Transition Guidelines' of 
draft-ietf-netmod-rfc6087bis-14. The modifications are coherent with the 
ietf-interfa...@2017-08-17.yang module in 
draft-ietf-netmod-rfc7277bis-00 and ietf...@2017-08-21.yang module in 
draft-ietf-netmod-rfc7277bis-00.


Vladimir


Review of draft-acee-netmod-rfc8022bis-05.
Vladimir Vassilev
2017-10-30

'Abstract':
'Introduction 1':
 - Both Abstract and Sec 1. contain duplicated text which can be removed
from Abstract. The text in Sec 1. can be simplified:

OLD:
   This version of these YANG modules uses new names for these YANG
   models.  The main difference from the first version is that this
   version fully conforms to the Network Management Datastore
   Architecture (NMDA).  Consequently, this document obsoletes RFC 8022.
NEW:
   This version of the Routing Management data model supports the Network
   Management Datastore Architecture (NMDA) 
[I-D.ietf-netmod-revised-datastores].



'7.  Routing Management YANG Module':

 - Why should address-family identity be different e.g. mandatory 
"false"; for system created RIBs? I think this needs some explanation 
(Page 21):

   ...
   uses address-family {
 description
   "Address family of the RIB.

It is mandatory for user-controlled RIBs.  For
system-controlled RIBs it can be omitted; otherwise, it
must match the address family of the corresponding state
entry.";
 refine "address-family" {
   mandatory "false";
 }
   }
   ...

 - Suggested change of 'base address-family;' -> 'base 
rt:address-family;' for identity ipv4 and ipv6 (ref. 
draft-ietf-netmod-rfc6087bis-14#section-4.2):


o The local module prefix MUST be used instead of no prefix in
all "default" statements for an "identityref" or "instance-identifier"
data type

'8.  IPv4 Unicast Routing Management YANG Module' 
(ietf-ipv4-unicast-rout...@2017-10-14.yang):
'9.  IPv6 Unicast Routing Management YANG Module' 
(ietf-ipv6-unicast-rout...@2017-10-14.yang):



 - The ietf-ipv4-unicast-routing and ietf-ipv6-unicast-routing modules 
import the ietf-routing without revision (ref. rfc6087#section-4.6):



o The revision-date substatement within the imports statement SHOULD be
present if any groupings are used from the external module."


'Appendix D. Data Tree Example':

 - The example in the Appendix D. has not been updated and it must be 
extended in order to demonstrate a usecase of operational datastore of 
configuration data with different origin (intended, system, etc.) 
similar to the 'Appendix C. Example Data' of 
draft-ietf-netmod-revised-datastores-05.



Nits:
 - s/Figures 1/Figure 1/
 - s/systemindependently/system independently/

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

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

[Vladimir Vassilev]

On 10/24/2017 07:06 PM, Andy Bierman wrote:




On Tue, Oct 24, 2017 at 5:27 AM, Vladimir Vassilev 
<vladi...@transpacket.com <mailto:vladi...@transpacket.com>> wrote:


On 10/24/2017 03:42 AM, Andy Bierman wrote:



On Mon, Oct 23, 2017 at 4:57 AM, Vladimir Vassilev
<vladi...@transpacket.com <mailto:vladi...@transpacket.com>
<mailto:vladi...@transpacket.com
<mailto:vladi...@transpacket.com>>> wrote:

On 10/23/2017 01:35 PM, Martin Bjorklund wrote:

Vladimir Vassilev <vladi...@transpacket.com
<mailto:vladi...@transpacket.com>
<mailto:vladi...@transpacket.com
<mailto:vladi...@transpacket.com>>> wrote:

Hello,

I would like to use the occasion of this Errata
report to
point out
some additional issues with the
instance-identifier type
definition.

IMO the instance-identifier built-in type has 2
additional
problems
that can be addressed with alternative and
significantly
more radical
errata or fixed in a new version of YANG.:

Problem 1: The obvious limitation inherited from
Xpath 1.0
- inability
to escape single or double quote characters. In Xpath
world this
limitation is worked around by use of concat()
which is
not available
in the YANG 1.1 instance-identifier definition. 2
examples
of this
limitation:

1. It is impossible to create value of type
instance-identifier
referencing nodes in lists with key string values
containing both a
single and a double quote characters e.g.
..."It's
valid string!".

2. Another example of the same problem would be a
leaf of type
instance-identifier referencing another leaf of type
instance-identifier. With 2 references it works
provided
one is
encoded with single quotes and the other with
double but it is
impossible to create third e.g.

YANG:

 list id-list {
   key "id";

   leaf id {
   type instance-identifier;
   }
 }




Although the instance-identifier is problematic, it is rarely
used at all,
let alone using it as a list key.

It is used as a key in ietf-alarms /alarms/alarm-list/alarm.


The XPath mixed-quotes problem is well-known, and the suggested
solution seems to be use the "concat" function

   /foo/bar[name=concat("It's a", ' "valiid" string')]

Not very user friendly, is it?

I think people naming their interfaces "It's a valid string!" can
take it. Prettier escaping solutions are available e.g. C string
but it will require more work then a line in the next YANG version
RFC. IMO solution is needed either concat or an alternative one.

Practical reason: YANG 1.1 can not create instance-identifier to
the alarm /alarms/alarm-list/alarm[...
resource="/interfaces/interface[name='eth0']"]. And this is not
the "That's a valid string!" named interface. The "That's a valid
string!" interface alarms can not be reported as a valid
ietf-alarms instance-identifier based resource alarm at all.




Actually the XPath designers made a reasonable trade-off by using 
concat as the solution to
a problem that rarely happens.   It is up to the IETF to define YANG 
in a way that does

not ignore the XPath solutions.
Yes. How about some proper rules mandating th use of quotes and concat 
like: 1. Only allow use of double quotes when there is single quote 
present. 2. Only use concat when there is both single and double quotes 
present to split the string into 1 char single quote strings and the rest.


Then  /foo/bar[name=concat('It',"'",'s a valid string!"')] is the only 
possible canonic representation for all implementations and the solution 
is solving the rare problem without reinventing the wheel.


Vladimir



Andy





Data:

* /top/id-list[id="/top/list[idx='4']"]

*
/top/id-list[id="/top/id-list[idx='/top/list[idx=4]'"]


  

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

[Vladimir Vassilev]

On 10/24/2017 03:42 AM, Andy Bierman wrote:




On Mon, Oct 23, 2017 at 4:57 AM, Vladimir Vassilev 
<vladi...@transpacket.com <mailto:vladi...@transpacket.com>> wrote:


On 10/23/2017 01:35 PM, Martin Bjorklund wrote:

    Vladimir Vassilev <vladi...@transpacket.com
<mailto:vladi...@transpacket.com>> wrote:

Hello,

I would like to use the occasion of this Errata report to
point out
some additional issues with the instance-identifier type
definition.

IMO the instance-identifier built-in type has 2 additional
problems
that can be addressed with alternative and significantly
more radical
errata or fixed in a new version of YANG.:

Problem 1: The obvious limitation inherited from Xpath 1.0
- inability
to escape single or double quote characters. In Xpath
world this
limitation is worked around by use of concat() which is
not available
in the YANG 1.1 instance-identifier definition. 2 examples
of this
limitation:

1. It is impossible to create value of type
instance-identifier
referencing nodes in lists with key string values
containing both a
single and a double quote characters e.g.
..."It's
valid string!".

2. Another example of the same problem would be a leaf of type
instance-identifier referencing another leaf of type
instance-identifier. With 2 references it works provided
one is
encoded with single quotes and the other with double but it is
impossible to create third e.g.

YANG:

 list id-list {
   key "id";

   leaf id {
   type instance-identifier;
   }
 }




Although the instance-identifier is problematic, it is rarely used at all,
let alone using it as a list key.

It is used as a key in ietf-alarms /alarms/alarm-list/alarm.


The XPath mixed-quotes problem is well-known, and the suggested
solution seems to be use the "concat" function

   /foo/bar[name=concat("It's a", ' "valiid" string')]

Not very user friendly, is it?
I think people naming their interfaces "It's a valid string!" can take 
it. Prettier escaping solutions are available e.g. C string but it will 
require more work then a line in the next YANG version RFC. IMO solution 
is needed either concat or an alternative one.


Practical reason: YANG 1.1 can not create instance-identifier to the 
alarm /alarms/alarm-list/alarm[... 
resource="/interfaces/interface[name='eth0']"]. And this is not the 
"That's a valid string!" named interface. The "That's a valid string!" 
interface alarms can not be reported as a valid ietf-alarms 
instance-identifier based resource alarm at all.





Data:

* /top/id-list[id="/top/list[idx='4']"]

* /top/id-list[id="/top/id-list[idx='/top/list[idx=4]'"]


* 

Problem 2: The instance-identifier type lacks canonical
form (which
makes it the only data type with implementation dependent
representation at the data level ... think of the integer
types
allowing optional spaces between the digits). This is in
fact the only
built-in data type that allows the server implementation
to change the
configuration data replacing double quotes with single or
the other
way around. Inserting white spaces where you did not have
them when
the configuration was submitted. You can not simply read a
configuration and use fast data comparison without schema
support just
because of this type. This is useless flexibility for
simple data
type.

And this can be fixed if:

1. white spaces in instance-identifiers are prohibited


2. list key predicates are required in alphabetical order

Or perhaps use the order the keys are defined in the data
model (the
"keys" statement").

This is an option but then the e.g. xpath2instid() function
implementations will need schema support.



All the YANG tools I have seen generate the predicates in YANG key order.

Yes.

If Xpath came with a canonical form definition (prohibiting spaces, 
redundant duplication of namespace prefixes in children, order of 
predicates, canonical quotation rule, and some flexibility as of the 
node prefix semantics) we would not need to have this discussion. Seems 
no o

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

[Vladimir Vassilev]

Hello,

I would like to use the occasion of this Errata report to point out some 
additional issues with the instance-identifier type definition.


IMO the instance-identifier built-in type has 2 additional problems that 
can be addressed with alternative and significantly more radical errata 
or fixed in a new version of YANG.:


Problem 1: The obvious limitation inherited from Xpath 1.0 - inability 
to escape single or double quote characters. In Xpath world this 
limitation is worked around by use of concat() which is not available in 
the YANG 1.1 instance-identifier definition. 2 examples of this limitation:


1. It is impossible to create value of type instance-identifier 
referencing nodes in lists with key string values containing both a 
single and a double quote characters e.g. ..."It's 
valid string!".


2. Another example of the same problem would be a leaf of type 
instance-identifier referencing another leaf of type 
instance-identifier. With 2 references it works provided one is encoded 
with single quotes and the other with double but it is impossible to 
create third e.g.


YANG:

list id-list {
  key "id";

  leaf id {
  type instance-identifier;
  }
}

Data:

* /top/id-list[id="/top/list[idx='4']"]

* /top/id-list[id="/top/id-list[idx='/top/list[idx=4]'"] proposed errata is also in effect>


* 

Problem 2: The instance-identifier type lacks canonical form (which 
makes it the only data type with implementation dependent representation 
at the data level ... think of the integer types allowing optional 
spaces between the digits). This is in fact the only built-in data type 
that allows the server implementation to change the configuration data 
replacing double quotes with single or the other way around. Inserting 
white spaces where you did not have them when the configuration was 
submitted. You can not simply read a configuration and use fast data 
comparison without schema support just because of this type. This is 
useless flexibility for simple data type.


And this can be fixed if:

1. white spaces in instance-identifiers are prohibited

2. list key predicates are required in alphabetical order

3. strict quotation convention with escape option is added. (only 3. 
contradicts the sec. 9.13 ".. instance-identifier is a subset of the 
XPath ..")


Vladimir

On 10/21/2017 08:16 PM, Andy Bierman wrote:



On Sat, Oct 21, 2017 at 12:28 AM, Benoit Claise > wrote:


Dear all,

Shall I validate this one?



To add more context, this relates to the the RESTCONF JSON vs. XML
discussions in the NETCONF WG.

  leaf broken {
  type union {
type int32;
type string;
 }
  }

If all values of key leaf "broken" are sent as strings in an 
instance-identifier,
then the int32 value may not match in all implementations, instead of 
the string.
Allowing numbers as literals in addition to quoted strings allows the 
sender

to be specific, and all implementations to be consistent.


Regards, Benoit



Andy

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/eid5157


--
Type: Technical
Reported by: Andy Bierman >

Section: 14

Original Text
-
   key-predicate-expr  = node-identifier *WSP "=" *WSP
quoted-string

Corrected Text
--
   key-predicate-expr  = node-identifier *WSP "=" *WSP
 (quoted-string / integer-value / decimal-value)

Notes
-
An instance identifier is forced to specify every key value to
be a string
even though the YANG key leaf type could be a numeric type.
XPath does not require a quoted string here, just YANG.

Old:  /top/list[idx="4"]
New: /top/list[idx=4]

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  : NETCONF Data Modeling Language
Area: Operations and Management
 

Re: [netmod] Pattern statements [was Re: Query about augmenting module from submodule in YANG 1.0]

[Vladimir Vassilev]

On 08/21/2017 05:14 PM, Robert Wilton wrote:


Hi Acee,

That makes sense.

The other thing that I think that we have got wrong is modelling regex 
pattern statements.  I think that it would be much better if these 
were written to be less exhaustive and much simpler.


E.g. the "route distinguisher" pattern in 
draft-ietf-rtgwg-routing-types-09 is defined as this:


  pattern
'(0:(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
  + '6[0-4][0-9]{3}|'
  + '[0-5]?[0-9]{0,3}[0-9]):(429496729[0-5]|'
  + '42949672[0-8][0-9]|'
  + '4294967[01][0-9]{2}|429496[0-6][0-9]{3}|'
  + '42949[0-5][0-9]{4}|'
  + '4294[0-8][0-9]{5}|429[0-3][0-9]{6}|'
  + '42[0-8][0-9]{7}|4[01][0-9]{8}|'
  + '[0-3]?[0-9]{0,8}[0-9]))|'
  + '(1:((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|'
  + '25[0-5])\.){3}([0-9]|[1-9][0-9]|'
  + '1[0-9]{2}|2[0-4][0-9]|25[0-5])):(6553[0-5]|'
  + '655[0-2][0-9]|'
  + '65[0-4][0-9]{2}|6[0-4][0-9]{3}|'
  + '[0-5]?[0-9]{0,3}[0-9]))|'
  + '(2:(429496729[0-5]|42949672[0-8][0-9]|'
  + '4294967[01][0-9]{2}|'
  + '429496[0-6][0-9]{3}|42949[0-5][0-9]{4}|'
  + '4294[0-8][0-9]{5}|'
  + '429[0-3][0-9]{6}|42[0-8][0-9]{7}|4[01][0-9]{8}|'
  + '[0-3]?[0-9]{0,8}[0-9]):'
  + '(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
  + '6[0-4][0-9]{3}|'
  + '[0-5]?[0-9]{0,3}[0-9]))|'
  + '(6(:[a-fA-F0-9]{2}){6})|'
  + '(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):'
  + '[0-9a-fA-F]{1,12})';
}

But I think that it would be much easier to read, and quite possibly 
more performant to execute, if the pattern regex was written something 
like the following:


 pattern:
'(0:[0-9]{1,5}:[0-9]{1,10})|
 (1:([0-9]{1,3}\.){4}:[0-9]{1,5})|
 (2:[0-9]{1,10}:0:[0-9]{1,5})|
 (6(:[a-fA-F0-9]{2}){6})';

Of course, this would allow more invalid values, but most servers 
would be expected to reject those when it converts them into an 
internal binary format any way.


What do you, and others, think?
You still need the 
|(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):[0-9a-fA-F]{1,12}) in the 
end to not reject valid values though.


IMO a pattern statement has value if it absolutely defines the set of 
valid strings. In general I do not see the benefit of pattern statements 
that do not reject all invalid string instances. I prefer the original 
pattern or none at all.


Vladimir


Thanks,
Rob


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

Re: [netmod] Query about augmenting module from submodule in YANG 1.0

[Vladimir Vassilev]

Hello,

IMO "submodule"s  are a striking example of redundant complexity in an 
otherwise very close to perfection YANG (regardless if it is YANG 1.0 or 
1.1).


Modules and submodules have been around for a while however the ratio of 
the currently published modules compared with the submodules is about 40 
modules to 1 submodule (if one ignores all the modules and submodules 
from  particular networking hardware manufacturer that is particularly 
keen on using submodules). As a far but still relevant analogy Java has 
a limitation of 1 file per class and this atomicity has proven to be an 
advantage especially in terms of enforcing modularity. IMO there is 
nothing that can be done with the help of submodules that can not be 
done without them.


For the sake of the argument can you provide a synthesized description 
of the problem that lead you to a drastic solution like "we’ll look at 
trying to put everything into submodules in this case."?


Vladimir

On 08/07/2017 04:37 PM, Ivory, William wrote:


Hi Jan,

Thanks – we’ll look at trying to put everything into submodules in 
this case.


Regards,

William

*From:*Jan Lindblad [mailto:j...@tail-f.com]
*Sent:* 07 August 2017 14:28
*To:* Ivory, William 
*Cc:* netmod@ietf.org
*Subject:* Re: [netmod] Query about augmenting module from submodule 
in YANG 1.0


The submodule concept in YANG 1.0 is, well, not very useful, and even 
less intuitive. That's why it saw major rework in YANG 1.1.


A YANG 1.0 submodule cannot reference the module that includes it, 
directly or indirectly. This is because in YANG 1.0 the symbols in 
other submodules of the same namespace are invisible to the submodule 
unless they are explicitly included. And parent modules can't be 
included by a submodule because that would lead to an inclusion loop. 
It is possible to reference (augment, etc) other sibling submodules, 
though. So if you split your modules cleverly, you might be able to 
resolve your referential constraints anyway.


If you really want to take the submodule path, I'd recommend moving to 
YANG 1.1. In the interest of preserving the hair tone of IT-architects.


/jan

We’re trying to solve a modularity problem with a YANG module by
splitting it into submodules and augmenting the parent module from
each submodule.  However, despite the wording below in YANG 1.0
section 7.15, we’ve found a couple of threads online with comments
suggesting it’s only allowed in YANG 1.1?  Would appreciate
clarification.

RFC 6020 section 7.15 suggests it is allowed:

‘

   The "augment" statement allows a module or submodule to add to the

   schema tree defined in an external module, or the current
module and

   its submodules, and to add to the nodes from a grouping in a "uses"

   statement.

‘

Versus online comments
here:https://www.ietf.org/mail-archive/web/netmod/current/msg15418.html



‘> On 01 Mar 2016, at 10:38, Anton Tkáčik  
wrote:

>

> Hi,

> Noticed other issue with example set,

> Inhttps://github.com/mbj4668/pyang/issues/194


  Lada stated that in YANG 1.0 submodule can not augment nodes

> defined in parent model.

>

> Is that correct that submodule can not augment definition defined in 
parent module?

  


This isn't possible in YANG 1.0 but will be possible in 1.1. However, in 
the present case the definition being augmented from the submodule is arguably 
in a different module.

  


Lada

‘

Thanks,

William

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





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


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

Re: [netmod] I-D Action: draft-ietf-netmod-intf-ext-yang-05.txt

[Vladimir Vassilev]

Hello,

Our validation tools report a problem that was also reported for the 04 
version and still not fixed:


This is our fix:

diff draft-modules/ietf-flexible-encapsulat...@2017-07-03.yang 
ietf-flexible-encapsulat...@2017-07-03.yang

145,146c145,146
<   '../outer-tag/dot1q-tag/tag-type = "s-vlan" and ' +
<   'dot1q-tag/tag-type = "c-vlan"' {
---
>   '../outer-tag/dot1q-tag/tag-type = "dot1q-types:s-vlan" 
and ' +

>   'dot1q-tag/tag-type = "dot1q-types:c-vlan"' {
217,218c217,218
<   '../outer-tag/dot1q-tag/tag-type = "s-vlan" and ' +
<   'dot1q-tag/tag-type = "c-vlan"' {
---
>   '../outer-tag/dot1q-tag/tag-type = "dot1q-types:s-vlan" and ' +
>   'dot1q-tag/tag-type = "dot1q-types:c-vlan"' {
375,376c375,376
<   '../outer-tag/dot1q-tag/tag-type = "s-vlan" and ' +
<'dot1q-tag/tag-type = "c-vlan"' {
---
>   '../outer-tag/dot1q-tag/tag-type = "dot1q-types:s-vlan" 
and ' +

>'dot1q-tag/tag-type = "dot1q-types:c-vlan"' {

Vladimir


On 07/04/2017 12:02 AM, internet-dra...@ietf.org wrote:

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

 Title   : Common Interface Extension YANG Data Models
 Authors : Robert Wilton
   David Ball
   Tapraj Singh
   Selvakumar Sivaraj
Filename: draft-ietf-netmod-intf-ext-yang-05.txt
Pages   : 27
Date: 2017-07-03

Abstract:
This document defines two YANG modules that augment the Interfaces
data model defined in the "YANG Data Model for Interface Management"
with additional configuration and operational data nodes to support
common lower layer interface properties, such as interface MTU.
These properties are common to many types of interfaces on network
routers and switches and are implemented by multiple network
equipment vendors with similar semantics, even though some of the
features are not formally defined in any published standard.


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

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

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


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

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

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


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

Re: [netmod] draft-vallin-netmod-alarm-module status and plans

[Vladimir Vassilev]

Hi Kent,

I followed the CCAMP thread concluding with 
https://www.ietf.org/mail-archive/web/ccamp/current/msg18142.html and 
IMO there is consensus that the draft should be move back to netmod.


Vladimir


On 06/22/2017 03:02 PM, Kent Watsen wrote:

Hi William,

Please be aware that this draft is moving to the CCAMP WG.  I don't think the 
ccamp-version of the draft has been posted yet, but it will be discussed in 
that WG (and not NETMOD) in Prague.

Regards,
Kent



On Jun 22, 2017, at 6:25 AM, William Lupton  wrote:

Dear all,

We at the Broadband Forum (BBF) would like to reiterate our interest in the 
draft-vallin-netmod-alarm-module draft.

We will also have some technical comments / suggestions (internal discussion is 
ongoing) that we will share with NETMOD as soon as possible.

Thanks,
William


On 31 May 2017, at 13:08, Benoit Claise  wrote:

William,

This was discussed with the authors, the NETMOD chairs, and the RTG AD Deborah.
The advice was for the authors to raise the draft in ccamp and try to progress 
it there.

The authors updated their draft to version 2 and pinged the CCAMP mailing list 
(https://www.ietf.org/mail-archive/web/ccamp/current/msg18124.html).
 From that email thread, it seems there is interest in the work, but where to 
do the work is not clear.

My advice to the authors: continue progress this work and if CCAMP is not 
interested or consider this work too generic, bring it back to NETMOD and we'll 
follow normal WG process.

Regards, Benoit

All,

I heard from Kent that 
https://tools.ietf.org/html/draft-vallin-netmod-alarm-module was moving to 
CCAMP but I don’t see any mention of it at 
https://datatracker.ietf.org/wg/ccamp/documents (although it is shown as a 
dependency at https://datatracker.ietf.org/wg/ccamp/deps/svg). Is any more info 
available please?

Thanks,
William

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

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


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

Re: [netmod] I-D Action: draft-ietf-netmod-sub-intf-vlan-model-01.txt

[Vladimir Vassilev]

On 06/15/2017 06:18 PM, Robert Wilton wrote:


Hi Vladimir,

Thanks for raising this.


On 15/06/2017 12:59, Vladimir Vassilev wrote:

Hello,

There is a problem with a mutually exclusive 'when' statements for 
the /interfaces/inteface/encapsulation container in 
ietf-interfaces-com...@2017-03-13.yang 
(draft-ietf-netmod-intf-ext-yang-04) and 
ietf-if-l3-v...@2017-03-13.yang  models causing error with our 
validation tools.


As defined in ietf-interfaces-com...@2017-03-13.yang:

...

container encapsulation {
  when
"derived-from-or-self(../if:type,
  'ianaift:ethernetCsmacd') or
 derived-from-or-self(../if:type,
  'ianaift:ieee8023adLag') or
 derived-from-or-self(../if:type, 'ianaift:pos') or
 derived-from-or-self(../if:type,
  'ianaift:atmSubInterface') or
 derived-from-or-self(../if:type, 'ethSubInterface')" {

...

and here augmented in ietf-if-l3-v...@2017-03-13.yang:

  augment "/if:interfaces/if:interface/if-cmn:encapsulation/" +
  "if-cmn:encaps-type" {
when "../if:type = 'ianaift:l2vlan' and
  derived-from-or-self(../if-cmn:forwarding-mode,
   'if-cmn:network-layer')" {

Short term fix I use is to add "or derived-from-or-self(../if:type, 
'ianaift:l2vlan')" to the ietf-interfaces-common definition.

I suspect that probably the reverse fix is probably better.

I.e. add derived-from-or-self(../if:type, 'ethSubInterface' to the 
encapsulation when statement replacing the l2vlan, since 
ethSubInterface derived from l2vlan anyway.


Thanks,
Rob
The "TODO" text you have placed in 
ietf-interfaces-com...@2017-03-13.yang under the when statement "TODO - 
Should we introduce an abstract type to make this extensible to new 
interface types, or vendor specific interface types?" for me is a hint 
that a better long term solution is under consideration (replacing the 
list of technology specific references).


My understanding is that only the subset of all sub-interfaces based on 
encapsulation will have encapsulation container. Identity derived from 
sub-interface -> encapsulation-sub-interface could be the abstract type, 
right?


Examples of practical use of the sub-interface abstraction and 
/interfaces/interface/encapsulation for the most common cases (e.g. 
l2vlan bridge configuration) is something that should be presented. If 
not as part of the draft on the mailing list as proof of concept.


IMO ietf-flexible-encapsulat...@2017-03-13.yang and 
ietf-if-l3-v...@2017-03-13.yang along with the 
/interfaces/interface/encapsulation container definition can be merged 
into single module called ietf-sub-intf-vlan.yang where the 
encapsulation-sub-interface identity and the encapsulation container are 
defined.


Vladimir

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

Re: [netmod] I-D Action: draft-ietf-netmod-sub-intf-vlan-model-01.txt

[Vladimir Vassilev]

Hello,

There is a problem with a mutually exclusive 'when' statements for the 
/interfaces/inteface/encapsulation container in 
ietf-interfaces-com...@2017-03-13.yang 
(draft-ietf-netmod-intf-ext-yang-04) and 
ietf-if-l3-v...@2017-03-13.yang  models causing error with our 
validation tools.


As defined in ietf-interfaces-com...@2017-03-13.yang:

...

container encapsulation {
  when
"derived-from-or-self(../if:type,
  'ianaift:ethernetCsmacd') or
 derived-from-or-self(../if:type,
  'ianaift:ieee8023adLag') or
 derived-from-or-self(../if:type, 'ianaift:pos') or
 derived-from-or-self(../if:type,
  'ianaift:atmSubInterface') or
 derived-from-or-self(../if:type, 'ethSubInterface')" {

...

and here augmented in ietf-if-l3-v...@2017-03-13.yang:

  augment "/if:interfaces/if:interface/if-cmn:encapsulation/" +
  "if-cmn:encaps-type" {
when "../if:type = 'ianaift:l2vlan' and
  derived-from-or-self(../if-cmn:forwarding-mode,
   'if-cmn:network-layer')" {

Short term fix I use is to add "or derived-from-or-self(../if:type, 
'ianaift:l2vlan')" to the ietf-interfaces-common definition.



Vladimir


On 03/13/2017 08:38 PM, internet-dra...@ietf.org wrote:

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

 Title   : Sub-interface VLAN YANG Data Models
 Authors : Robert Wilton
   David Ball
   Tapraj Singh
   Selvakumar Sivaraj
Filename: draft-ietf-netmod-sub-intf-vlan-model-01.txt
Pages   : 27
Date: 2017-03-13

Abstract:
This document defines YANG modules to add support for classifying
traffic received on interfaces as Ethernet/VLAN framed packets to
sub-interfaces based on the fields available in the Ethernet/VLAN
frame headers.  These modules allow configuration of Layer 3 and
Layer 2 sub-interfaces (e.g. attachment circuits) that can
interoperate with IETF based forwarding protocols; such as IP and
L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN.  The
sub-interfaces also interoperate with VLAN tagged traffic orginating
from an IEEE 802.1Q compliant bridge.  Primarily the classification
is based on VLAN identifiers in the 802.1Q VLAN tags, but the model
also has support for matching on some other layer 2 frame header
fields and is designed to be extensible to match on other arbitrary
header fields.

The model differs from an IEEE 802.1Q bridge model in that the
configuration is interface/sub-interface based as opposed to being
based on membership of an 802.1Q VLAN bridge.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-sub-intf-vlan-model-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


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

Re: [netmod] Question on intefaces-state model

[Vladimir Vassilev]

Hello,

On 06/14/2017 01:18 PM, Bogaert, Bart (Nokia - BE/Antwerp) wrote:

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



I agree that the statistics counter leafs as defined in ietf-interfaces 
are optional except the discontinuity-time ("mandatory true;") leaf. You 
were right it makes the entire /interfaces-state/interface/statistics 
container mandatory even if none of the optional counters are implemented.


The context of the example was the statement by Andy who seemed to 
differ on the counters being optional. I was not sure what he ment and 
added an example of device not implementing some of the counters without 
breaking conformity with ietf-interfaces:


On 06/13/2017 11:15 AM, Vladimir Vassilev wrote:
On 06/12/2017 08:31 PM, Andy Bierman wrote: an  must 
contain an instance of the mandatory leaf.
The mandatory-stmt is very confusing for config=false nodes. 
Mandatory=true means

Mandatory=false does not mean optional-to-implement although it sure
looks that way for config=false nodes.  Only if-feature can make a 
node optional to implement.
If we take serial interface with hardware that only has in-octets and 
out-octets counters I would expect to only find these two in 
/interfaces-state/interface/statistics +  discontinuity-time. Do you 
say the rest of the counters must be present (e.g. allways 0) for 
proper implementation of ietf-interfaces? 


That said you probably also agree that a model with optional leafs is 
equivalent to an employment contract where the monthly salary is 
optional. State data models should avoid the entropy of allowing 
implementations to either implement or not leafs without this being 
formal conformance deviation (this being especially valid for basic 
counters part of the base ietf model like ietf-interfaces). That causes 
greater waste of not only engineering time but runtime traffic as well. 
Management applications have to be designed to poll the leafs and make 
conditional decisions for each instance and handle missing leafs to 
conform to the model.


For example an option to do automated validation of all point to point 
links in a topology (by checking counters at source and destination 
ports - out-unicast-pkts=in-unicast-pkts ... etc.). All the devices 
implement the required capability - ietf-interfaces but some do not 
return out-unicast-pkts, out-broadcast-pkts, out-multicast-pkts since 
the hardware only provides them with out-total-pkts and in-total-pkts 
(not part of ietf-interfaces model).



With that example in mind I have another relevant question:

Is there consensus that this is valid YANG 1.1 and with a mandatory 
counters defined like that the stated conformance actually brings some 
guarantees the required counter will be implemented:


...

yang-version 1.1;

...

   augment "/if:interfaces-state/if:interface/if:statistics" {
leaf in-total-pkts {
  mandatory true;
  type yang:counter64;
}
leaf out-total-pkts {
  mandatory true;
  type yang:counter64;
}

}

...

pyang does not like that ("cannot augment with mandatory node 
in-total-pkts") and I think it should be valid to add mandatory true 
counter leafs to /interfaces-state/interface/statistics


Vladimir

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

Re: [netmod] Question on intefaces-state model

[Vladimir Vassilev]

On 06/12/2017 08:31 PM, Andy Bierman wrote:




On Mon, Jun 12, 2017 at 10:21 AM, Juergen Schoenwaelder 
> wrote:


On Fri, Jun 09, 2017 at 10:55:20AM +, Bogaert, Bart (Nokia -
BE/Antwerp) wrote:
>
> 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.
>

The alternative which we use is to not have 
/interfaces-state/interface/statistics container for the interfaces 
without counters. The container is mandatory=false.



The discontinuity-time is relevant for _any_ counter associated with
an interface, regardless whether the counter is defined in the
interfaces model or elsewhere. I have a hard time to imagine an
interface that has zero counters.

There are some though. Optical amplifiers and similar equipment that 
does not have counters - the status data is only signal levels.


The mandatory-stmt is very confusing for config=false nodes. 
Mandatory=true means

an  must contain an instance of the mandatory leaf.

Mandatory=false does not mean optional-to-implement although it sure
looks that way for config=false nodes.  Only if-feature can make a 
node optional to implement.
If we take serial interface with hardware that only has in-octets and 
out-octets counters I would expect to only find these two in 
/interfaces-state/interface/statistics +  discontinuity-time. Do you say 
the rest of the counters must be present (e.g. allways 0) for proper 
implementation of ietf-interfaces?


Vladimir




/js


Andy

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

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





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


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

Re: [netmod] YANG doctor review of draft-ietf-netmod-intf-ext-yang-04

[Vladimir Vassilev]

Hello,

On 04/06/2017 07:43 PM, Andy Bierman wrote:


3) identity ethSubInterface

This identity is used in the encapsulation container when-stmt.
It is not clear if this is intended as a base identity (like identity 
sub-interface)

An example for the encapsulation container would help clarify the
expected usage

This also has 2 bases (sub-interface and l2vlan).
Some explanation in the identity-stmt would be helpful
(since this is a new YANG 1.1 construct)
It seems the intentended result was identity similar to 
ianaift:atmSubInterface (thus the naming convention change 
ethSubInterface instead of eth-sub-interface). I think it is less 
confusing to name the identity with the same naming convention used for 
the rest of the identities introduced e.g. sub-interface, 
loopback-internal etc. and if needed define new atm-sub-interface based 
on sub-interface. I am not sure even atm users would like a model where 
atmSubInterface will be the only identity of all future sub interface 
based identities not being derived from sub-interface because of this 
precedent:


 augment "/if:interfaces/if:interface" {
   when "derived-from(if:type,
  'ietf-if-cmn',
  'sub-interface') or
 if:type = 'ianaift:atmSubInterface' or
 if:type = 'ianaift:frameRelay'"  {

Vladimir



Andy



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

Re: [netmod] Modelling different "levels" of data in YANG

[Vladimir Vassilev]

Hi,

Here is a summary of the proposed solutions so far:

* The solution with introduction of YANG statement "diagnostics true;", 
additional datastore and NETCONF protocol change. IMO that sounds heavy 
but valid solution.
* The solution with RPC returning the data as output. IMO has the 
limitation of not presenting the diagnostics data in the data tree (no 
valid instance-identifiers to be used in notifications). But is the 
simplest to have in place.

* The solution with RPC enabling the containers only for a certain session.

I thought also of this alternative solution:  The solution is to avoid 
clobbering the replies to s without filter or s with filter 
matching only parent nodes of the "diagnostics state" container data  
and not return those nodes in the reply except in the cases the filter 
matches data nodes part of the diagnostics data explicitly.


Example for /interfaces-state/interfaces/diagnostics (using xpath filter 
for brevity but valid for the "subtree" case):


These skip "diagnostics":



These return "diagnostics":

select="/interfaces-state/interface/diagnostics"\>



This looks like a violation of RFC 6241 6.2.5 bullet 12 but IMO the 
container is non-mandatory diagnostics data so returning it only when 
someone really wants it and not otherwise is the definition of the 
solution to the problem.


/Vladimir

On 12/12/2016 05:47 PM, Kent Watsen wrote:


Hi Robert,

You’re right, it should’ve been the  (not ).   
However, I think that it’s better to use a flag on the 
 datastore, rather than to define a new datastore.  
Not only would it mimic how with-defaults works, but it also seems 
more intuitive from a retrieval perspective, as the diagnostics nodes 
could be sprinkled throughout a data model, and a single  
could return all nodes (not just the diagnostics) for a given 
subtree.Thoughts?


Separately, from a modelling perspective, presumably there would have 
to be an additional flag to go with the config false flag, something 
like the below.  Is this what you were envisioning?


container thermostat {

leaf configured-temperature {

type int8;

}

leaf current-temperature {

config false;

type int8;

}

container diagnostics {

config false;

diagnostics true;<-- new flag here

...

}

Is all this leading up to a draft?  ;)

Kent  // contributor

*From: *Robert Wilton 
*Date: *Monday, December 12, 2016 at 6:10 AM
*To: *Kent Watsen , Andy Bierman 
*Cc: *"netmod@ietf.org" 
*Subject: *Re: [netmod] Modelling different "levels" of data in YANG

Hi Kent,

On 10/12/2016 00:59, Kent Watsen wrote:

> I prefer not to use specialized  operations.

Agreed, I was thinking something more along the lines of:

   

  

 

  

<--- note this flag here

  

 http://example.com/schema/1.2/config;
>



  



 

  

   

Thus explicitly requesting all the extra stuff get returned...

Yes, that is roughly along the lines that I was thinking.

Or building on draft-nmdsdt-netmod-revised-datastores:
- presuming the existing of a  operation to generically 
return the contents of any datastore,
- defining a new  datastore that contains the contents of 
the  along with all config false schema nodes 
labelled as "diagnostics true".


   

  

 

  

  



  


Thanks,
Rob



> In the usage model that Rob described, the service tech will be

> setting diag-mode to 'system'  then retrieving the extra
'diag-stats',

>then setting diag-mode back to 'user'.

Right, but this does not seem ideal as the diag-mode toggle is a
global setting that would affect all clients for some window of
time, or do we envision diag-mode dropping the system down to
single-user mode?

Kent  // contributor



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

Re: [netmod] Modelling different "levels" of data in YANG

[Vladimir Vassilev]

On 12/06/2016 10:03 PM, Alex Campbell wrote:

IMO using an action or rpc is an okay solution for now, certainly 
better than than not including the data at all.


If I have to chose between RPC with 'output' containing the state data 
for selected interface and mapping the data to a container/list not 
under /interfaces-state (e.g. another top level container) I prefer the 
second option since notifications and data models in general can refer 
to it as part of the data tree. It allows for simpler monitoring and 
implementation of alarms etc.



Perhaps in the future the client could specify which YANG modules it 
cares about, in addition to a subtree filter. Then you could put the 
extended diagnostic information into another module (using "augment"), 
and clients that don't know about the extended diagnostic information 
wouldn't request it, and clients that do would know to only request it 
when they need it.
One can use xpath 1.0 filter. This option is already available. Example 
 RPC retrieving only state data of interest.


...
  
select="//*[namespace-uri()='urn:ietf:params:xml:ns:yang:ietf-interfaces' 
or namespace-uri()='urn:ietf:params:xml:ns:yang:ietf-system']"/>

  
...

Sane server implementations will skip the time consuming calbacks 
retrieving detailed data defined in other modules then ietf-intefaces 
and ietf-system.


/Vladimir

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

Re: [netmod] Modelling different "levels" of data in YANG

[Vladimir Vassilev]

On 12/06/2016 10:40 PM, Juergen Schoenwaelder wrote:


I fear that a dumb client sending a  without a proper filter to
select the data that is relevant for the client will not necessarily
get smarter by defining additional operations.

Sometimes access control can help to control dumb clients that try to
get everything (and then ignore most of the data they receive); simply
make sure that only the information is accessible to a client that is
actually needed by a client. In other words, the filtering logic does
not have to be hard coded in the data model.

+1

One additional solution for consideration is a new top level 
config=false container with a list e.g. 
/ethernet-interfaces-state/ethernet-interface/... where the key is 
leafref to /interfaces-state/interface/name With this solution IMO all 
requirements mentioned in the discussion so far are satisfied without 
the need to introduce any RPCs or hard coding filtering logic in the model.


/Vladimir



/js


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

Re: [netmod] Modelling different "levels" of data in YANG

[Vladimir Vassilev]

On 12/05/2016 07:10 PM, Robert Wilton wrote:


Hi,

We are currently working on modelling 802.3 Ethernet YANG within the 
802.3 YANG study group.


One interesting issue that has come up is the scope of the operational 
state data that could be modeled:


At the top level, an operator may just want to know whether an 
Ethernet interface is up or down.


At a second level, if the Ethernet interface is down, then there is 
some high level diagnostics information that may be useful to an 
operator to diagnose why the interface isn't up (e.g. alarms 
information, optical power levels, auto-negotiation protocol status).


There is also a third level, of very detailed, 802.3 hardware register 
information defined in 802.3 Clause 45.  Such information is probably 
of most relevance to the engineers developing and programming Ethernet 
chips and PHYs, but is sometimes useful for resolving potential vendor 
inter-operation issues.  Retrieving this information out of the 
Ethernet chips can be comparatively slow.


The question that was being discussed is whether it is appropriate to 
model all three levels on information in the 802.3 Ethernet YANG 
models, or whether only the top level and second level information 
can/should be modeled via YANG?


If we were to model the third level information in YANG then it would 
seem highly desirable for that information to not be returned in 
response to a general NETCONF  request because the information 
is generally not of relevance and has potential performance issues in 
returning it.  Instead, it would seem desirable to only return this 
data if it was specifically requested (e.g. a  request on the 
node containing the third level information), or if a hypothetical 
filter extension was specified and used to explicitly include it in 
the response. Given that there doesn't seem to a great way to 
currently achieve this in YANG, this makes me think that it isn't 
sensible to model this third level of detailed information in YANG at 
this time.  Do others agree?


Have others faced similar issues, and if so, how have you solved them?
How about having this state data reside under a config=true presence 
container e.g. /interfaces/interface/ethernet-detailed-state... . The 
user can then create the container for the interfaces he is interested 
in reading the detailed state data.


Or have dedicated RPC in the model that enables/disables the presence of 
the detailed state information for certain interfaces. Since the state 
container is not mandatory.


In any case a grouping with the 802.3 Clause 45 information data will 
definitely be usefull.


/Vladimir


Input welcome.  Thanks,
Rob


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

Re: [netmod] How to prevent a client from modifying the type of an interface?

[Vladimir Vassilev]

On 11/29/2016 05:18 PM, Jan Lindblad wrote:


Bart,

Jürgen et al are of course right in what they say, but if you really 
want to use YANG to enable a manager to know a priori what values are 
possible for a particular leaf somewhere, that's easy too -- if you 
see the addition of a new proprietary YANG module as a possibility.


module device-limitations {
...
  container limitations {
must 
"not(/if:interfaces/if:interface[not(if:type='ianaift:fastdsl')])" {
  error-message "There must not be any interfaces that are not of 
fastdsl interface type";

}
  }
}
+1. We use the same approach for defining device specific limitations in 
YANG.


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

Re: [netmod] New Version Notification for draft-vallin-netmod-alarm-module-00.txt

[Vladimir Vassilev]

Hi,

I also reviewed the ietf-alarms model. We are interested and intend to 
implement it replacing our proprietary model.


The model is flexible and covers all alarms scenarios we support.

IMO the operator and shelving functionality can potentially be moved to 
additional module augmenting a simpler ietf-alarms.yang allowing 
possible alternative models.


As I understand Alex he would like to see some solution adding some 
determinism by pairing known "resource" and 
{alarm-type-id,alarm-type-qualifier} tuples. This can be done in 
additional model since I see it as an additional feature not necessary 
to be part of the core ietf-alarms.yang and I see nothing preventing 
such additional model to be built on top of the current ietf-alarms.yang


Vladimir


On 10/11/2016 09:18 AM, stefan vallin wrote:

Hi!

Alex, see inline on your comments.
Another thing, you had  an earlier comment:
"I would like to see a YANG feature for past status changes, or perhaps this 
part moved to a separate module augmenting ietf-alarms.”
Just to make sure I get your comment correctly.
Are you saying that you would like the alarm/status-change list to be a YANG feature 
to indicate “optionality"

list status-change {
   if-feature alarm-status-changes;  <
   key time;

Alex Campbell  wrote:

Hi,

alarm-list holds a list of raised and cleared alarms (but not those
that have never been raised).
alarm-inventory holds a list of all possible alarm _types_.
If alarm-inventory were to hold a list of all possible alarms, that
would indeed resolve my concern. (It would be equivalent to our
all-alarms list)

But this only works for devices where you can (statically?) enumerate
*all* resources that possibly could be in an alarm state!  This does
not seem very scalable to me.  Or did I miss something in your
descripition?


But other things than entities can have alarms. AND
instance-identifers are not “free-form”. It is a strange limitation to
limit alarms to the entity-model

I agree; however, it has the nice effects that it is possible to
enumerate all resources

So, we could consider the alarm-inventory to have an additional leaf “resource”.
I think that would resolve your issue?
Of course not all systems know that, but for those that do, this helps a lot, I 
agree.
I see that go well with another relevant comment you had that the 
alarm-inventory should have
a requirement that it needs to be updated when new cards are inserted for 
example.
We might even add a notif for alarm-inventory changes.


On 11 Oct 2016, at 08:42, Martin Bjorklund  wrote:

See above.


and also that the resources and their
associated alarms form a hierarchy which can be visually displayed -
an operator can expand a tree to get progressively more detail on the
device status.
The top level of the tree shows "device has problems"; the next level
shows "line card 3 has problems"; the next level shows "Interface 3/2
has problems"; the next level shows "Interface 3/2 has no media".
However, I think the concepts of root cause resources and impacted
resources are more useful than this hierarchy.

Why wouldn't this be possible with the model we propose?

I think you are talking about a very useful application in the management 
system.
This does not mean the exact same view need to available in the alarm interface.




/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] 'when' statement in edit-config payload parsing

[Vladimir Vassilev]

On 09/13/2016 06:48 PM, Andy Bierman wrote:

Hi,

I am not in favor of changing when-stmt so it works like must-stmt.
I prefer it work as designed.  It is like choice-stmt, where a new case
will cause objects from the previously selected case to be 
automatically deleted.


There is no text in RFC 7950 that actually says an error is returned
if a when-stmt is false because an anyxml or anydata input parameter
was converted to top-level YANG nodes and reprocessed.

The text only covers direct when-stmts like below:

   rpc plot-point {
  input {
leaf point-type {
  type enumeration {
  enum 2d;
  enum 3d;
  }
  mandatory true;
}
leaf X { type int32; mandatory true; }
leaf Y { type int32; mandatory true; }
leaf Z {
   when "../point-type = '3d';
   mandatory true;
   type int32;
   }
 }
   }


If the client sets point-type to '2d' and provides a Z leaf, then an 
error is returned.

This is the only type of usage the text in question actually covers.
It is  RPC that has started the thread (the 'when' 
validation in  is much clearer and I agree with all you say 
above). There was the original example by Yves (changed when "A" to when 
"../A"):


  container root {
leaf A {
  type empty:
}
leaf B {
  when "../A";
  type uint32;
}
  }
... and the netconf :

 
   
 
   
 
 
   http://dummy.com;>
 
 
   3
 
   
 
   
 

There is consensus the 'when' statement is satisfied in this case which 
answers his original question.


However if we make change to the original example by assuming the target 
is not 'running' but 'candidate' and /root/A is already present before 
the following  is processed:


 
   
 
   
 
 
   http://dummy.com;>
 
   3
 
   
 
   
 

My interpretation of the relevant text in YANG 1.0 and YANG 1.1 is the 
'when' statement is satisfied since when the  is applied to 
the 'candidate' configuration the result will be valid 'candidate' 
configuration state and this is what matters. If there is consensus on 
that I have nothing to add.


Vladimir





Andy


On Tue, Sep 13, 2016 at 4:43 AM, Vladimir Vassilev 
<vladi...@transpacket.com <mailto:vladi...@transpacket.com>> wrote:


On 09/13/2016 01:26 PM, Juergen Schoenwaelder wrote:

    On Tue, Sep 13, 2016 at 01:19:02PM +0200, Vladimir Vassilev wrote:

I am wondering in which cases this is useful. Consider
a candidate
datastore - why would a 'when' expression have to true
after each
edit? Why do we force clients to send edits in such a
way that 'when'
expressions are true after each edit?

For example command line  completion in
/interfaces/interface can
evaluate all 'when' statements in child data nodes and
augmentations and
come up with relevant list of container and leaf child
completions based on
the already created /interfaces/interface/type (same
applies for the options
a user is presented with in a GUI after specifying the
'name' and 'type' of
the interface). It is the same with 'if-feature'
evaluations. The 'must'
statements however can be more complicated since they are
only checked when
the interactive incremental edit process is complete and
 is
attempted.

I do not see what  completion has to do with the
processing of
edit-config on the server. Are people implementing 
completion by
sending edit-configs to a server? But yes, trying to enforce
constraints while doing  completion may lead to surprises for
people not understanding the constraints being enforced via
incremental  completion.

Well it means that the 'candidate' configuration can not be in a
state where any of the 'when' statements fail (since it is
modified only with ). This is significant reduction
of the entropy and thus can be utilized for automation. In my
example that fact is used for  completion.

Vladimir

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




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

Re: [netmod] 'when' statement in edit-config payload parsing

[Vladimir Vassilev]

On 09/13/2016 10:25 AM, Juergen Schoenwaelder wrote:

On Tue, Sep 13, 2016 at 09:34:33AM +0200, Ladislav Lhotka wrote:

On 13 Sep 2016, at 09:01, Yves Beauville  wrote:

Both RFC 6020 and RFC 7950 are providing the same requirement in section 
'Payload Parsing':
   o  If data for a node tagged with "when" is present, and the "when" condition evaluates to 
"false", the server MUST reply with an "unknown-element" error-tag in the rpc-error.

This section seems confusing. It makes no sense to evaluate "when" or "must" on the 
contents of a protocol message such as edit-config because accessible trees for XPath evaluations are defined 
in sec. 6.4.1 in terms of datastores and "all state data".


I agree that this bullet in section 8.3.1 looks odd. Perhaps Martin
recalls why this was written in the first place?

/js


IMO it is that bullet that sets apart 'when' from 'must' statements. 
With the current text 'when' statements should be evaluated along with 
'range',..., 'if-feature' etc. 8.3.1 specified validation statements 
upon every  while 'must' statements should be evaluated 
only upon  along with the rest of "description" statement 
validation checks done. The designer should take care to not specify 
'when' statements that hinder incremental editing of the 'candidate' 
configuration.


I use 'when' statements in models utilizing lists often with 'identity' 
leafs in the parent chain of data nodes and only testing for the values 
of those 'identity' leafs or the keys. Anything else IMO requires 'must' 
statements with proper dedicated error messages. Following this rule 
prevents situations where you need to have a single  
creating multiple leafs with complicated dependency to satisfy the 
'when' statements.


Probably a clarification that the 'when' statement should evaluate to 
'true' after the  is applied (e.g. to a copy of the edited 
configuration for example) and not based only on the data content of the 
 RPC is what is needed.


Vladimir

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

[netmod] Circular dependency in 'when'

[Vladimir Vassilev]

Hi,

Is there any practical value of 'when' statements with circular 
dependency to the value of the parent (in case it is a leaf) or any 
children of the parent?


  container circular-dependency-when {
  leaf a {
  when "(. + ../b) = 100";
  type uint16 {
  range "0 .. 100";
  }
  }
  leaf b {
  type uint16 {
  range "0 .. 100";
  }
  }
  }

I notice none of the tools  known to me complain about this example 
model however some will not allow the user to interactively configure 
'a' (even if he intends to use value which would make the 'when' 
statement evaluate as "true").


Did not find any 'when' statements depending on the value of their 
parent or the value of children of that parent in the standard and draft 
models known to me but this is valid YANG according to the YANG RFC text.


I believe if there is consensus this indeed qualifies as circular 
dependency and it has no value to allow such cases it can at least give 
a signal to model designers they should avoid using such 'when' 
statements until this is explicitly noted in a follow up YANG version.


Vladimir

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

Re: [netmod] How to constrain a leaf to a read-only list of supported values?

[Vladimir Vassilev]

One alternative for getting rid of unsupported "identity"-s is to use 
"if-feature" as sub-statement which is now supported in YANG 1.1. This 
would be an elegant solution for the example with the 3 compression 
methods. However for standard models one will either have to live with 
the many irrelevant options presented to the user or use some extension 
similar to 
https://tools.ietf.org/html/draft-vassilev-netmod-yang-direct-must-augment-ext-00 
but for identities instead of "must" statements. Then clients and 
servers supporting it will be able to take the light out of the 
"identity"-s the implementation does not support by augmenting those 
with relevant if-feature statements.


On 09/01/2016 09:48 AM, Balazs Lengyel wrote:

Hello,

The proposed iana-entity.yang seems to take the same approach: one 
file defining 28 identities.


And I share all your concerns about iana-if-type.

Balazs


On 2016-08-31 14:16, Vladimir Vassilev wrote:

On 08/31/2016 12:38 PM, Ladislav Lhotka wrote:
On 31 Aug 2016, at 11:10, Vladimir Vassilev 
<vladi...@transpacket.com> wrote:


If you design your models using identityref and define the 
identities in separate modules e.g. compression-zip.yang, 
compression-gzip.yang, etc. you can just chose not to load the 
particular YANG models containing the identities not supported when 
your device starts.
Right, and I have proposed this approach several times in the past. 
However, some people prefer that the modules defining identities 
mirror IANA and similar registries. In the case of 
iana-interface-types it also means that implementations have to deal 
with obsolete, obscure and experimental interface types that happen 
to be in the IANA registry but nobody will ever want to use.


Lada

+1

The 275 identities defined in iana-if-type.yang appearing as possible 
/interfaces/interface/type tab completion options in a YANG aware cli 
or drop-down menu in gui is annoying and stands out as an obvious 
problem.


It is not late to split the file. No standard RFC YANG model includes 
iana-if-type.yang yet. The actually referenced identities in current 
drafts is less then 16 (grep-ing in my known YANG model archive) 
{ethernetCsmacd, l2vlan, ieee8023adLag, ifPwType, pos, atm, 
atmSubInterface, sonet, otnOtu, frameRelay, bridge, 
macSecControlledIF, fastdsl}


If not single instance per file maybe dividing the file into 
categories so if your device is atm aware you import 
iana-if-type-atm.yang and get {atm, atmSubInterface}.


However we can probably agree the iana-if-type.yang exception is not 
a valid excuse for new models like the one in the example where there 
are 3 compression methods to not modularize the identity definitions 
into separate files and not load identities the implementation does 
not support but instead resolve to workaround solutions.


Vladimir

___
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] How to constrain a leaf to a read-only list of supported values?

[Vladimir Vassilev]

On 08/31/2016 01:10 PM, Balazs Lengyel wrote:

Hello,

The problem is not just about identities. It can be a value range.
If your example was about value range then a deviation would be a 
solution. Then we have the same case for modularization. YANG files 
defining deviations loaded when the deviation is relevant and not loaded 
otherwise.
Sometimes we have a generic module like iana-interface type that list 
a lot of identities, and I don't want to have one YAM file per 
identity, to allow a fine control. Also sadly it is not possible to 
have a deviation removing identities. IMHO would be needed.
Well the biggest problem modularizing your identity definitions is you 
will have more YANG files proportional to the flexibility you want. I 
would have chosen that in the example you provide.


I would be more interested in having an extension saying static-data. 
This would state that that part of config is set by the system, and 
can not be modified by the user. So I could have conditions based on 
it, but the user might not modify it.
That is still not as good as modularization of your model and using 
optionally loadable YANG 'deviation's and 'identity' definitions. Even 
if you have "static-data tree" you will be able to use must statements 
to not allow certain range based on that "static data tree" it will 
still be the range defined in the type from the model that will be shown 
to the user editing the configuration in YANG aware CLI or GUI. It is 
still a workaround even if the must statement will fail upon commit.


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

Re: [netmod] How to constrain a leaf to a read-only list of supported values?

[Vladimir Vassilev]

If you design your models using identityref and define the identities in 
separate modules e.g. compression-zip.yang, compression-gzip.yang, etc. 
you can just chose not to load the particular YANG models containing the 
identities not supported when your device starts.


If you absolutely can not define your identities in separate YANG files 
(better modularity is indeed the edge YANG has over other modeling 
languages and it should be used) you can use feature with some 
limitations e.g. instead of leaf of type enumeration you will have a 
choice with each case containing if-feature and presence container for 
example.


If you can not change the model to be modular and your implementation 
does not support it 100% then you are not supporting the model and you 
are free to be creative with the workaround but then YANG is not the 
problem.


I also see alternative discussion value in the subject line. Lets say 
one would like to specify in a standard way a list of values supported 
by a device as valid /interface/interface/name values e.g. ("ge0", 
"ge1",  "xe0", "xe1", "me0"). This can be useful in many ways e.g. 
tab completion. Also the supported types for each of the interface names 
and so on further reducing the entropy. Does anyone else see value in that?


On 08/31/2016 09:35 AM, Balazs Lengyel wrote:

Hello Jan,

This may be the best solution we have, but nacm rules may be changed, 
and then device limits might be edited by the operator, and then we 
have a problem.


The good solution would be to indicate that this is read-only static 
data, and allow must, leafref towards it. However I don't see a way to 
do this in YANG at the moment short of an ericsson-extension.


regards Balazs


On 2016-08-30 15:14, Jan Lindblad wrote:

Balazs,


We have the following design pattern.

1) An enumeration or a set of identities are defined that define a 
set of options generally supported by Ericsson products.  (e.g. 
supported compression algorithms)
2) The specific node sets in run-time a leaf-list indicating the set 
of values that this specific node supports (e.g. 
nodes-supported-compression-types: zip, gzip, bz)
3) For some function the user has to select a specific option value 
(e.g. leaf file-compression for transferring backup files)


Problem: how do you restrict values for (3) - file-compression so 
that it is one of the nodes-supported-compression-types. The natural 
solution would be to use a must expression or a leaf-ref, but as 
nodes-supported-compression-types is config-false data, it is not 
allowed to constrain the config=true leaf, file-compression, with it.


It would be perfectly reasonable because the 
nodes-supported-compression-types only change during upgrade, but 
YANG does not allow this.


I would still like to have some modeled solution, not just plain 
English stating the constraint. Any idea how to do it?
I have seen this use case many times. I usually solve this by making 
a container with device specific limits, lists of supported values, 
etc, which is config true but with nacm rules preventing everyone 
from making changes. Then I have a device specific database 
initialization file with the correct settings for this device, which 
is loaded into the database at first boot.


/jan




Vladimir

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

Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers

[Vladimir Vassilev]

On 08/23/2016 11:09 AM, Martin Bjorklund wrote:

Vladimir Vassilev <vladi...@transpacket.com> wrote:

On 08/23/2016 10:15 AM, Martin Bjorklund wrote:

They are evaluated.  See Section 7.5.3:

 When a datastore is validated, all "must" constraints are
 conceptually evaluated once for each node in the accessible tree (see
 Section 6.4.1).


/martin

Then we have the case I objected to and the example:

YANG 1.0:

augment "/if:interfaces/if:interface" {
 container inet {
 must "../name = 'me0'" {

This should have been a 'when' expression, not 'must'.  Alternatively,
it should have been a P-container, since obviously the container has
some semantics.  Or alternatively, the must expression should have
been on the address leaf, since this is what you really checked.
I claim that any example of a must statement in non-presence container 
is affected in a similar way (Has anyone example that proves the 
contrary?). 'when' statements are alternative when the 'must' statement 
depends on data nodes that are not child nodes (which I admit is the 
case in this example). The thing with 'must' expressions in non-presence 
container is they are used in complicated models where 'mandatory' and 
'choice' solutions are not an option and for whatever reason the design 
got to that point the fact is that by introducing the auto-evaluation of 
non-presence containers it is even more complicated to use them. Here an 
example that stops working in YANG 1.1:


augment "/if:interfaces/if:interface" {
container 2-company-3-crowd {
must "(a and b and not(c)) or (not(a) and b and c) or (a and 
not(b) and c)" {

}
leaf a {
type string;
}
leaf b {
type string;
}
leaf c {
type string;
}
}
}

... to make it work one has to accept to not deny the creation of 
/interfaces/interface/2-company-3-crowd as empty container and modify 
the expression adding ...or (not(a) and not(b) and not(c)).



That said I admit it is not often one needs non-presence container must 
statements. But in the cases one needs them the YANG 1.1 text is not 
helping. It causes all the statements to be processed when no one 
attempts to create them or child nodes residing in them. I find no 
justification for that.






/martin



 description
  "The inet container is only valid for the management ('me0')
  interface.";
 }
 leaf address {
 type inet:ip-prefix;
 }
 }
}

YANG 1.1 (replace "../name = 'me0'" with "../name='me0' or not
(./address)" and process 95 unnecessary Xpath evaluations).

I think this proves the argument that there will be more unnecessary
Xpath processing.  In addition it illustrates how a simple task
requires ugly patch (the ".. or not (./address)" added to the must
expression) just to ensure the expression does not fail in the default
case where the interface is not named "me0" and the user has not even
attempted to create empty /interfaces/interface/inet container in YANG
1.1.

Vladimir



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

Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers

[Vladimir Vassilev]

On 08/23/2016 10:15 AM, Martin Bjorklund wrote:

They are evaluated.  See Section 7.5.3:

When a datastore is validated, all "must" constraints are
conceptually evaluated once for each node in the accessible tree (see
Section 6.4.1).


/martin

Then we have the case I objected to and the example:

YANG 1.0:

augment "/if:interfaces/if:interface" {
container inet {
must "../name = 'me0'" {
description
 "The inet container is only valid for the management 
('me0') interface.";

}
leaf address {
type inet:ip-prefix;
}
}
}

YANG 1.1 (replace "../name = 'me0'" with "../name='me0' or not 
(./address)" and process 95 unnecessary Xpath evaluations).


I think this proves the argument that there will be more unnecessary 
Xpath processing. In addition it illustrates how a simple task requires 
ugly patch (the ".. or not (./address)" added to the must expression) 
just to ensure the expression does not fail in the default case where 
the interface is not named "me0" and the user has not even attempted to 
create empty /interfaces/interface/inet container in YANG 1.1.


Vladimir

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

Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers

[Vladimir Vassilev]

On 08/23/2016 12:08 AM, Alex Campbell wrote:

The intention in this case is obviously to evaluate the 'must' statement if
the container contains any values; what would break if we said that

A non-presence container exists in the data tree if and only if it has
any children which exist in the data tree.

thus disallowing the existence of empty NP-containers in the data tree?


The question is where is the misunderstanding.

   "If a node that exists in the accessible tree has a non-presence
   container as a child, then the non-presence container also exists in
   the tree."

What does this mean? I believe there is confusion based on "the tree" 
refering not to the data tree but the Xpath context. At least I hoped 
until I realized the text was introduced as a solution to Y41 
'clarification of "must" in NP-container'. That definitely means it 
addresses the must statements in the non-presence containers and it 
means "the tree" as in the data tree.


1. If "then the non-presence container also exists in the tree." is 
refering to the Xpath context and not the data tree (which is not 
obvious since nowhere is the Xpath context introduced as "the tree") 
then the Xpath validation statements in the non-presence container do 
not have to be evaluated. The only effect is that other Xpath 
expressions testing for the existence of the non-presence container will 
return true.


2. If the meaning is that the non-presence container exists virtually in 
the data tree and its pertaining Xpath expressions have to be evaluated 
then there is a problem. Then it is not only that many unnecessary Xpath 
evaluations will be processed but also designers have to make sure their 
Xpath expressions do not fail when the non-presence container is not 
even created (it is not a problem if the user attempts to create it 
empty then at least there is some bad initiative from him asking for 
error message). Like in the example there will be 95 errors for all 
containers not part of the interface named "me0". There can never be a 
valid configuration for YANG 1.1 for this example. If the must statement 
is modified from must "../name = 'me0'" to "../name='me0' or not 
(./address)" then it will work as intended in YANG 1.0 with the overhead 
of 95 unnecessary evaluations.


If the text you propose is added without the current text removed it 
will be even more difficult to understand the clarification.


Vladimir


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

Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers

[Vladimir Vassilev]

On 08/22/2016 06:45 PM, Martin Bjorklund wrote:

I disagree.  If the model needs to have some semantic validation
rules, the designer is going to put them in a place such that they are
evaluated when the need to be evaluated.
So designers augmenting /interfaces/interface with non-presence 
container with child leaves should just pick one of the leaves in YANG 
1.1 and put the must statements there instead of the parent container. 
Yes this might work. There is no problem adding extra "../" in the Xpath 
expressions. But what is the justification of all that except the "If a 
container does not have a "presence" statement and the last child node 
is deleted, the NETCONF server MAY delete the container." text?


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

Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers

[Vladimir Vassilev]

On 08/22/2016 06:37 PM, Juergen Schoenwaelder wrote:

On Mon, Aug 22, 2016 at 06:15:50PM +0200, Vladimir Vassilev wrote:

On 08/22/2016 06:10 PM, Juergen Schoenwaelder wrote:

On Mon, Aug 22, 2016 at 05:59:37PM +0200, Vladimir Vassilev wrote:


Which of the 3 issues pointed in the conclusion you don't agree with and why
{1. limited validation expression flexibility, 2. higher validation
workload, 3. broken NACM}? Difficult to not agree with 2. And 1 is
predetermined from the fact of the reduced entropy attributed to a
non-presence container - namely its existence now is determined by the
existence of its parent (which reduces flexibility in a very certain way).

Can someone explain to me what exactly breaks NACM? An example would
help me.

/js (as contributor)


"It is absolutely legal to configure "update" rights to /interfaces to a
group of users reserving the "create" right to the superuser. How is this
scenario handled by servers ignoring empty non-presence containers?" (this
is excerpt from an earlier post on that thread)

If a non-presence container always exits in YANG 1.1 this usage example is
not possible.

Should I read 'ignoring empty non-presence containers' as 'removing empty
non-presence containers (form the XML encoding)'?
Yes the original post targeted the text: "If a container does not have a 
"presence" statement and the last

   child node is deleted, the NETCONF server MAY delete the container."

There is nothing indicating it is concerning only the XML encoding which 
I believe can be fixed with AUTH48 modification if we agree this is the 
intention.


Isn't the idea that non-presence container always exits in YANG 1.1
for the purpose of validation, that is in the XPATH context.

You have a point. The YANG 1.1 text addresses only the Xpath context:

"If a node that exists in the accessible tree has a non-presence
container as a child, then the non-presence container also exists in
the tree. ".

However now we have introduced a separation between a data tree and 
Xpath context tree which only serves the case where data tree 
non-presence containers are removed from the data tree automatically 
(and not only from the XML encoding as assumed above). Or do you see any 
other justification? It is this logic that creates the confusion and the 
impression YANG 1.1 advocates the NACM unfriendly case of non-presence 
containers being auto deleted from the data tree.


Back to your example, what is the client going to update in
/interfaces if /interfaces is empty? Or is the scenario that the group
of users have create and update rights within /interfaces but no
create right on /interfaces?  I am trying to understand what exactly
the situation is that you think causes problems.

/js
Here I might experience revelation I always assumed update on a 
container means you can create children in it but you can not create it 
if it does not exist already if you only have update rights but no 
create rights. There is no text in NACM RFC 6536 detailing what updating 
container means. Are you saying one can only replace values of leafs 
that already exist?


Vladimir

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

Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers

[Vladimir Vassilev]

On 08/22/2016 06:10 PM, Juergen Schoenwaelder wrote:

On Mon, Aug 22, 2016 at 05:59:37PM +0200, Vladimir Vassilev wrote:


Which of the 3 issues pointed in the conclusion you don't agree with and why
{1. limited validation expression flexibility, 2. higher validation
workload, 3. broken NACM}? Difficult to not agree with 2. And 1 is
predetermined from the fact of the reduced entropy attributed to a
non-presence container - namely its existence now is determined by the
existence of its parent (which reduces flexibility in a very certain way).

Can someone explain to me what exactly breaks NACM? An example would
help me.

/js (as contributor)

"It is absolutely legal to configure "update" rights to /interfaces to a 
group of users reserving the "create" right to the superuser. How is 
this scenario handled by servers ignoring empty non-presence 
containers?" (this is excerpt from an earlier post on that thread)


If a non-presence container always exits in YANG 1.1 this usage example 
is not possible.


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

Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers

[Vladimir Vassilev]

On 08/22/2016 03:36 PM, Ladislav Lhotka wrote:

This example is based on the bug I propose to be fixed. If you looked at the 
patch I propose in 
https://www.ietf.org/mail-archive/web/netconf/current/msg11637.html sec. 7.1.6 
of RFC 6020 is modified:

---
OLD:
7.6.1.  The leaf's default value

   The default value of a leaf is the value that the server uses if the
   leaf does not exist in the data tree.  The usage of the default value
   depends on the leaf's closest ancestor node in the schema tree that
   is not a non-presence container:

NEW:
7.6.1.  The leaf's default value

   The default value of a leaf is the value that the server uses if the
   leaf does not exist in the data tree.  The usage of the default value
   depends on the leaf's closest ancestor node in the schema tree:

This would effectively remove the distinction between presence and non-presence 
containers, and I am not in favour of doing so. In any case, this is not 
something to introduce in the AUTH48 stage.
The distinction in the context of the primary reason for introduction of 
the "presence" statement indicating explicit semantic meaning of the 
presence of a container is still there. However I do not see the value 
of distinction in terms of creation and deletion. And it is that 
distinction introducing the bulk of clarification texts. The now 
mandatory evaluation of all must statements in non-presence containers 
is going to introduce very high and unnecessary processing load. I gave 
an example with 96 interfaces switch with 20 non-presence containers in 
/interfaces/interface. How about top level SDN manager?



By introducing the Y41 "clarification" now they are conforming which is the 
only benefit at the cost of limited validation expression flexibility, higher validation 
workload, broken NACM and probably some other issues we are about to discover.

I don't agree with this conclusion. NACM probably needs to be updated anyway.
Which of the 3 issues pointed in the conclusion you don't agree with and 
why {1. limited validation expression flexibility, 2. higher validation 
workload, 3. broken NACM}? Difficult to not agree with 2. And 1 is 
predetermined from the fact of the reduced entropy attributed to a 
non-presence container - namely its existence now is determined by the 
existence of its parent (which reduces flexibility in a very certain way).

I don't see it as a workaround and I don't think there is ANY limitation 
whatsoever due to this. The rules are now clear, which is a good thing.

Lada
I have expressed my concerns. I did not find anything addressing the 3 
issues above on the list and I thought it was worth posting something in 
the context of the ongoing discussion. There may be different opinions 
of the significance of the issues but they do exist.


Vladimir

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

Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers

[Vladimir Vassilev]

On 08/22/2016 01:56 PM, Ladislav Lhotka wrote:

Vladimir Vassilev <vladi...@transpacket.com> writes:


On 08/20/2016 10:29 AM, Juergen Schoenwaelder wrote:

As document shepherd, I believe there is no strong agreement on the
problem and there is no concrete proposal with strong consensus for a
modification of the document (which is in AUTH48). In fact, there has
been no defect description and proposed bug fix at all on the NETMOD
mailing list.

Hello,

I have strong objection to the text proposed as solution to issue #41:

6.4.1 Xpath Context:

  If a node that exists in the accessible tree has a non-presence
  container as a child, then the non-presence container also exists in
  the tree.

The description of the issue itself is:

  Y41: clarification of "must" in NP-container <>


I believe the 5 mails in the
http://www.ietf.org/mail-archive/web/netmod/current/msg10015.html did
not address all the negative consequences of such change in the rules
for evaluation of validation statements regarding non-presence
containers and the solution that was taken is not acceptable for the
following reasons:

[1] the proposed text is not a clarification as indicated in Y41 but a
backward incompatible change of the YANG validation statement evaluation
rules.

The charter doesn't limit YANG 1.1 to clarifications. The adopted
solution addresses ambiguous cases like this:

container top {
   must "foo > 42";
   leaf foo {
 type uint8;
   }
   leaf bar {
 type boolean;
 default true;
   }
}

If "top" doesn't exist, then according to sec. 7.6.1 of RFC 6020, the
default value of "bar" is in use, so somehow the NP-container "top"
should also be in use. The question then arises whether the "must"
constraint applies or not.
This example is based on the bug I propose to be fixed. If you looked at 
the patch I propose in 
https://www.ietf.org/mail-archive/web/netconf/current/msg11637.html sec. 
7.1.6 of RFC 6020 is modified:


---
OLD:
7.6.1.  The leaf's default value

   The default value of a leaf is the value that the server uses if the
   leaf does not exist in the data tree.  The usage of the default value
   depends on the leaf's closest ancestor node in the schema tree that
   is not a non-presence container:

NEW:
7.6.1.  The leaf's default value

   The default value of a leaf is the value that the server uses if the
   leaf does not exist in the data tree.  The usage of the default value
   depends on the leaf's closest ancestor node in the schema tree:
---
The patch removes the "MAY be deleted" text and all artifacts resulting 
from poor attempts to cover the logical discontinuity it inflicts on 
YANG. It is the only justification of all special case clarifications 
regarding non-presence containers which are never going to be enough to 
cover all private cases.



[2] the clarification introduces further confusion for models like NACM
where non-presence containers are used for access control and their
explicit creation and deletion is the only sane way to enforce the
configured rules. Always present non-presence containers that MAY be
auto deleted by servers ... how will this work exactly?

IMO the problem is in this auto-deletion option. I suspect my example
above may also be unclear from the NACM point of view - do the rules set
for "top" apply if "top" hasn't been explicitly configured?
+1 I do not know either. NACM is affected in a bad way. The "MAY be 
deleted" text was not that bad since one would assume sane servers would 
not auto delete data nodes which already have configured NACM rules.



[3] the proposed text leads to increased processing of large number of
validation checks which is very unlikely to bring real value to YANG. 20
non-presence containers with must statements per interface in
96-interface switch is already heavy Xpath evaluation task. A task that
in YANG 1.0 was not necessary if the containers were not explicitly
created.

Some implementations did it anyway and some didn't, which was considered
a problem.
The implementations that did it anyway were not conforming to YANG 1.0 
since non-presence containers were not part of the configuration tree by 
default unless they were explicitly created. By introducing the Y41 
"clarification" now they are conforming which is the only benefit at the 
cost of limited validation expression flexibility, higher validation 
workload, broken NACM and probably some other issues we are about to 
discover.



[4] the proposed text leads to less flexibility and excludes certain
practical validation models e.g.
https://www.ietf.org/mail-archive/web/netconf/current/msg11609.html

Well... If the goal it to prevent np2_leaf from appearing when np1_leaf
is configured, then the most natural solution is to put a must statement on
np1_leaf:

leaf np1_leaf {
   type string;
   must "not(../../np2/np2_leaf)&q

Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers

[Vladimir Vassilev]

Dear Juergen Schoenwaelder,

On 08/22/2016 11:25 AM, Juergen Schoenwaelder wrote:

On Sat, Aug 20, 2016 at 07:18:42PM +0200, Vladimir Vassilev wrote:


Hello,

I have strong objection to the text proposed as solution to issue #41:


Dear Vladimir Vassilev,

please note that we YANG 1.1 is in AUTH48 state, that is YANG 1.1 has
passed WG last call, IETF last call, and IESG approval. In other
words, we are way beyond the state in the IETF process where we
discuss the resolution of individual issues. As far as I recall from
the logs, issue #41 was closed about two years ago.

/js



I wrote my proposal for errata as if the RFC was published hoping it 
would  gain agreement on the bug and the proposed fix and hopefully get 
addressed during the editing/auth48 stage so we do not have to post an 
RFC with already known defects. I interpreted your mail as invitation 
for people with opinion on the issue to post their concrete proposals 
which is what I did.


On 08/20/2016 10:29 AM, Juergen Schoenwaelder wrote:

Here is what I wrote on Thu, 16 Jun 2016 14:49:00 +0200:

: It is possible that people will find more bugs while this I-D sits in
: the RFC editor queue. My idea is to treat them pretty much in the way
: we treat errata of published RFCs (they need to be clearly written up,
: discussed on the list, there needs to be agreement on the bug and the
: proposed fix). If we get pre-publication errata with consensus, I hope
: we can address them during the editing/auth48 stage so we do not have
: to post an RFC with already known defects. Does this make sense to
: you?

As document shepherd, I believe there is no strong agreement on the
problem and there is no concrete proposal with strong consensus for a
modification of the document (which is in AUTH48). In fact, there has
been no defect description and proposed bug fix at all on the NETMOD
mailing list.

/js
Why is the "defect description and proposed bug fix" I propose not a 
candidate for consideration for a AUTH48 change?


Can someone with alternative opinion comment on the issues [1-4] I list. 
I really hope I am wrong and those are not as significant problems as it 
currently seems to me.


On 08/20/2016 07:18 PM, Vladimir Vassilev wrote:

Hello,

I have strong objection to the text proposed as solution to issue #41:

6.4.1 Xpath Context:

If a node that exists in the accessible tree has a non-presence
container as a child, then the non-presence container also exists in
the tree.

The description of the issue itself is:

Y41: clarification of "must" in NP-container <>


I believe the 5 mails in the 
http://www.ietf.org/mail-archive/web/netmod/current/msg10015.html did 
not address all the negative consequences of such change in the rules 
for evaluation of validation statements regarding non-presence 
containers and the solution that was taken is not acceptable for the 
following reasons:


[1] the proposed text is not a clarification as indicated in Y41 but a 
backward incompatible change of the YANG validation statement 
evaluation rules.


[2] the clarification introduces further confusion for models like 
NACM where non-presence containers are used for access control and 
their explicit creation and deletion is the only sane way to enforce 
the configured rules. Always present non-presence containers that MAY 
be auto deleted by servers ... how will this work exactly?


[3] the proposed text leads to increased processing of large number of 
validation checks which is very unlikely to bring real value to YANG. 
20 non-presence containers with must statements per interface in 
96-interface switch is already heavy Xpath evaluation task. A task 
that in YANG 1.0 was not necessary if the containers were not 
explicitly created.


[4] the proposed text leads to less flexibility and excludes certain 
practical validation models e.g. 
https://www.ietf.org/mail-archive/web/netconf/current/msg11609.html


[5] the proposed text inflicts problems 1-4 and its clarification 
effect is not working for me.


I have a concrete proposal for a solution on the issue - remove the 
"non-presence containers MAY be deleted automatically" text from YANG 
1.1 instead of opening Pandora's box:


Instead of building further the pipe dream of non-presence containers 
that MAY be deleted automatically I propose that flexibility removed 
from YANG 1.1. All non-presence containers have to be created 
explicitly and the validation statements must be evaluated only for 
explicitly created containers (so long there is no change from YANG 
1.0) and these containers MUST be deleted explicitly (replacing the 
"MAY be deleted automatically" YANG 1.0 optimization attempt which is 
the origin of the pipe dream) as one would logically expect. It is 
semantical meaning that is not present not the container which still 
has its usage giving structure to the data and especially in cases 
like NACM and validation statements where

Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers

[Vladimir Vassilev]

On 08/20/2016 10:29 AM, Juergen Schoenwaelder wrote:


As document shepherd, I believe there is no strong agreement on the
problem and there is no concrete proposal with strong consensus for a
modification of the document (which is in AUTH48). In fact, there has
been no defect description and proposed bug fix at all on the NETMOD
mailing list.

Hello,

I have strong objection to the text proposed as solution to issue #41:

6.4.1 Xpath Context:

If a node that exists in the accessible tree has a non-presence
container as a child, then the non-presence container also exists in
the tree.

The description of the issue itself is:

Y41: clarification of "must" in NP-container <>


I believe the 5 mails in the 
http://www.ietf.org/mail-archive/web/netmod/current/msg10015.html did 
not address all the negative consequences of such change in the rules 
for evaluation of validation statements regarding non-presence 
containers and the solution that was taken is not acceptable for the 
following reasons:


[1] the proposed text is not a clarification as indicated in Y41 but a 
backward incompatible change of the YANG validation statement evaluation 
rules.


[2] the clarification introduces further confusion for models like NACM 
where non-presence containers are used for access control and their 
explicit creation and deletion is the only sane way to enforce the 
configured rules. Always present non-presence containers that MAY be 
auto deleted by servers ... how will this work exactly?


[3] the proposed text leads to increased processing of large number of 
validation checks which is very unlikely to bring real value to YANG. 20 
non-presence containers with must statements per interface in 
96-interface switch is already heavy Xpath evaluation task. A task that 
in YANG 1.0 was not necessary if the containers were not explicitly created.


[4] the proposed text leads to less flexibility and excludes certain 
practical validation models e.g. 
https://www.ietf.org/mail-archive/web/netconf/current/msg11609.html


[5] the proposed text inflicts problems 1-4 and its clarification effect 
is not working for me.


I have a concrete proposal for a solution on the issue - remove the 
"non-presence containers MAY be deleted automatically" text from YANG 
1.1 instead of opening Pandora's box:


Instead of building further the pipe dream of non-presence containers 
that MAY be deleted automatically I propose that flexibility removed 
from YANG 1.1. All non-presence containers have to be created explicitly 
and the validation statements must be evaluated only for explicitly 
created containers (so long there is no change from YANG 1.0) and these 
containers MUST be deleted explicitly (replacing the "MAY be deleted 
automatically" YANG 1.0 optimization attempt which is the origin of the 
pipe dream) as one would logically expect. It is semantical meaning that 
is not present not the container which still has its usage giving 
structure to the data and especially in cases like NACM and validation 
statements where without certain explicit create/delete rules things get 
really confusing.


The concrete proposal in form of a patch to RFC6020 sent in this e-mail 
to the netconf mailing list: 
https://www.ietf.org/mail-archive/web/netconf/current/msg11637.html 
There will be even more obsoleted clarification text that will be 
irrelevant if the concept change is applied to YANG 1.1


Vladimir

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