Hello,
I have a proposal based on <get-data> that provides an elegant solution
to consider as a 3rd option. It is based on keeping exactly the same
model as in RFC 7895 and using <get-data> RPC to retrieve datastore
specific yang-library instance data in a similar way one would use
<get-data> to retrieve the datastore contents. In addition a top level
config=false container e.g. /datastores with list of supported
datastores that does not need to be part of the yang-library module:
module: ietf-datastores
+--ro datastores
| +--ro datastore* [name]
| +--ro name identityref
Vladimir
On 11/09/2017 05:51 PM, Robert Wilton wrote:
Hi,
Given some of the feedback related to the complexity of the YANG
library bis structure, we have come up with two other possible
structures for the YANG library data:
(1) A simplified structure to make YANG library meet the NMDA
requirements, but that is closer to the existing YANG library
structure, and arguably simpler.
(2) An enhanced version of the structure (1) above, that is also
extended to allow the structure to be reused for schema-mount via an
augmentation.
For reference, at the end of this email, I have also included the tree
diagram of the existing YANG library, and the current YANG library bis
draft (draft-ietf-netconf-rfc7895bis-02) version.
Considering the two new YANG library structures:
------------------------
*(1) A simplified structure to make YANG library meet the NMDA
requirements, but that is closer to the existing YANG library structure.*
The main changes are:
(i) Split "implemented modules" and "import-only-modules" into two
separate lists, making the most important list (i.e. implemented
modules) keyed by module name only and hence easier to reference.
(ii) Assume modules are implemented in all datastores by default (with
a "not-implemented-in" leaflist of datastores that a module is not
implemented in).
(iii) Assume that features are implemented in all datastores by
default (with a "not-implemented-in" leaflist of datastores that a
feature is not implemented in).
(iv) Deleted module-sets.
(v) Datastores are now just a list of supported datastores (that could
potentially be extended with further per datastore properties in future).
Manually generated tree output for proposed YANG library:
module: ietf-yang-library
+--ro yang-library
+--ro modules
| +--ro module* [name]
| | +--ro name yang:yang-identifier
| | +--ro revision? revision-identifier
| | +--ro schema? inet:uri
| | +--ro namespace inet:uri
| | +--ro submodule* [name]
| | | +--ro name yang:yang-identifier
| | | +--ro revision? yang:yang-identifier
| | | +--ro schema? inet:uri
| | +--ro not-implemented-in*
| | | -> /yang-library/datastore/name
| | +--ro feature* [name]
| | | +--ro name yang:yang-identifier
| | | +--ro not-implemented-in*
| | | -> /yang-library/datastore/name
| | +--ro deviation*
| | -> ../name
| |
| +--ro import-only-module* [name revision]
| +--ro name yang:yang-identifier
| +--ro revision union
| +--ro schema? inet:uri
| +--ro namespace inet:uri
| +--ro submodule* [name]
| +--ro name yang:yang-identifier
| +--ro revision yang:revision-identifier
| +--ro schema? inet:uri
+--ro datastore* [name] // Allows future per datastore properties.
| +--ro name identityref
+--ro checksum string
------------------------------
*(2) An enhanced version of the structure (1) above, that is extended
to allow the structure to be reused for schema-mount via an augmentation.*
This is similar to the structure above, except that the "the set of
modules" is contained in a list of named schema (e.g. similar to the
schema mount draft), allowing this structure to be re-used for schema
mount.
Schema mount would be expected to augment yang-library to add in the
additional schema mount information. In the tree diagram, I have
shown the schema-mount mount-point augmentation, but not including
namespaces yet.
Every server would be required to provide at least one schema in the
schema list, and the primary schema for the device would always be
given the name "primary".
module: ietf-yang-library
+--ro yang-library
+--ro schema* [name]
| +--ro name string
| +--ro checksum string
| +--ro module* [name]
| | +--ro name yang:yang-identifier
| | +--ro revision? yang:revision-identifier
| | +--ro schema? inet:uri
| | +--ro namespace inet:uri
| | +--ro submodule* [name]
| | | +--ro name yang:yang-identifier
| | | +--ro revision? yang:yang-identifier
| | | +--ro schema? inet:uri
| | +--ro not-implemented-in*
| | | -> /yang-library/datastore/name
| | +--ro feature* [name]
| | | +--ro name yang:yang-identifier
| | | +--ro not-implemented-in*
| | | -> /yang-library/datastore/name
| | +--ro deviation*
| | | -> ../name
| | +- schema-mount:mount-point* [label]
| | +--ro label yang:yang-identifier
| | +--ro config? boolean
| | +--ro (schema-ref)
| | +--:(inline)
| | | +--ro inline? empty
| | +--:(use-schema)
| | +--ro use-schema* [name]
| | +--ro name
| | | -> /yang-library/schema/name
| | +--ro parent-reference* yang:xpath1.0
| |
| +--ro import-only-module* [name revision]
| +--ro name yang:yang-identifier
| +--ro revision union
| +--ro schema? inet:uri
| +--ro namespace inet:uri
| +--ro submodule* [name]
| +--ro name yang:yang-identifier
| +--ro revision yang:revision-identifier
| +--ro schema? inet:uri
+--ro datastore* [name] // Allows future per datastore properties.
| +--ro name identityref
+--ro checksum string
Please can you provide comments on these structures, in particular:
Is this version better (i.e. simpler) that the version currently in
draft-ietf-netconf-rfc7895bis-02 (below)?
Should we try and make the structure extensible for schema-mount via
augmentation (i.e. version (2)), or is it better that schema-mount has
its own separate subtree?
For reference only I have included the existing YANG library and YANG
library bis draft tree diagrams.
Thanks,
Rob
-----------------------------
*** FOR REFERENCE ONLY ***
(3) The current YANG library structure in YANG library bis
(draft-ietf-netconf-rfc7895bis-02)
module: ietf-yang-library
+--ro yang-library
+--ro modules
| +--ro module* [id]
| +--ro id string
| +--ro name yang:yang-identifier
| +--ro revision? revision-identifier
| +--ro schema? 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 schema? inet:uri
+--ro module-sets
| +--ro module-set* [id]
| +--ro id string
| +--ro module* -> ../../../modules/module/id
+--ro datastores
| +--ro datastore* [name]
| +--ro name identityref
| +--ro module-set
| -> ../../../module-sets/module-set/id
+--ro checksum string
-----------------------------
*** FOR REFERENCE ONLY ***
(4) The current YANG library structure (RFC 7895)
+--ro modules-state
+--ro module-set-id string
+--ro module* [name revision]
+--ro name yang:yang-identifier
+--ro revision union
+--ro schema? inet:uri
+--ro namespace inet:uri
+--ro feature* yang:yang-identifier
+--ro deviation* [name revision]
| +--ro name yang:yang-identifier
| +--ro revision union
+--ro conformance-type enumeration
+--ro submodule* [name revision]
+--ro name yang:yang-identifier
+--ro revision union
+--ro schema? inet:uri
_______________________________________________
Netconf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
