Minutes interim-2017-netconf-01: Wed 10:00
||Minutes interim-2017-netconf-01: Wed 10:00
NETCONF Interim Meeting - December 13, 2017 7-9 a.m. PST.
YANG Library Options:
File size: 75.34MB
Duration: 1 hour 46 minutes
Streaming recording link:
Download recording link:
Review YANG Library proposals
This presentation will also go over topics raised during the IETF 100 meeting
- Line card insertion/deletion
- Semantic versioning
LL: Ladislav Lhotka
RW: Robert Wilton
MB: Martin Björklund
ME: Mehmet Ersue
KW: Kent Watsen
AB: Andy Bierman
CB: Carsten Bormann
EV: Erik Voit
EN: Einar Nilsen-Nygaard
IB: Igor Bryskin
JT: Jeff Tantsura
SM: Scott Mansfield
XL: Xufeng Liu
JS: Juergen Schoenwaelder
AM: Ashesh Mishra
SB: Stephen Banghard (?)
MJ: Mahesh Jethanandani
LL: Does the RFC 7950 section 5.6.5 requirement (one revision of a module
in a server) apply to schema mount? RW: This would make constraints
checking very hard. A device could change YANG library based on what
linecards are plugged in, or alternative have a single schema that is a
superset of all possible lincards. MB: Any comments on the different
proposals (RPC, or YANG library as operational data, or one version of YANG
library per datastore). LL: Likes the idea of using a RPC. MB: How would
the RPC that work? LL: Single RPC that gets everything, (e.g. one of the
structures that has been discussed). Same RPC in the form of an action
could be used for schema mount. JS: Would need to execute the RPC/action
for every mountpoint. MB: Actions are associated to data in , so how to
obtain schema information for a mount point in a configuration datastore?
Also how is the checksum handled? RPC would give you everything unless
there are filter parameters on the RPC. MB: What about using separate
meta-data datastores to provide the yang library information for other
regular datastores? JS: This is expensive given the current set of protocol
operations we have, requires N roundtrips for N datastores. MB: Anybody
here to speak in favour of the meta-data datastore solution? [nobody did
Martin presenting on alternative 1:
KW: What is the checksum for under the schema?
MB: The checksum represents the checksum for a particular schema, so that
if a module in particular schema changed then the checksum for that schema
would change, along with the top level checksum. Top level checksum can
get sent in the capabilities message. KW: What if the top level schema
changes for another reason. MB: Then the top level checksum changes. IB: Do
we always have one schema per datastore? MB: Yes.
Martin presenting on alternative 2:
LL: The client can use a checksum to see that nothing has changed.
MB: Checksum can be used for all solutions. Have to code for the startup
case. XL?: Where does the name of the module-set come from. MB: The server
makes up the name for the module-set and the schema. KW: May be a downside,
a schema could point to more than one module-set. How are conflicts
handled. MB: Combining module-sets don't allow any conflicts, just one
module. IB: How do you deal with modules that don't fit into module-sets?
... missed some of these questions ... MB: Two different schema can point
to the same module sets. LL: Different solution of Y?L draft, a schema
could point to another schema or just modules. E.g. allow schema to
recurse rather than having module-sets. IB: Likes this option.
Martin is presenting on alternative 3:
(What is in current bis draft -02)
MB: Harder for a client to get the data (extra level of indirection), list
is perhaps a bit less obvious. LL: Instead the schema list, it could
reference another schema. IB: Do we have to limit to only implementing a
single module in a schema. MB: Server reports what it can do, and will
onnly report a single revision if it is following the rules. IB: What about
an older client? MB: The model is only reporting what the server is doing.
JS: YANG update rules means that an old client can talk to a new server.
Discussion on the different options:
JS: Do we need to discuss licensing and sem-versioning?
MB: Server has different license options, and a client can enable different
licenses. MB: Alternative C doesn't really support the idea of a license
representing a set of modues. XL: Module sets could have comflicting
versions. MJ: Does that rule option 3 out? LL: Thinking about schema mount,
different VMs could have different features enabled. KW: Nice if licenses
lined up with just features, but questionable for vendors; similarly for
modules. MJ: License is for a module or a set of modules. IB: Could this be
done by a separate module? E.g. replicating the structure, and put it
somewhere else. JS: You need extra information for licensing so would
likely have a separate module, but still helpful to refer back to a module
set. LL: Module-sets shouldn't be restricted to just referencing a single
version of a module, that rule should perhaps be expressed in the protocol.
AB: I do not like the yang library proposals because they allow a server to
report something that is forbidden by MUSTs LL: Some of the flexibility is
needed to support schema mount. AB: I do not think schema mount is the
right solution for management virtualized systems. MB: A MUST applies
regardless whether the MUST is enforced by a data model structure. Even
simple models have situations where MUSTs are not always expressed in the
Which do you you prefer?
1.7 Alt B (ds -> schema -> module-set)
1.9 Alt A (ds -> schema)
2.7 Alt C (ds -> schema -> module-id)
4.0 Alt D ( rpc)
5.4 Alt E (yang-library per datastore?)
AB: I voted for the order in which things were shown (A,B,C,D,E, other) but
my vote is not in favor of any of these proposals.
Should licensing be considered now?
Should h/w insertion/removal be considered now?
Should sem-ver be considered now?