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