Martin,
Thanks for raising this, there's definitely some open issues as well as
confusion on this topic. In the different options listed below you say that
each datastore refers to a schema, correct? What is the mechanism you would
use to do this?
In talking to some others on this topic, they suggested using a library per
datastore. I haven't look into this enough to know if that is a good or bad
idea, but it seems functionally equivalent to your first option but
realized in a different way. Just something to add to the mix.
Lou
On December 8, 2017 4:48:15 AM Martin Bjorklund <[email protected]> wrote:
Hi,
There has been quite a lot of discussion about the YANG library
data model on the list. The authors of draft-ietf-netconf-rfc7895bis
have tried to understand all arguments in the discussion, and provide
a solution. Below are 3 solution proposals (we have discussed more,
but they are basically just variations on the same themes).
Absolute Requirements
---------------------
o RFC 7950, Section 5.6.5 says:
A server MUST NOT implement more than one revision of a module.
o draft-ietf-netmod-revised-datastores says:
The conventional configuration datastores [...] share exactly
the same datastore schema
o draft-ietf-netmod-revised-datastores says:
The datastore schema for <operational> MUST be a superset of the
combined datastore schema used in all configuration datastores
except that YANG nodes supported in a configuration datastore MAY
be omitted from <operational> if a server is not able to
accurately report them.
These requirements (of course) still hold, and we think that the YANG
library document should explain what they imply for the data reported
as part of the library. (For example, all conventional datastores
MUST have a reference to the same "schema").
Objectives (in no particular order)
-----------------------------------
1. As efficient as possible for a client to consume.
Since the size of the yang library can be quite large, it should
be possible for clients to cache the yang library information.
2. A dynamic datastore must be able to implement a module or feature
that is not implemented in the conventional datastores.
3. It must be possible to NOT implement a module or feature in
operational, even if it is implemented in some other datastore.
This is required for transition purposes; a server that wants to
implement <operational> should not have to implement all modules at
once.
4. A given module can only be implemented in one revision in all
datastores. If a module is implemented in more than one
datastores, the same revision is implemented in all these
datastores.
5. Multiple revisions can be used for import, if import-by revision
is used.
6. Nice to have: make it possible to be used by schema mount
It should be noted that because of 2 and 3 (and 6), the original data
model in RFC 7895 cannot be used.
Use Cases
---------
Here's a set of use cases that must be supported.
C1. conventional + operational, all have the same schema
C2. conventional + operational, ietf-hardware is not implemented in
conventional
C3. conventional + operational, some modules not yet implemented in
operational, and some modules are partly implemented in
operational.
C4. conventional + operational + ephemeral, ephemeral has its own
set of modules
Alt. A.
-------
Each datastore refers to a schema, and each schema contains a flat
list of all modules, features, etc.
+--ro yang-library
+--ro schema* [name]
| +--ro name string
| +--ro checksum string
| +--ro module* [name]
| | +--ro name yang:yang-identifier
| | +--ro revision? revision-identifier
| | +--ro namespace inet:uri
| | +--ro location* inet:uri
| | +--ro submodule* [name]
| | | +--ro name yang:yang-identifier
| | | +--ro revision? revision-identifier
| | | +--ro location* inet:uri
| | +--ro feature* [name]
| | | +--ro name yang:yang-identifier
| | +--ro deviation* [module]
| | +--ro module -> ../../name
| +--ro import-only-module* [name revision]
| +--ro name yang:yang-identifier
| +--ro revision union
| +--ro namespace inet:uri
| +--ro location* inet:uri
| +--ro submodule* [name]
| +--ro name yang:yang-identifier
| +--ro revision? revision-identifier
| +--ro location* inet:uri
+--ro datastore* [name]
| +--ro name identityref
| +--ro schema -> ../../schema/name
+--ro checksum string
How does this solution handle the use cases above?
C1: One schema, all datastores refer to this schema.
C2: Two schemas, "conventional" and "operational". They differ in
just one element (ietf-hardware). All other module information
is entirely duplicated in both.
C3: Two schemas, "conventional" and "operational". They differ in
the modules not implemented in operational, and operational also
has some deviation modules with "not-implemented".
C4: Three schemas, "conventional", "ephemeral", "operational".
"operational" contains the union of all modules in the other
two.
Pro: simple on the client, simple on the server
Con: verbose, since a single difference requires a complete, new,
schema.
Alt. B.
-------
Each datastore refers to a schema, and each schema contains a list
of references to module-sets, and each module-set contains a flat
list of all modules, features, etc.
When combining module-sets into a schema there MUST NOT be any
duplicate module definitions in the module-sets.
+--ro yang-library
+--ro module-set* [name]
| +--ro name string
| +--ro checksum string
| +--ro module* [name]
| | +--ro name yang:yang-identifier
| | +--ro revision? revision-identifier
| | +--ro namespace inet:uri
| | +--ro location* inet:uri
| | +--ro submodule* [name]
| | | +--ro name yang:yang-identifier
| | | +--ro revision? revision-identifier
| | | +--ro location* inet:uri
| | +--ro feature* [name]
| | | +--ro name yang:yang-identifier
| | +--ro deviation* [module]
| | +--ro module -> ../../name
| +--ro import-only-module* [name revision]
| +--ro name yang:yang-identifier
| +--ro revision union
| +--ro namespace inet:uri
| +--ro location* inet:uri
| +--ro submodule* [name]
| +--ro name yang:yang-identifier
| +--ro revision? revision-identifier
| +--ro location* inet:uri
+--ro schema* [name]
| +--ro name string
| +--ro checksum string
| +--ro module-set* -> ../../module-set/name
+--ro datastore* [name]
| +--ro name identityref
| +--ro schema -> ../../schema/name
+--ro checksum string
How does this solution handle the use cases above?
C1: One module-set, one schema, all datastores refer to this schema,
the schema refers to the single module-set.
C2: Two schemas, "conventional" and "operational", and two
module-sets. One module-set contains just "ietf-hardware" and
the other everything else. The "operational" schema refers to
both module-sets, and the "conventional" to just the one without
"ietf-hardware".
C3: Two schemas, "conventional" and "operational", and three
module-sets. One module-set contains all modules fully
implemented in both conventional and operational, one contains
the modules implemented only in conventional, and one the
modules and deviations for the partly implemented modules in
operational.
C4: Three schemas, "conventional", "ephemeral", "operational", but
just two module-sets. "conventional" refers to one of the
module-sets, and "ephemeral" to the other. "operational" refers
to both.
Pro: less verbose
Con: the client has to follow extra references and must combine the
result from the references into a single schema.
Alt. C.
-------
(This is the draft -02 version with just some name changes)
Each datastore refers to a schema, and each schema contains a list
of references to each module it includes.
+--ro yang-library
+--ro module* [id]
| +--ro id string
| +--ro name yang:yang-identifier
| +--ro revision? revision-identifier
| +--ro location* inet:uri
| +--ro namespace inet:uri
| +--ro feature* yang:yang-identifier
| +--ro deviation* [module]
| | +--ro module -> ../../id
| +--ro conformance-type enumeration
| +--ro submodule* [name]
| +--ro name yang:yang-identifier
| +--ro revision? revision-identifier
| +--ro location* inet:uri
+--ro schema* [name]
| +--ro name string
| +--ro module* -> ../../module/id
+--ro datastore* [name]
| +--ro name identityref
| +--ro schema -> ../../schema/name
+--ro checksum string
How does this solution handle the use cases above?
C1: One schema, all datastores refer to this schema,
the schema refers to all modules.
C2: Two schemas, "conventional" and "operational", and the module
list contains all modules. The "operational" schema refers to
all modules, and "conventional" to all modules except
"ietf-hardware".
C3: similar to C2, except there will be two entries in the module
list for evenry module that is partly implemented in
operational.
C4: Three schemas, "conventional", "ephemeral", "operational", and
the module list contains all modules.
Each schema refers to the modules it supports.
Pro: All modules available are listed in one place.
Con: the client has to follow extra references and must combine the
result from the references into a single schema.
the least "direct" solution due to the module "id".
probably a bit tricky to implement on the server.
/martin
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
