Re: [netmod] 3 RFCs in 1 day!

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

[netmod] 3 RFCs in 1 day!

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

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

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:

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

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:

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

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

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

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

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

[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

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

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"

Re: [netmod] How to constrain a leaf to a read-only list of supported values?

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

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

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

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

> 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

Re: [netmod] How to constrain a leaf to a read-only list of supported values?

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

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

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

Re: [netmod] How to constrain a leaf to a read-only list of supported values?

> 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

Re: [netmod] How to constrain a leaf to a read-only list of supported values?

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

Re: [netmod] How to constrain a leaf to a read-only list of supported values?

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

Re: [netmod] derived-from-or-self leads to circular import

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

Re: [netmod] How to constrain a leaf to a read-only list of supported values?

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