Hi Jason,
Please see inline [RW] ...
On 30/01/2019 00:55, Sterne, Jason (Nokia - CA/Ottawa) wrote:
Thanks Rob. Please see inline.
Jason
*From:*Robert Wilton <rwil...@cisco.com>
*Sent:* Thursday, January 24, 2019 1:16 PM
*To:* Sterne, Jason (Nokia - CA/Ottawa) <jason.ste...@nokia.com>;
netmod@ietf.org
*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)./*
[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?
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)./*
[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?
*//*
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./*
[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.
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)./*
[RW]: Agreed.
Thanks,
Rob
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>
<mailto:netmod-boun...@ietf.org> *On Behalf Of *Robert Wilton
*Sent:* Thursday, December 20, 2018 12:45 PM
*To:* netmod@ietf.org <mailto: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
