Re: [netmod] 3 RFCs in 1 day!

[Juergen Schoenwaelder]

With the publication of these three RFCs a major milestone has been
reached - a big thank you to Martin and Lada and everybody who
contributed to the development of these specifications over the last
two years. This work involved 1 interim meeting, 22 virtual interim
meetings and the resolution of 60 tracked issues, and countless
messages on the mailing list. Lets have a virtual celebration today!

/js

On Wed, Aug 31, 2016 at 07:57:16PM -0700, Andy Bierman wrote:
> Hi,
> 
> I get to be the first to thank Martin and Lada for all the work
> that went into these RFCs. YANG 1.1 is finally done!
> 
> Now I hope we start seeing lots of implementations of these RFCs.
> 
> 
> Andy

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


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

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

[netmod] 3 RFCs in 1 day!

[Andy Bierman]

Hi,

I get to be the first to thank Martin and Lada for all the work
that went into these RFCs. YANG 1.1 is finally done!

Now I hope we start seeing lots of implementations of these RFCs.


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

[netmod] RFC 7952 on Defining and Using Metadata with YANG

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.


RFC 7952

Title:  Defining and Using Metadata with YANG 
Author: L. Lhotka
Status: Standards Track
Stream: IETF
Date:   August 2016
Mailbox:lho...@nic.cz
Pages:  21
Characters: 35394
Updates:RFC 6110

I-D Tag:draft-ietf-netmod-yang-metadata-07.txt

URL:https://www.rfc-editor.org/info/rfc7952

DOI:http://dx.doi.org/10.17487/RFC7952

This document defines a YANG extension that allows for defining
metadata annotations in YANG modules.  The document also specifies
XML and JSON encoding of annotations and other rules for annotating
instances of YANG data nodes.

This document is a product of the NETCONF Data Modeling Language Working Group 
of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


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

[netmod] RFC 7951 on JSON Encoding of Data Modeled with YANG

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.


RFC 7951

Title:  JSON Encoding of Data Modeled with YANG 
Author: L. Lhotka
Status: Standards Track
Stream: IETF
Date:   August 2016
Mailbox:lho...@nic.cz
Pages:  20
Characters: 32316
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-netmod-yang-json-10.txt

URL:https://www.rfc-editor.org/info/rfc7951

DOI:http://dx.doi.org/10.17487/RFC7951

This document defines encoding rules for representing configuration
data, state data, parameters of Remote Procedure Call (RPC)
operations or actions, and notifications defined using YANG as
JavaScript Object Notation (JSON) text.

This document is a product of the NETCONF Data Modeling Language Working Group 
of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


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

[netmod] RFC 7950 on The YANG 1.1 Data Modeling Language

[rfc-editor]

A new Request for Comments is now available in online RFC libraries.


RFC 7950

Title:  The YANG 1.1 Data Modeling Language 
Author: M. Bjorklund, Ed.
Status: Standards Track
Stream: IETF
Date:   August 2016
Mailbox:m...@tail-f.com
Pages:  217
Characters: 393155
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-netmod-rfc6020bis-14.txt

URL:https://www.rfc-editor.org/info/rfc7950

DOI:http://dx.doi.org/10.17487/RFC7950

YANG is a data modeling language used to model configuration data,
state data, Remote Procedure Calls, and notifications for network
management protocols.  This document describes the syntax and
semantics of version 1.1 of the YANG language.  YANG version 1.1 is a
maintenance release of the YANG language, addressing ambiguities and
defects in the original specification.  There are a small number of
backward incompatibilities from YANG version 1.  This document also
specifies the YANG mappings to the Network Configuration Protocol
(NETCONF).

This document is a product of the NETCONF Data Modeling Language Working Group 
of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


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

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

[Juergen Schoenwaelder]

On Wed, Aug 31, 2016 at 06:11:14PM +, Kent Watsen wrote:
> [as a contributor]
> 
> My only comment on this draft is that I’d prefer it if the “routing-state” 
> tree were moved into another YANG module, so that it could be more easily 
> deprecated when the opstate solution comes.   I suggested this before, with 
> regards to rfc6087bis Section 5.23, but that thread seemed to have petered 
> out, but now here we are and my opinion remains the same.
>

We already have foo:/foo /foo:foo-state modules and while we can now
start a series of foo:/foo and foo-state:/foo-state modules in the
hope that this will eventually 'easier' in the future, it might also
be that we just create more variation and confusion.

/js

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

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

Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

[Kent Watsen]

[as a contributor]

My only comment on this draft is that I’d prefer it if the “routing-state” tree 
were moved into another YANG module, so that it could be more easily deprecated 
when the opstate solution comes.   I suggested this before, with regards to 
rfc6087bis Section 5.23, but that thread seemed to have petered out, but now 
here we are and my opinion remains the same.

Thanks,
Kent

From: netmod  on behalf of Kent Watsen 

Date: Friday, August 26, 2016 at 1:54 PM
To: "netmod@ietf.org" 
Subject: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 
9, 2016)


This is a notice to start a two-week NETMOD WG last call for the document:

A YANG Data Model for Routing Management
https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-23

Please indicate your support or concerns by Thursday September 9, 2016.

We are not only interested in receiving defect reports, we are equally 
interested in statements of the form:

  * I have reviewed draft-ietf-netmod-routing-cfg-23 and I found no issues
  * I have implemented the data model in draft-ietf-netmod-routing-cfg-23
  * I am implementing the data model in draft-ietf-netmod-routing-cfg-23
  * I am considering to implement the data model in 
draft-ietf-netmod-routing-cfg-23

Of course, these are merely suggestions, folks can provide comments in any form 
that suits them.


Thank you,

NETMOD WG Chairs


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

Re: [netmod] RFC 6087bis guidance re use of revision statements indrafts

[Kent Watsen]

I like Jonathan’s proposed text as well.

Kent // as a contributor


On 8/31/16, 8:14 AM, "netmod on behalf of Acee Lindem (acee)" 
 wrote:



On 8/31/16, 8:00 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:

>
>> On 31 Aug 2016, at 13:17, William Lupton 
>>wrote:
>> 
>> I like this. In particular I like the clean use of “version” and
>>“revision”. Editorial nit: add a comma after “i.e.” because that’s the
>>style used for “e.g.”. Tx, W.
>
>+1
>
>Lada

I like this text as well. Keeping a complete revision history in the model
can become unwieldy. Besides, git does a MUCH better job of this.

Thanks,
Acee





>
>> 
>>> On 31 Aug 2016, at 11:56, Jonathan Hansford 
>>>wrote:
>>> 
>>> How about:
>>>  
>>> NEW:
>>>  
>>> It is not required to keep the full revision history of draft versions
>>>(e.g., modules contained within Internet-Drafts). That is, within a
>>>sequence of draft versions, only the most recent revision need be
>>>recorded in the module. However, whenever a new (i.e. changed) version
>>>is made available (e.g., via a new version of an Internet-Draft), the
>>>revision date of that new version MUST be updated to a date later than
>>>that of the previous version.
>>>  
>>> Jonathan
>>>  
>>> From: William Lupton
>>> Sent: 29 August 2016 15:20
>>> To: Andy Bierman
>>> Cc: netmod@ietf.org
>>> Subject: Re: [netmod] RFC 6087bis guidance re use of revision
>>>statements indrafts
>>>  
>>> Andy,
>>>  
>>> This thread started with discussion of an apparent ambiguity in the
>>>current text:
>>>  
>>> OLD
>>>  
>>> It is acceptable to reuse the same revision statement within
>>>unpublished versions (i.e., Internet-Drafts), but the revision date
>>>MUST be updated to a higher value each time the Internet-Draft is
>>>re-posted.
>>>  
>>> —— 
>>>  
>>> It became clear from the subsequent discussion (thanks Randy!) that
>>>the above text isn’t intended to mean “reuse the identical revision
>>>statement, INCLUDING THE REVISION DATE” but to mean “reuse the revision
>>>statement, UPDATING THE REVISION DATE”.
>>>  
>>> Then other people raised other points, e.g only updating the revision
>>>date if the YANG has changed, distinguishing between the document and
>>>the YANG contained therein, and distinguishing between YANG in IDs and
>>>YANG created by other SDOs. My proposed new text tries to address all
>>>of these:
>>>  
>>> NEW:
>>> 
>>> It is not required to keep the full revision history of draft versions
>>>(e.g., modules contained within Internet-Drafts). That is, within a
>>>sequence of draft versions, only the most recent revision need be
>>>recorded in the module. However, if the module has changed, the
>>>revision date of the most recent revision MUST be updated to a later
>>>date whenever a new version is made available (e.g., via a new version
>>>of an Internet-Draft).
>>>  
>>> ——
>>>  
>>> I believe that this retains the original intent in a way that resolves
>>>the original ambiguity and addresses the other points that were raised.
>>>It it’s “worse”, how is it worse (apart from being longer, on which
>>>point mea culpa)?
>>>  
>>> Thanks,
>>> William
>>>  
>>> On 19 Aug 2016, at 15:42, Andy Bierman  wrote:
>>>  
>>> On Fri, Aug 19, 2016 at 7:13 AM, Dale R. Worley 
>>>wrote:
>>> Andy Bierman  writes:
>>> > An Internet-Draft is NOT a means of "publishing" a specification;
>>> 
>>> As I said, that's the theory, but practice is considerably different.
>>>  
>>> Anybody that implements a work-in-progress knows they are taking a risk
>>> on an unstable document.  The guideline already says MUST update
>>> the revision date.
>>>  
>>> Not sure what more you want to guidelines document to do.
>>>  
>>> Dale
>>>  
>>> Andy
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>
>___
>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 

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] RFC 6087bis guidance re use of revision statements indrafts

[Acee Lindem (acee)]

On 8/31/16, 8:00 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:

>
>> On 31 Aug 2016, at 13:17, William Lupton 
>>wrote:
>> 
>> I like this. In particular I like the clean use of “version” and
>>“revision”. Editorial nit: add a comma after “i.e.” because that’s the
>>style used for “e.g.”. Tx, W.
>
>+1
>
>Lada

I like this text as well. Keeping a complete revision history in the model
can become unwieldy. Besides, git does a MUCH better job of this.

Thanks,
Acee





>
>> 
>>> On 31 Aug 2016, at 11:56, Jonathan Hansford 
>>>wrote:
>>> 
>>> How about:
>>>  
>>> NEW:
>>>  
>>> It is not required to keep the full revision history of draft versions
>>>(e.g., modules contained within Internet-Drafts). That is, within a
>>>sequence of draft versions, only the most recent revision need be
>>>recorded in the module. However, whenever a new (i.e. changed) version
>>>is made available (e.g., via a new version of an Internet-Draft), the
>>>revision date of that new version MUST be updated to a date later than
>>>that of the previous version.
>>>  
>>> Jonathan
>>>  
>>> From: William Lupton
>>> Sent: 29 August 2016 15:20
>>> To: Andy Bierman
>>> Cc: netmod@ietf.org
>>> Subject: Re: [netmod] RFC 6087bis guidance re use of revision
>>>statements indrafts
>>>  
>>> Andy,
>>>  
>>> This thread started with discussion of an apparent ambiguity in the
>>>current text:
>>>  
>>> OLD
>>>  
>>> It is acceptable to reuse the same revision statement within
>>>unpublished versions (i.e., Internet-Drafts), but the revision date
>>>MUST be updated to a higher value each time the Internet-Draft is
>>>re-posted.
>>>  
>>> —— 
>>>  
>>> It became clear from the subsequent discussion (thanks Randy!) that
>>>the above text isn’t intended to mean “reuse the identical revision
>>>statement, INCLUDING THE REVISION DATE” but to mean “reuse the revision
>>>statement, UPDATING THE REVISION DATE”.
>>>  
>>> Then other people raised other points, e.g only updating the revision
>>>date if the YANG has changed, distinguishing between the document and
>>>the YANG contained therein, and distinguishing between YANG in IDs and
>>>YANG created by other SDOs. My proposed new text tries to address all
>>>of these:
>>>  
>>> NEW:
>>> 
>>> It is not required to keep the full revision history of draft versions
>>>(e.g., modules contained within Internet-Drafts). That is, within a
>>>sequence of draft versions, only the most recent revision need be
>>>recorded in the module. However, if the module has changed, the
>>>revision date of the most recent revision MUST be updated to a later
>>>date whenever a new version is made available (e.g., via a new version
>>>of an Internet-Draft).
>>>  
>>> ——
>>>  
>>> I believe that this retains the original intent in a way that resolves
>>>the original ambiguity and addresses the other points that were raised.
>>>It it’s “worse”, how is it worse (apart from being longer, on which
>>>point mea culpa)?
>>>  
>>> Thanks,
>>> William
>>>  
>>> On 19 Aug 2016, at 15:42, Andy Bierman  wrote:
>>>  
>>> On Fri, Aug 19, 2016 at 7:13 AM, Dale R. Worley 
>>>wrote:
>>> Andy Bierman  writes:
>>> > An Internet-Draft is NOT a means of "publishing" a specification;
>>> 
>>> As I said, that's the theory, but practice is considerably different.
>>>  
>>> Anybody that implements a work-in-progress knows they are taking a risk
>>> on an unstable document.  The guideline already says MUST update
>>> the revision date.
>>>  
>>> Not sure what more you want to guidelines document to do.
>>>  
>>> Dale
>>>  
>>> Andy
>> 
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>
>___
>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] RFC 6087bis guidance re use of revision statements indrafts

[Ladislav Lhotka]

> On 31 Aug 2016, at 13:17, William Lupton  wrote:
> 
> I like this. In particular I like the clean use of “version” and “revision”. 
> Editorial nit: add a comma after “i.e.” because that’s the style used for 
> “e.g.”. Tx, W.

+1

Lada

> 
>> On 31 Aug 2016, at 11:56, Jonathan Hansford  wrote:
>> 
>> How about:
>>  
>> NEW:
>>  
>> It is not required to keep the full revision history of draft versions 
>> (e.g., modules contained within Internet-Drafts). That is, within a sequence 
>> of draft versions, only the most recent revision need be recorded in the 
>> module. However, whenever a new (i.e. changed) version is made available 
>> (e.g., via a new version of an Internet-Draft), the revision date of that 
>> new version MUST be updated to a date later than that of the previous 
>> version.
>>  
>> Jonathan
>>  
>> From: William Lupton
>> Sent: 29 August 2016 15:20
>> To: Andy Bierman
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements 
>> indrafts
>>  
>> Andy,
>>  
>> This thread started with discussion of an apparent ambiguity in the current 
>> text:
>>  
>> OLD
>>  
>> It is acceptable to reuse the same revision statement within unpublished 
>> versions (i.e., Internet-Drafts), but the revision date MUST be updated to a 
>> higher value each time the Internet-Draft is re-posted.
>>  
>> —— 
>>  
>> It became clear from the subsequent discussion (thanks Randy!) that the 
>> above text isn’t intended to mean “reuse the identical revision statement, 
>> INCLUDING THE REVISION DATE” but to mean “reuse the revision statement, 
>> UPDATING THE REVISION DATE”.
>>  
>> Then other people raised other points, e.g only updating the revision date 
>> if the YANG has changed, distinguishing between the document and the YANG 
>> contained therein, and distinguishing between YANG in IDs and YANG created 
>> by other SDOs. My proposed new text tries to address all of these:
>>  
>> NEW:
>> 
>> It is not required to keep the full revision history of draft versions 
>> (e.g., modules contained within Internet-Drafts). That is, within a sequence 
>> of draft versions, only the most recent revision need be recorded in the 
>> module. However, if the module has changed, the revision date of the most 
>> recent revision MUST be updated to a later date whenever a new version is 
>> made available (e.g., via a new version of an Internet-Draft).
>>  
>> ——
>>  
>> I believe that this retains the original intent in a way that resolves the 
>> original ambiguity and addresses the other points that were raised. It it’s 
>> “worse”, how is it worse (apart from being longer, on which point mea culpa)?
>>  
>> Thanks,
>> William
>>  
>> On 19 Aug 2016, at 15:42, Andy Bierman  wrote:
>>  
>> On Fri, Aug 19, 2016 at 7:13 AM, Dale R. Worley  wrote:
>> Andy Bierman  writes:
>> > An Internet-Draft is NOT a means of "publishing" a specification;
>> 
>> As I said, that's the theory, but practice is considerably different.
>>  
>> Anybody that implements a work-in-progress knows they are taking a risk
>> on an unstable document.  The guideline already says MUST update
>> the revision date.
>>  
>> Not sure what more you want to guidelines document to do.
>>  
>> Dale
>>  
>> Andy
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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




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

[Balazs Lengyel]

Hello,

The problem is not just about identities. It can be a value range. 
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.


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.


regards Balazs


On 2016-08-31 12:38, Ladislav Lhotka wrote:

On 31 Aug 2016, at 11:10, Vladimir Vassilev  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


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

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







--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

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

Re: [netmod] RFC 6087bis guidance re use of revision statements indrafts

[Jonathan Hansford]

How about:

NEW:

It is not required to keep the full revision history of draft versions (e.g., 
modules contained within Internet-Drafts). That is, within a sequence of draft 
versions, only the most recent revision need be recorded in the module. 
However, whenever a new (i.e. changed) version is made available (e.g., via a 
new version of an Internet-Draft), the revision date of that new version MUST 
be updated to a date later than that of the previous version.

Jonathan

From: William Lupton___
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?

[Ladislav Lhotka]

> On 31 Aug 2016, at 11:10, Vladimir Vassilev  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

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

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




___
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] How to constrain a leaf to a read-only list of supported values?

[Martin Bjorklund]

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.

I think this is the only correct solution available today.  I.e.,
describe the behavior in description text, and/or add an extension
that makes this formal and machnie readable for your tools:

  leaf-list supported-compression-algorithm {
config false;
type eri:compression-algorithm;
description
  "Lists the compression algorithms supported by this device.";
  }

  leaf compression-algorithm {
config true;
type eri:compression-algorithm;
description
  "Must be one of the values listed in
   supported-compression-algorithm.";
eri:restrict-to "../supported-compression-algorithm";
  }

But I assume that the list of supported-compression-algorithm can
change with a software upgrade, and if so, how do you handle the case
that the config contains a value that is removed in a software
upgrade?


/martin


> 
> 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
> >
> 
> -- 
> Balazs Lengyel   Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com
> 
> ___
> 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] derived-from-or-self leads to circular import

[Balazs Lengyel]

  
  
Hello Bart,
A nice solution could be to separate ietf-entity into 2 yang
  modules (YAMs). One handling only generic entity stuff and another
  handling sensor related stuff. If  ietf-entity does not include
  any entity-type specific stuff it does not need to import
  iana-entity any more. This is how it works with ietf-interfaces
  and iana-if-type. Ietf-interfaces does not include anything that
  is if-type specific. Problem solved.
regards Balazs


On 2016-07-29 14:50, Bogaert, Bart
  (Nokia - BE) wrote:


  
  
  
  
Hi,
 
The IETF draft entity model has added the
  following:
   
container sensor-data {
 
when 'derived-from-or-self(../class,

"iana-entity", "sensor")' {
 
We already know that derived-from-or-self
  actually only has 2 parameters so it is expected to become
 
    container sensor-data {
  when 'derived-from-or-self(../class,
 "iana-entity:sensor")' {
 
In order to correctly compile (using
  confdc) we also need to import iana-entity for the identities
  defined in there.  However this is leading a circular
  dependency:
1.   Iana-entity
  imports ietf-entity (to ‘resolve’ entity-physical-class)
2.   Ietf-entity
  imports iana-entity (to obtain the indentities defined in
  there)
 
One way to solve this is to move the
  definition of entity-physical-class from ietf-entity to
  iana-entity which would resolve the fact that iana-entity
  requires an import of ietf-entity (ietf-entity needs to import
  iana-entity anyhow, so it can also pick the typedef from the
  same module too).
 
Whatever solution is chosen, the circular
  import needs to be resolved (or circular imports should be
  allowed – after all: what has been imported can be “tracked”
  removing the need to re-import something that was already
  imported).
 
Best regards - Vriendelijke groeten,
Bart Bogaert
Broadband-Access
System Architect Data
Contact
number +32 3 2408310 (+32 477 673952)
 
NOKIA
Copernicuslaan 50, 2018 Antwerp, Belgium
  Fortis 220-0002334-42
  VAT BE 0404 621 642 Register of Legal Entities Antwerp
  
  
<<
This message (including any attachments) contains
confidential information intended for a specific individual
and purpose, and is protected by law. If you are not the
intended recipient, you should delete this message. Any
disclosure, copying, or distribution of this message, or the
taking of any action based on it, is strictly prohibited
without the prior consent of its author.
>> 
 
  
  
  
  
  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



-- 
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 

  


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

[Balazs Lengyel]

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



--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

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