Hi, I originally brought up this issue in July 2015 https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/
I don't think the WG ever agreed on the problem that needs to be solved, and that is still the case. In reality each server has 1 package -- its entire library. The SEMVER work shows that vendors are treating platforms as independent release trains, and not really developing loadable packages. I think YANG 1.2 improvements for conformance (e.g., YANG-redirects, SEMVER import) and the YANG Catalog can solve the module compatibility issues. It is more of a documentation problem than a standards problem. Andy On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) < jason.ste...@nokia.com> wrote: > Thanks Rob. Please see inline. > > Jason > > > > *From:* Robert Wilton <rwil...@cisco.com> > *Sent:* Thursday, January 24, 2019 1:16 PM > *To:* Sterne, Jason (Nokia - CA/Ottawa) <jason.ste...@nokia.com>; > netmod@ietf.org > *Subject:* Re: initial comments on draft-rwilton-netmod-yang-packages > > > > Hi Jason, > > Thanks for the review and comments. > > I've put some responses inline ... > > On 24/01/2019 14:56, Sterne, Jason (Nokia - CA/Ottawa) wrote: > > Hi guys, > > > > I've gotten most of the way through the draft and have some initial > comments. I haven't digested the section 10 open issues yet or the examples. > > > > Section 5 mentions the following: > > YANG library is augmented to allow servers to report the packages > > that they implement and to associate those packages back to > > particular datastore schema. > > > > Does the combination of this draft and rfc7895bis somehow allow the same > package to be advertised in 2 different datastores, but with different > deviations in each datastore? I'm thinking of a case, for example, where a > package is fully supported in the running but the package minus a few > modules (or parts of modules) is supported in the operational datastore. > There seems to be a 1:1 relationship between package and rfc7895bis schema. > > So, the intention is no, not directly. > > My aim here is that <running> would implement package "foo", and > <operational> would implement package "modified-foo". Package > "modified-foo" would import package "foo" and also specify the set of > modules that contain the deviations "foo". > > I didn't want a server to be able to see that I implement package "foo", > but then I have all these deviations that change its behavior. Instead, it > is really implementing a different package that is based on "foo". > > > > > > The packages draft doesn't include any specific leaf-list for deviations. > Section 7.2 mentions that deviations could be expressed by including > modules that happen to contain deviations. That seems a bit inconsistent > with rfc7895bis that has a specific leaf-list of deviations (and NETCONF > hello that specifically explicitly labels deviation modules). > > I'm conflicted on this one. I don't really like the deviation list in > YANG library because I regard it as a duplicate source of information, and > then there is a question of which source of data do you trust. E.g. do you > process a deviation in a module that is not listed in the deviations module > list? > > *[>>JTS: ] Good point. I suppose this issue applies today already. i.e. > what if one of the modules advertised in the <hello> is a module of > deviations (without having been referenced by another module as a deviation > module).* > > > > > > Section 5.1 says the package must be referentially complete. I can see the > advantages of that although wondering if that might limit flexibility of > partitioning modules into packages. I could imagine use cases for dividing > a large set of modules into a few packages that might rev independently but > can still all work together (especially if they rev in a bc manner). But > maybe that just starts to introduce too much complexity? > > Yes, having partial packages may be useful. Perhaps just adding a leaf to > indicate whether a package is referentially complete could be the answer > here. > > > > > > I didn't understand this part of section 5.1. Can you maybe illustrate > with an example? > > The version/revision of a module listed in the package module list > > supercedes any version/revision of the module listed in a imported > > package module list. This allows a package to resolve any > > conflicting implemented module versions/revisions in imported > > packages. > > Probably best to see example B.3. in the appendix because it exactly > illustrates this point. > > Basically: > 1) Packages must explicitly list all versions of all modules they > define/import. > 2) If two imported packages define different versions of modules, then the > package that is importing them needs a way to define which version to use. > 3) A package needs a way to override the version of module specified in an > imported package. > > *[>>JTS: ] Thx. That example does help. I suppose the designer of the > package needs to carefully check that the version they select can be > successfully used by all the modules in the package. * > > *I think there is a minor typo in example B.3. The example-3-pkg is > importing "* *example-import-1" but I believe you meant "* > *example-import-1-pkg" > (and some for import-2).* > > > > It might be a good idea to add a parent-version to the package module (to > allow tracking lineage of packages). > > Agreed, or maybe allowing a revision history like modules. Not sure which > is better here. Packages could get a lot of updates, and a long revision > history would not be helpful at all. > > *[>>JTS: ] I think a minimum of just specifying the direct parent is > enough to build the full tree of lineage. We don't need a long history of N > revisions.* > > > > > > I like the use of groupings. That allows a manager to use this as a > building block to compose a model that has a list of packages. > > OK. > > > > > > Having a global list of mandatory features (vs having the mandatory > feature a per-module list) means inventing the new <module-name>:<feature> > format. Should we instead somehow put the mandatory features against each > module of the package? > > Perhaps. My thinking here was to have the list of features high up and > very easy to find/parse. > > > > > > The location leaf is a uri but then the description says it must be a url > (where the model can be retrieved). I do like that the namespace is > separate from the location, but maybe we should make location a url type? > > Yes, I was thinking that is should be a URL. > > > > > > Do we need a namespace for package names in the model? > > I had them in an earlier version, but I took them out, because I wasn't > sure that they are really useful/required. > > Defining a format to make package names themselves globally unique might > be sufficient. > > *[>>JTS: ] I'm OK with that. It is similar to how we're finding that it is > useful that YANG module names are globally unique (i.e. by naming with > ietf-xxxx or companyabc-xxx).* > > > > > > In 7.3 we only reference module-sets and not modules. So the grouping of > modules into sets and packages must be the same? > > Not necessarily. > > I am trying to reuse the module-set definitions as much as possible (to > avoid duplication). One issue here is that module-sets are combined then > all the modules must not overlap, which doesn't make the mapping to > module-sets quite so clean. > > > > > > A schema can only have a single package. I think that works but it means a > server would advertise multiple schemas if it wants to support multiple > packages. I'm not sure if there are some downsides to that (it just > surprised me). > > My aim here was: > - multiple packages are advertised in yang-library/packages > - datastores only report that they "implement" one [top level] package > version. [The package itself might import other packages.] > > If we do package selection, then for a given YANG client session, and the > version of YANG library available/reported by that session, it would appear > as if the server only implements one top level package for a datastore. > Different clients choosing different versions would see slightly different > output depending on which package version they had selected to use. > > Thanks again for the review and the comments! > > Rob > > > > > > > > Jason > > > > > > > > *From:* netmod <netmod-boun...@ietf.org> <netmod-boun...@ietf.org> *On > Behalf Of *Robert Wilton > *Sent:* Thursday, December 20, 2018 12:45 PM > *To:* netmod@ietf.org > *Subject:* [netmod] YANG Packages > > > > Hi, > > I've written up an ID for a potential solution for YANG packages using > instance data: > > Abstract > > > > This document defines YANG packages, an organizational structure > > holding a set of related YANG modules, that can be used to simplify > > the conformance and sharing of YANG schema. It describes how YANG > > instance data documents are used to define YANG packages, and how the > > YANG library information published by a server can be augmented with > > additional packaging related information. > > https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/ > > Potentially this work may be of use as part of the YANG versioning design > team work. In addition, if the WG likes this approach of defining YANG > packages, then it might also be useful to bind a schema to a YANG instance > data document. > > Some questions for members of the WG: > > 1) Do members of the WG agree that YANG packages is something that needs > to be solved? > > 2) Is the approach in this draft of defining these as instance data > documents a good starting point? > > 3) This approach augments YANG library-bis, reusing module-sets, but not > replacing the way that modules are reported in YANG library-bis. Is this > the right approach? This approach tries to allow module-sets to be reused > for both schema and packages, but the YANG library-bis rules for combining > module-sets (i.e. no conflicts) may make this harder to really reuse the > module-sets for both purposes. > > Of course, any other comments or feedback is welcome and appreciated. > > Thanks, > Rob > > _______________________________________________ > 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
