Re: [netmod] initial comments on draft-rwilton-netmod-yang-packages

[Andy Bierman <[e-mail]>]

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) <
[e-mail]> wrote:

> Thanks Rob. Please see inline.
>
> Jason
>
>
>
> *From:* Robert Wilton <[e-mail]>
> *Sent:* Thursday, January 24, 2019 1:16 PM
> *To:* Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]>;
> [e-mail]
> *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 <[e-mail]> <[e-mail]> *On
> Behalf Of *Robert Wilton
> *Sent:* Thursday, December 20, 2018 12:45 PM
> *To:* [e-mail]
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>