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