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

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 24 Jan 2019 14:56:45 +0000

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.

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

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?

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.

It might be a good idea to add a parent-version to the package module (to allow tracking lineage of packages).

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.

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?

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?

Do we need a namespace for package names in the model?

In 7.3 we only reference module-sets and not modules. So the grouping of modules into sets and packages must be the same?

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

Jason

From: netmod <[email-masked]> On Behalf Of Robert Wilton
Sent: Thursday, December 20, 2018 12:45 PM
To: [email-masked]
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

---

From: Robert Wilton <[email-masked]>
Date: Thu, 24 Jan 2019 18:16:21 +0000

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

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

> conflicting implemented module versions/revisions in imported
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.

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

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

> 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 <[email-masked]> *On Behalf Of *Robert Wilton
> *Sent:* Thursday, December 20, 2018 12:45 PM
> *To:* [email-masked]
> *Subject:* [netmod] YANG Packages
>
> Hi,
>
> 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.
>
> 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.
>

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 30 Jan 2019 00:55:24 +0000

Thanks Rob. Please see inline.
Jason

From: Robert Wilton <[email-masked]>
Sent: Thursday, January 24, 2019 1:16 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>; [email-masked]
Subject: Re: initial comments on draft-rwilton-netmod-yang-packages

Hi Jason,

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

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

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.

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

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.

OK.

Perhaps.  My thinking here was to have the list of features high up and very easy to find/parse.

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

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.

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.

Rob

Jason

From: netmod <[email-masked]><mailto:[email-masked]> On Behalf Of Robert Wilton
Sent: Thursday, December 20, 2018 12:45 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [netmod] YANG Packages

Hi,

Abstract

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Jan 2019 17:22:02 -0800

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) <
[email-masked]> wrote:

> *From:* Robert Wilton <[email-masked]>
> *Sent:* Thursday, January 24, 2019 1:16 PM
> *To:* Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]>;
> [email-masked]
> *Subject:* Re: initial comments on draft-rwilton-netmod-yang-packages
>
>
>
> Hi Jason,
>
> comments. I haven't digested the section 10 open issues yet or the examples.
>
>
>
> 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.
>
> 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).
>
> 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.
>
>
>
>
>
> 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.
> *[>>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).*
>
>
>
> 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.*
>
>
>
>
>
> 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?
>
> 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?
>
> *[>>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.
>
> 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
> 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:
> 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.
>
> *From:* netmod <[email-masked]> <[email-masked]> *On
> Behalf Of *Robert Wilton
> 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.
>
> 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.
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 30 Jan 2019 12:19:14 +0000

Hi Andy,

Thanks for the comments.

> https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-package/

Yes.

The solution I propose is different in the sense that it uses YANG 
instance data to define YANG packages rather than new YANG keywords.   I 
believe that this should make it a lower cost solution to define and 
implement.

> and that is still the case.

That wasn't quite my impression.  I also think that folks were busy 
focusing on other WG activity and didn't necessarily have the time to 
concentrate on this.

My draft was aiming on solving two broad problems:

    The main goals of YANG package definitions include, but are not
    restricted to:

    o  To act as a simplified YANG conformance mechanism.  Rather than
       conformance being performed against a set of individual YANG
       module revisions, conformance could also be more simply stated in
       terms of YANG packages, with a set modifications (e.g. additional
       modules, deviations, or features).

    o  To allow YANG datastore schema to be specified in a more concise
       way rather than having to list all modules and revisions.  YANG
       package definitions can be defined in documents that can be
       referenced by a URL rather than requiring explicit lists of
       modules to be shared between client and server.  Hence, a YANG
       package must contain sufficient information to allow a client or
       server to precisely construct the schema associated with the
       package.

>
> In reality each server has 1 package -- its entire library.

This doesn't apply to all servers.  For a long time, as a vendor, we 
have had separate packages that can be independently installed, and 
which extend the management model to cover the new functionality.  E.g. 
BNG functionality could be in a separate, independently installable, 
package on top of the base router functionality.

For a Linux server, the manageability interface will depend on what 
applications have been installed.

> The SEMVER work shows
> that vendors are treating platforms as independent release trains, and 
> not really

This depends on the vendor.  The YANG versioning work is trying to find 
a solution that works across the industry.  I believe that the 
versioning requirements are different for standards developed modules, 
vs industry developed modules, vs vendor modules.

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

Having a standard YANG module that can be used to define packages is 
something this is useful and should be standardized.  I believe that 
this is better than each vendor coming up with their own solution for 
this problem.

Thanks,
Rob

>
>
> Andy
>
>
>
>
> On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia - CA/Ottawa) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     *From:*Robert Wilton <[email-masked] <mailto:[email-masked]>>
>     *To:* Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>         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.
>
>         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
>     "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".
>
>         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
>     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.
>
>     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.
>     */[>>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?
>
>         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?
>
>     I had them in an earlier version, but I took them out, because I
>     wasn't sure that they are really useful/required.
>
>     */[>>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:
>      - 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.
>
>         *From:*netmod <[email-masked]>
>         <mailto:[email-masked]> *On Behalf Of *Robert Wilton
>         *To:* [email-masked] <mailto:[email-masked]>
>         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.
>
>         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.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Jan 2019 07:16:47 -0800

> believe that this should make it a lower cost solution to define and
I think yangvalidator.org has a better solution that does not change YANG
conformance.

Andy

> This doesn't apply to all servers.  For a long time, as a vendor, we have
> had separate packages that can be independently installed, and which extend
> the management model to cover the new functionality.  E.g. BNG
> functionality could be in a separate, independently installable, package on
> top of the base router functionality.
>
> This depends on the vendor.  The YANG versioning work is trying to find a
> solution that works across the industry.  I believe that the versioning
> requirements are different for standards developed modules, vs industry
> developed modules, vs vendor modules.
>
>
>
> something this is useful and should be standardized.  I believe that this
> is better than each vendor coming up with their own solution for this
> problem.
>
> Thanks,
> Rob
>
>
>
>
> Andy
>
>
>
>
>> 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?
>>
>> to indicate whether a package is referentially complete could be the answer
>> here.
>>
>>
>>
>>
>>
>> the package that is importing them needs a way to define which version to
>> use.
>> *[>>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
>> 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

---

From: Robert Wilton <[email-masked]>
Date: Wed, 30 Jan 2019 15:32:03 +0000

Hi Jason,

Please see inline [RW] ...

On 30/01/2019 00:55, Sterne, Jason (Nokia - CA/Ottawa) wrote:
> *From:*Robert Wilton <[email-masked]>
>     initial comments. I haven't digested the section 10 open issues
>     yet or the examples.
>
>     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.
>
> "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".
>
>     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).
>
> 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)./*
>
[RW]: One benefit of explicitly listing deviations would be that, if a 
package wanted to deviate some nodes in modules from an imported 
package, then it would be required to explicitly list the modules that 
was being deviated (along with the deviations).  So a reader of the 
package definition would be able to easily see that it is not using a 
100% faithful implementation of the imported package.

>     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?
>
> leaf to indicate whether a package is referentially complete could be 
> the answer here.
>
> */[>>JTS: ] Thx. That example does help. I suppose the designer of the 
> 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 "/* 
[RW]: I think that is an artifact of YANG instance data.  At the moment, 
the name of the YANG instance data file is "example-import-2-pkg", which 
defines the YANG package "example-import-2".  Possibly these names could 
be aligned to the same, but possibly that may be more confusing?

> *//*
> */[>>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./*
>
[RW]: Yes, I think that I agree.  This field could be optional to implement.

>     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.
>
>     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?
>
> */[>>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)./*
>
[RW]: Agreed.

Thanks,
Rob

> 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.
>
>     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:
> 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.
>
>     defining YANG packages, then it might also be useful to bind a
>     schema to a YANG instance data document.
>
>     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.
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Jan 2019 07:53:12 -0800

> I think yangvalidator.org has a better solution that does not change YANG

oops -- I meant yangcatalog.org

I don't agree that:

 (1) an instance document is easier for readers and writers.
It may be easier for tool makers, but that is subjective.
But the solution is irrelevant unless we agree on the problem first.

 (2) we need to specify YANG conformance for groups of modules

(3) it simplifies YANG to define conformance for modules and groups of
modules

(4) it is unclear how the packages are used by an operator

(5) the WG agreed on any problem to solve for which YANG packages is the
solution

Andy

>>> inconsistent with rfc7895bis that has a specific leaf-list of deviations
>>> (and NETCONF hello that specifically explicitly labels deviation modules).
>>>
>>> url (where the model can be retrieved). I do like that the namespace is
>>> 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.
>>>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 30 Jan 2019 16:02:02 +0000

On 30/01/2019 15:16, Andy Bierman wrote:
>
>
> On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Andy,
>
>     Thanks for the comments.
>
>     instance data to define YANG packages rather than new YANG
>     keywords.   I believe that this should make it a lower cost
>     solution to define and implement.
>
>
>
> I think yangvalidator.org <http://yangvalidator.org> has a better 
> solution that does not change YANG conformance.

Do you mean that we can just use zip files with the list of modules?

I don't really see how this helps.

Consider:
- server vendor A, implements some subset of the OpenConfig YANG 
modules, each at a particular version, along with some deviations and 
vendor augmentations.
- server vendor B, implements the same subset of the OpenConfig YANG 
modules, but at different versions, along with some deviations and 
vendor augmentations.
- server vendor C, implements a slightly different set of the OpenConfig 
YANG modules, but at different versions, along with some deviations and 
vendor augmentations.

As a client, how do I know what module versions to code against, when I 
want to work with devices provided by all three vendors?

I might be wrong, but I think that the OC solution is use git tags, so 
they tag sets of modules that are expected to work together and also to 
provide a linear release history of their sets of modules.  So, if 
everyone implements the module versions associated with a git tag then 
it should convert a two dimensional problem of module revisions into a 
linear problem.  The YANG packages draft is aiming to provide a solution 
to this problem that doesn't require the use of git, or sending zip 
files of modules around.

At the moment, it seems that everyone is doing this in different ways:
  - Yumawork customers/servers use zip files of modules for conformance.
  - OpenConfig client/server implementations use git tags, or git refpoints.
  - Cisco customers use the contents of directories on github YangModels.

Finally, this draft doesn't change YANG conformance, it just expresses 
it in what is intended to be a simpler way.

Thanks,
Rob

>     That wasn't quite my impression.  I also think that folks were
>     busy focusing on other WG activity and didn't necessarily have the
>     time to concentrate on this.
>
>     This doesn't apply to all servers.  For a long time, as a vendor,
>     we have had separate packages that can be independently installed,
>     and which extend the management model to cover the new
>     functionality.  E.g. BNG functionality could be in a separate,
>     independently installable, package on top of the base router
>     functionality.
>
>     For a Linux server, the manageability interface will depend on
>     what applications have been installed.
>
>
>>     The SEMVER work shows
>>     that vendors are treating platforms as independent release
>>     trains, and not really
>     This depends on the vendor.  The YANG versioning work is trying to
>     find a solution that works across the industry.  I believe that
>     the versioning requirements are different for standards developed
>     modules, vs industry developed modules, vs vendor modules.
>
>
>>
>>     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
>     Having a standard YANG module that can be used to define packages
>     is something this is useful and should be standardized.  I believe
>     that this is better than each vendor coming up with their own
>     solution for this problem.
>
>     Thanks,
>     Rob
>
>
>>
>>
>>     Andy
>>
>>
>>
>>
>>         *To:* Sterne, Jason (Nokia - CA/Ottawa)
>>         <[email-masked] <mailto:[email-masked]>>;
>>             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.
>>
>>             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
>>         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
>>         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?
>>
>>         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.
>>
>>         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.
>>         */[>>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.
>>
>>             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?
>>
>>             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?
>>
>>         I had them in an earlier version, but I took them out,
>>         because I wasn't sure that they are really useful/required.
>>
>>         */[>>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.
>>
>>         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:
>>          - 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.
>>
>>             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.
>>
>>             2) Is the approach in this draft of defining these as
>>             instance data documents a good starting point?
>>
>>             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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Jan 2019 09:31:06 -0800

> Do you mean that we can just use zip files with the list of modules?

I don't care about the solution details yet. They are 2nd order problems.

Conformance means "what modules are required to be implemented together".
It is not clear that this problem can be solved.  The augment-stmt defines
implicit
multi-module conformance.  I am not convinced that the extra work of
defining package conformance
is worth it.

The issue of what modules does vendor A implement is not a conformance
problem.
It is just more metadata and YANG Catalog is focused on providing that data.

>
> Consider:
> - server vendor A, implements some subset of the OpenConfig YANG modules,
> each at a particular version, along with some deviations and vendor
> augmentations.
> modules, but at different versions, along with some deviations and vendor
> augmentations.

The vendors publish their implementation details on yangcatalog and you get
the info
and see what modules are in common.

There are only market requirements determining what group of modules has to
exist
in an implementation.  It is not clear to me that formalizing these
requirements
is something the industry will do effectively.  Module tags already provide
a way
to conceptually group modules together.

Seems like every vendor has openconfig, foo-openconfig, and
foo-openconfig-deviations
so that there are no agreed upon subsets. Even if openconfig had properly
documented
subsets, would your client even be able to code to it (ignoring add-ons and
deviations).

I might be wrong, but I think that the OC solution is use git tags, so they
> tag sets of modules that are expected to work together and also to provide
> a linear release history of their sets of modules.  So, if everyone
> implements the module versions associated with a git tag then it should
> convert a two dimensional problem of module revisions into a linear
> problem.  The YANG packages draft is aiming to provide a solution to this
> problem that doesn't require the use of git, or sending zip files of
> modules around.
>

>  - Yumawork customers/servers use zip files of modules for conformance.

Not sure what this means.
Actually the server libraries can be loaded and unloaded.
Module can be standalone libraries or grouped as bundles.
But this seems like an implementation detail, unrelated to conformance.

> Finally, this draft doesn't change YANG conformance, it just expresses it
> in what is intended to be a simpler way.
>

It adds another conformance system to maintain.
The language only recognizes module to module interfaces, not package to
package.
That adds more complexity. It doesn't take away any complexity.

If there was a standard to load and unload modular functionality at
boot-time or run-time,
then I could see why there is a need to have a standard to define YANG
packages.

Andy

---

From: Robert Wilton <[email-masked]>
Date: Wed, 30 Jan 2019 18:04:00 +0000

On 30/01/2019 17:31, Andy Bierman wrote:
>
>
> On Wed, Jan 30, 2019 at 8:02 AM Robert Wilton <[email-masked] 
>>         The solution I propose is different in the sense that it uses
>>         YANG instance data to define YANG packages rather than new
>>         YANG keywords.   I believe that this should make it a lower
>>         cost solution to define and implement.
>>
>>
>>
> It is not clear that this problem can be solved.  The augment-stmt 
> defines implicit

So, I'm not proposing backing any sort of package conformance into the 
language at all.  A package is just metadata that defines that a set of 
modules, at particular revisions/versions, work together and can 
represent part of a YANG schema.

This is equivalent to
  - how a zip file of YANG modules provided to yangvalidator would work.
  - getting the contents of YANG library from a server (but a YANG 
packages soln can also work offline)
  - fetching the modules from YANG catalog (if they have been labelled 
appropriately), although I'm not convinced that this universally works 
today.

But in terms of the usability of YANG, I don't think that doing 
conformance only at the module level is really sufficient. Clients need 
to be coding against sets of modules at particular versions that are 
known to work together, and known that multiple server vendors will 
implement.

A pick and mix appropriate to module revisions doesn't seem to help anyone.

> It is just more metadata and YANG Catalog is focused on providing that 

Does YANG catalog indicate the set of IETF modules that I would need to 
implement L2VPN services on a device?

Module tags could be used to do this (another packaging solution), but 
this would cause a proliferation of tags when it comes to versioning, 
since I don't think that you can cleanly bake semver into module tags.

>     modules, each at a particular version, along with some deviations
>     and vendor augmentations.
>     - server vendor B, implements the same subset of the OpenConfig
>     YANG modules, but at different versions, along with some
>     deviations and vendor augmentations.
>     - server vendor C, implements a slightly different set of the
>     OpenConfig YANG modules, but at different versions, along with
>     some deviations and vendor augmentations.
>
>     As a client, how do I know what module versions to code against,
>     when I want to work with devices provided by all three vendors?
>
>
>
> The vendors publish their implementation details on yangcatalog and 
> you get the info
> There are only market requirements determining what group of modules 
> has to exist
> is something the industry will do effectively.  Module tags already 
> provide a way
> so that there are no agreed upon subsets. Even if openconfig had 
> properly documented
> subsets, would your client even be able to code to it (ignoring 
> add-ons and deviations).

I think that answer will converge on yes, I don't know how long it will 
take.  It would probably be better if at the time that protocol 
specifications are written, that the authors of the specifications also 
write the YANG modules to manage them at the same time.

>
>     I might be wrong, but I think that the OC solution is use git
>     tags, so they tag sets of modules that are expected to work
>     together and also to provide a linear release history of their
>     sets of modules.  So, if everyone implements the module versions
>     associated with a git tag then it should convert a two dimensional
>     problem of module revisions into a linear problem.  The YANG
>     packages draft is aiming to provide a solution to this problem
>     that doesn't require the use of git, or sending zip files of
>     modules around.
>
>
>     Finally, this draft doesn't change YANG conformance, it just
>     expresses it in what is intended to be a simpler way.
>
>
> The language only recognizes module to module interfaces, not package 
> to package.

I propose that at the language level conformance is at the module level 
(modulo import-by-version).

> That adds more complexity. It doesn't take away any complexity.

It is meant to be a simpler way of packaging up, and trying to control 
and manage the complexity that already exists today.

E.g. I could give a YANG compiler the name, version, and location of a 
package and tell it to build the entire schema associated with that 
package.

In a somewhat similar way, when I write code, my build file specifies 
which libraries I depend on, and their versions, but I can leave it to 
the build tool to determine what those libraries themselves depend on 
and recursively pull in all the dependencies.

> then I could see why there is a need to have a standard to define YANG 

I agree that this is another example of where they could be useful.

Thanks,
Rob

>>         That wasn't quite my impression.  I also think that folks
>>         were busy focusing on other WG activity and didn't
>>         necessarily have the time to concentrate on this.
>>
>>         This doesn't apply to all servers.  For a long time, as a
>>         vendor, we have had separate packages that can be
>>         independently installed, and which extend the management
>>         model to cover the new functionality.  E.g. BNG functionality
>>         could be in a separate, independently installable, package on
>>         For a Linux server, the manageability interface will depend
>>         on what applications have been installed.
>>
>>
>>>         The SEMVER work shows
>>         This depends on the vendor.  The YANG versioning work is
>>         trying to find a solution that works across the industry.  I
>>         believe that the versioning requirements are different for
>>         standards developed modules, vs industry developed modules,
>>         vs vendor modules.
>>
>>
>>>
>>>         and  the YANG Catalog can solve the module compatibility
>>>         issues. It is more of a documentation
>>         Having a standard YANG module that can be used to define
>>         packages is something this is useful and should be
>>         standardized.  I believe that this is better than each vendor
>>         coming up with their own solution for this problem.
>>
>>         Thanks,
>>         Rob
>>
>>
>>>
>>>
>>>         Andy
>>>
>>>
>>>
>>>
>>>         On Tue, Jan 29, 2019 at 4:55 PM Sterne, Jason (Nokia -
>>>         CA/Ottawa) <[email-masked]
>>>         <mailto:[email-masked]>> wrote:
>>>
>>>             <[email-masked]
>>>                 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.
>>>
>>>                 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.
>>>
>>>             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
>>>             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)./*
>>>
>>>                 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
>>>             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.
>>>
>>>             Probably best to see example B.3. in the appendix
>>>             because it exactly illustrates this point.
>>>
>>>             Basically:
>>>             modules, then the package that is importing them needs a
>>>             way to define which version to use.
>>>             designer of the package needs to carefully check that
>>>             the version they select can be successfully used by all
>>>             the modules in the package. /*
>>>
>>>             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?
>>>
>>>             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
>>>                 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:
>>>             level] package version.  [The package itself might
>>>             import other packages.]
>>>
>>>             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
>>>                 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
>>>                 2) Is the approach in this draft of defining these
>>>                 as instance data documents a good starting point?
>>>
>>>                 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.
>>>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Jan 2019 12:51:59 -0800

On Wed, Jan 30, 2019 at 10:04 AM Robert Wilton <[email-masked]> wrote:

>> I think yangvalidator.org has a better solution that does not change
>> YANG conformance.
>>
> modules, at particular revisions/versions, work together and can represent
> part of a YANG schema.
>
> This is equivalent to
>  - getting the contents of YANG library from a server (but a YANG packages
> soln can also work offline)
This sort of metadata could be provided by module tags.
A vendor or SDO could define module-tags that represent packages.

> conformance only at the module level is really sufficient.  Clients need to
> be coding against sets of modules at particular versions that are known to
> work together, and known that multiple server vendors will implement.
>
I get all the different components and variables one might have for a
package.
I am not as convinced (as in 2015) that standard packages could be simple
and widely deployed..
Now it seems vendors implement an ad-hoc subset + additions to everything.
It doesn't help to define a new package variant to match the vendor
implementation.
The YANG library can do that already.

You seem more optimistic than me that the industry is actually ready,
willing, and able
to implement standard YANG packages.

> implement L2VPN services on a device?
This seems like a separate problem, but actually it can help by searching a
lot of known modules.
In order to know what vendor A, B, and C have in common, you need to get
the catalog info for each vendor.

Module tags can also solve this problem.

> this would cause a proliferation of tags when it comes to versioning, since
> I don't think that you can cleanly bake semver into module tags.
>
>
>
> The vendors publish their implementation details on yangcatalog and you
> get the info
> There are only market requirements determining what group of modules has
> to exist
> subsets, would your client even be able to code to it (ignoring add-ons
> and deviations).
>
>> provide a linear release history of their sets of modules.  So, if everyone
> It is meant to be a simpler way of packaging up, and trying to control and
> manage the complexity that already exists today.
>

This is a tool implementation detail, not a conformance issue.
It would be nice to have a standard format for the YANG library for a tool
to use.
You seem to be proposing an artifact containing ietf-yang-library
information.
That seems OK to me, but it should not have anything to do with conformance.
It is just a standard way to express a module-set in a yang-data artifact.

> which libraries I depend on, and their versions, but I can leave it to the
> build tool to determine what those libraries themselves depend on and
> recursively pull in all the dependencies.
>
>
>
Andy

>>> have had separate packages that can be independently installed, and which
>>> extend the management model to cover the new functionality.  E.g. BNG
>>> a solution that works across the industry.  I believe that the versioning
>>>> same package to be advertised in 2 different datastores, but with different
>>>> Instead, it is really implementing a different package that is based on
>>>> "foo".
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> multiple packages. I'm not sure if there are some downsides to that (it
>>>> just surprised me).
>>>>
>>>> My aim here was:
>>>> 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

---

From: Robert Wilton <[email-masked]>
Date: Thu, 31 Jan 2019 17:24:18 +0000

On 30/01/2019 20:51, Andy Bierman wrote:
>
>
> On Wed, Jan 30, 2019 at 10:04 AM Robert Wilton <[email-masked] 
>>>         On Wed, Jan 30, 2019 at 4:19 AM Robert Wilton
>>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>             Hi Andy,
>>>
>>>             Thanks for the comments.
>>>
>>>             The solution I propose is different in the sense that it
>>>             uses YANG instance data to define YANG packages rather
>>>             than new YANG keywords.   I believe that this should
>>>             make it a lower cost solution to define and implement.
>>>
>>>
>>>
>>>         I think yangvalidator.org <http://yangvalidator.org> has a
>>>         better solution that does not change YANG conformance.
>>
>>     It is not clear that this problem can be solved.  The
>>     augment-stmt defines implicit
>>     multi-module conformance.  I am not convinced that the extra work
>>     of defining package conformance
>>     is worth it.
>
>     So, I'm not proposing backing any sort of package conformance into
>     the language at all.  A package is just metadata that defines that
>     a set of modules, at particular revisions/versions, work together
>     and can represent part of a YANG schema.
>
>     This is equivalent to
>      - fetching the modules from YANG catalog (if they have been
>     labelled appropriately), although I'm not convinced that this
>     universally works today.
>
>

Yes, this is a different way to assigning membership, although I'm not 
convinced that it is better.

I think that such a scheme could work without versioning, but I'm not 
sure that it will work so well once package versioning is considered, 
because to handle versioning the tags don't just need to represent which 
package they belong to, they also should identify which version of that 
package.

E.g. [email-masked] might be tagged with:
"[email-masked]", "[email-masked]", "[email-masked]", 
[email-masked]", ...

If packages change quite frequently then you might find that a module 
needs 50+ tags to identify which particular packages it belongs to.

Any without knowing the package version, I don't see that there would be 
enough information to build a schema since you wouldn't know which 
versions of YANG modules to use.

>     conformance only at the module level is really sufficient. 
>     Clients need to be coding against sets of modules at particular
>     versions that are known to work together, and known that multiple
>     server vendors will implement.
>
> I am not as convinced (as in 2015) that standard packages could be 
> simple and widely deployed..

YANG library is only on the box at the moment, and it just gives a flat 
list of modules.
I would like it to also be available off the box and have more structure.

E.g. I would like IETF to define an L2VPN package that contains the 
basic set of YANG modules that a device that supports L2VPN services 
would be expected to implement at a minimum.

Then, rather that checking the output of YANG library to see that it has 
all the necessary modules to implement an L2VPN service, I could instead 
check whether the package implemented by the device imports the L2VPN 
package.  And if it does import that package, I can then also see which 
version of that package it implements (rather than checking every module 
version).

> to implement standard YANG packages.

If we want YANG to be properly successful then I see that it has go 
there.  But nobody can do this today until there is a way that such 
packages can be defined, and versioned, and we start defining what these 
standard packages look like.

>
>
>
>>
>>     The issue of what modules does vendor A implement is not a
>>     conformance problem.
>     Does YANG catalog indicate the set of IETF modules that I would
>     need to implement L2VPN services on a device?
>
>
> This seems like a separate problem, but actually it can help by 
> searching a lot of known modules.
> In order to know what vendor A, B, and C have in common, you need to 
> get the catalog info for each vendor.
>

But when there are multiple vendors with multiple devices, with multiple 
versions of software available then this looks like a hard problem to solve.

I would like someone (or a program) to be able to look at a package 
definition file, and determine if it implements what is required, and 
what software version is needed, and whether they are deviations that 
matter.

When my client then connects to that device, I would like the client to 
be able to check that it implements that modules that I expect it to.  I 
would strongly prefer if this could be done by returning a small amount 
of data, rather than a list of 1000 modules/sub-modules for every server 
that I connect to.

Module tags won't tell the client that it implements all the required 
modules that implement the L2VPN service, it will just indicate that 
implements some modules which can be used to implement an L2VPN service.

>     Module tags could be used to do this (another packaging solution),
>     but this would cause a proliferation of tags when it comes to
>     versioning, since I don't think that you can cleanly bake semver
>     into module tags.
>
>
>>
>>         - server vendor A, implements some subset of the OpenConfig
>>         YANG modules, each at a particular version, along with some
>>         - server vendor B, implements the same subset of the
>>         OpenConfig YANG modules, but at different versions, along
>>         with some deviations and vendor augmentations.
>>         OpenConfig YANG modules, but at different versions, along
>>         with some deviations and vendor augmentations.
>>
>>         As a client, how do I know what module versions to code
>>         against, when I want to work with devices provided by all
>>         three vendors?
>>
>>
>>
>>     The vendors publish their implementation details on yangcatalog
>>     and you get the info
>>     There are only market requirements determining what group of
>>     modules has to exist
>>     in an implementation.  It is not clear to me that formalizing
>>     these requirements
>>     is something the industry will do effectively. Module tags
>>     already provide a way
>     I think that answer will converge on yes, I don't know how long it
>     will take.  It would probably be better if at the time that
>     protocol specifications are written, that the authors of the
>     specifications also write the YANG modules to manage them at the
>     same time.
>
>>
>>         together and also to provide a linear release history of
>>         their sets of modules.  So, if everyone implements the module
>>         versions associated with a git tag then it should convert a
>>         two dimensional problem of module revisions into a linear
>>         problem.  The YANG packages draft is aiming to provide a
>>         solution to this problem that doesn't require the use of git,
>>         or sending zip files of modules around.
>>
>>
>>     The language only recognizes module to module interfaces, not
>>     package to package.
>
>     I propose that at the language level conformance is at the module
>     level (modulo import-by-version).
>
>
>     It is meant to be a simpler way of packaging up, and trying to
>     control and manage the complexity that already exists today.
>
>     E.g. I could give a YANG compiler the name, version, and location
>     of a package and tell it to build the entire schema associated
>     with that package.
>
>
> It would be nice to have a standard format for the YANG library for a 
> tool to use.

Yes, what I am proposing is close to a file containing ietf-yang-library 
information, but I want it to be hierarchical/recursive, where as the 
schema defined by YANG library bis is flat, and I want the data to also 
optionally be made available in YANG library.

What I am proposing here doesn't change conformance of the YANG language 
in any way, not does it replace YANG library.

Thanks,
Rob

>
>
>     In a somewhat similar way, when I write code, my build file
>     specifies which libraries I depend on, and their versions, but I
>     can leave it to the build tool to determine what those libraries
>     themselves depend on and recursively pull in all the dependencies.
>
>
>>
>>     If there was a standard to load and unload modular functionality
>>     at boot-time or run-time,
>>     then I could see why there is a need to have a standard to define
>>     YANG packages.
>
>>>             That wasn't quite my impression.  I also think that
>>>             folks were busy focusing on other WG activity and didn't
>>>             model to cover the new functionality.  E.g. BNG
>>>             functionality could be in a separate, independently
>>>             installable, package on top of the base router
>>>             functionality.
>>>
>>>             For a Linux server, the manageability interface will
>>>             depend on what applications have been installed.
>>>
>>>
>>>>             The SEMVER work shows
>>>>             that vendors are treating platforms as independent
>>>>             release trains, and not really
>>>             trying to find a solution that works across the
>>>             industry.  I believe that the versioning requirements
>>>             are different for standards developed modules, vs
>>>             industry developed modules, vs vendor modules.
>>>
>>>
>>>>
>>>>             and  the YANG Catalog can solve the module
>>>>             compatibility issues. It is more of a documentation
>>>             standardized.  I believe that this is better than each
>>>             vendor coming up with their own solution for this problem.
>>>
>>>             Thanks,
>>>             Rob
>>>
>>>
>>>>
>>>>
>>>>             Andy
>>>>
>>>>
>>>>
>>>>
>>>>                     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.
>>>>
>>>>                     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
>>>>                 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
>>>>                 really implementing a different package that is
>>>>                 based on "foo".
>>>>
>>>>                     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
>>>>                     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?
>>>>
>>>>                     I didn't understand this part of section 5.1.
>>>>                     Can you maybe illustrate with an example?
>>>>
>>>>                 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.
>>>>                 */[>>JTS: ] Thx. That example does help. I suppose
>>>>                 the designer of the package needs to carefully
>>>>                 check that the version they select can be
>>>>                 */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 "/*
>>>>                     It might be a good idea to add a parent-version
>>>>                     to the package module (to allow tracking
>>>>                     lineage of packages).
>>>>
>>>>                 modules. Not sure which is better here.  Packages
>>>>                 could get a lot of updates, and a long revision
>>>>                 */[>>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.
>>>>
>>>>                     format. Should we instead somehow put the
>>>>                     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?
>>>>
>>>>                 I had them in an earlier version, but I took them
>>>>                 out, because I wasn't sure that they are really
>>>>                 useful/required.
>>>>
>>>>                 */[>>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)./*
>>>>
>>>>                     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
>>>>                     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:
>>>>                  - 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.
>>>>
>>>>                     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
>>>>                     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.
>>>>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 31 Jan 2019 09:45:04 -0800

Hi,

I can see some utility in a module-set artifact.
Every tool has a different way of specifying a set of [module, revision,
features, deviations].
The module-set has these parameters (plus other metadata)

    rc:yang-data module-set {
      container module-set {
          uses yanglib:module-set-parameters;
       }
    }

The application purpose of the module-set is not relevant here.
It could be the library subset needed for L2VPN, it could be the entire
module list
for a specific vendor/model/version. It could be the module-set needed
to reproduce a bug.

Andy

On Thu, Jan 31, 2019 at 9:24 AM Robert Wilton <[email-masked]> wrote:

> I think that such a scheme could work without versioning, but I'm not sure
> that it will work so well once package versioning is considered, because to
> handle versioning the tags don't just need to represent which package they
> belong to, they also should identify which version of that package.
>
> "[email-masked]" <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]" <[email-masked]>,
> enough information to build a schema since you wouldn't know which versions
> of YANG modules to use.
>
>
>
>
>
>
> E.g. I would like IETF to define an L2VPN package that contains the basic
> set of YANG modules that a device that supports L2VPN services would be
> expected to implement at a minimum.
>
> This seems like a separate problem, but actually it can help by searching
> a lot of known modules.
> definition file, and determine if it implements what is required, and what
> software version is needed, and whether they are deviations that matter.
>
> When my client then connects to that device, I would like the client to be
> able to check that it implements that modules that I expect it to.  I would
> strongly prefer if this could be done by returning a small amount of data,
> rather than a list of 1000 modules/sub-modules for every server that I
> connect to.
>
>>>>> *[>>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
>>>>> leaf to indicate whether a package is referentially complete could be the
>>>>> answer here.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *[>>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).*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> (to avoid duplication).  One issue here is that module-sets are combined