Re: [Netmod-ver-dt] YANG packages draft

["Sterne, Jason (Nokia - CA/Ottawa)" <[e-mail]>]

The split at the top level sounds like a good idea.

Let's put them in separate YANG modules.

From: Netmod-ver-dt <[e-mail]> On Behalf Of Rob Wilton (rwilton)
Sent: Thursday, January 23, 2020 5:27 AM
To: Rob Wilton (rwilton) <[e-mail]>; [e-mail]
Subject: Re: [Netmod-ver-dt] YANG packages draft

One further thought on the updates that I made to the packages draft:

Currently the "packages" top-level container and the YANG library augmentation are in the same YANG module (and hence they have a dependency on the RFC 8525 version of YANG library).  I wonder whether it would be better to split these into two separate modules, i.e. allowing the packages solution to coexist with the older version of YANG library RFC 7995)?

Any thoughts on this?

Thanks,
Rob


From: Netmod-ver-dt <[e-mail]<mailto:[e-mail]>> On Behalf Of Rob Wilton (rwilton)
Sent: 22 January 2020 16:31
To: [e-mail]<mailto:[e-mail]>
Subject: [Netmod-ver-dt] YANG packages draft

FYI, I've updated the YANG packages draft with the updated YANG model structure that we discussed previously and were using, and changed the way that the model is described (i.e. reference the common structure of the grouping).

I've made one further change which is to root the package list under a "packages" top level container rather than augmenting YANG library as was done previously.  I think that this probably makes YANG library more user friendly (so that clients querying YANG library don't suddenly get all the packages information that mostly they should not need - given the desire for packages information to be available offline).  I think that this probably also helps with YANG packages, since clients won't need to necessarily get the duplicate module list information in YANG library, and it also allows the package information to be included (e.g. in an instance-data document) without the YANG library information.

I've pushed the updates to my github rgwilton/YANG-Packages-Draft repository (so that you can easily see the history of what has changed), and also to the yang-ver-dt repository, which I propose that we use for this document going forward.

I've also been resolving/closing some of the open issues at github rgwilton/YANG-Packages-Draft repository.  For the ones that I think that we need to still keep open, I will copy them to the yang-ver-dt repository, so that everything is in one place, and anyone can easily update.

The examples in this draft still need to be updated, which would be nice to do before an adoption call, but is not critical.

Any comments, concerns, etc, please let me know, or raise them in tomorrow's meeting.

Thanks,
Rob