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?
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.
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.
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 <netmod-boun...@ietf.org> *On Behalf Of *Robert Wilton
*Sent:* Thursday, December 20, 2018 12:45 PM
*To:* netmod@ietf.org
*Subject:* [netmod] YANG Packages
Hi,
I've written up an ID for a potential solution for YANG packages using
instance data:
Abstract
This document defines YANG packages, an organizational structure
holding a set of related YANG modules, that can be used to simplify
the conformance and sharing of YANG schema. It describes how YANG
instance data documents are used to define YANG packages, and how the
YANG library information published by a server can be augmented with
additional packaging related information.
https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/
Potentially this work may be of use as part of the YANG versioning
design team work. In addition, if the WG likes this approach of
defining YANG packages, then it might also be useful to bind a schema
to a YANG instance data document.
Some questions for members of the WG:
1) Do members of the WG agree that YANG packages is something that
needs to be solved?
2) Is the approach in this draft of defining these as instance data
documents a good starting point?
3) This approach augments YANG library-bis, reusing module-sets, but
not replacing the way that modules are reported in YANG library-bis.
Is this the right approach? This approach tries to allow module-sets
to be reused for both schema and packages, but the YANG library-bis
rules for combining module-sets (i.e. no conflicts) may make this
harder to really reuse the module-sets for both purposes.
Of course, any other comments or feedback is welcome and appreciated.
Thanks,
Rob
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
