Hi,
The new structure still has the same problems for the
client as
before.
It is a major change in the architecture to have different
schema trees per datastore instead of per-server.
The server is allowed to have different features and
deviations
for the same objects.
The client is completely on its own trying to compare
<operational> to anything
if the schema trees are different
container foo {
leaf bar {
if-feature X;
type string;
}
leaf baz {
if-feature "not X";
type string;
}
}
How does the client compare <running> to <operational> if the
features do not match?
If the server deviates the leaf (e.g. change type string to
int32) how does the client
compare the values?
This new complexity would be mandatory for the client to
support in some proprietary
manner since the NMDA standard ignores these problems.
NMDA was supposed to be simpler because the client could
compare intended
and applied values using the same object path. openconfig
required a data
model change and a trivial name-mapping. In reality, NMDA
is far more disruptive to existing implementations.
Andy
On Thu, Nov 9, 2017 at 8:51 AM, Robert Wilton
<rwil...@cisco.com <mailto:rwil...@cisco.com>> 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
