Hi Andy,
On 16/11/2017 02:29, Andy Bierman wrote:
Hi,
The per-datastore feature aspect of NMDA is a new and significant
change to YANG.
| | +--ro feature* [name]
| | | +--ro name yang:yang-identifier
| | | +--ro not-implemented-in*
| | | -> /yang-library/datastore/name
YANG does not define feature conformance at this granularity.
I strongly object to this change to YANG conformance.
A server can only advertise a YANG feature if it implemented on the
entire server.
This extra complexity is not present on the openconfig solution or
requirements.
In terms of comparison, it definitely is:
- you can have different features for the config and state trees (e.g.
"router-id" feature in RFC 8022).
- sometimes the conventions are not followed completely consistently,
e.g. different types, or semantics between config and state.
- sometimes the structures differ between config and state.
So, the problem comparing between config and state is not easier in
either the IETF split tree or OpenConfig solutions.
Comparing any datastore to <operational> is much more complex (any may
not be possible)
if the features are different for a given module.
You can always compare (except deviations in operational). If a feature
is enabled on any configuration datastore then it must also be enabled
on operational.
E.g. take "router-id" feature from RFC8022bis (that was also defined in
RFC8022).
This feature can be enabled:
(i) everywhere (i.e. <conventional> + <i2rs-ephemeral> + <operational>), or
(ii) <conventional> + <operational>, or
(iii) <i2rs-ephemral> + <operational>, or
(iv) <operational> only, or
(v) or in none of them.
Hence, <operational> always contains a superset of the nodes.
I do not see how <operational> can be true superset of the
conventional datastores
if the features are different.
Because of the statement above.
Thanks,
Rob
Andy
On Wed, Nov 15, 2017 at 9:29 AM, Robert Wilton <[email protected]
<mailto:[email protected]>> wrote:
I don't think that this is really a good idea. You would end up
returning server metadata in addition to the configuration.
I still think that the YANG library proposal is the best solution.
Thanks,
Rob
On 16/11/2017 01:21, Vladimir Vassilev wrote:
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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netconf
<https://www.ietf.org/mailman/listinfo/netconf>
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
<https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
