Re: [netmod] YANG library structure

[Lou Berger <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>