Thanks Rob. Please see inline.
Jason
From: Robert Wilton <[email protected]>
Sent: Thursday, January 24, 2019 1:16 PM
To: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]>; [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]
https://www.ietf.org/mailman/listinfo/netmod
