Hi Andy,
On 16/11/2017 10:42, Andy Bierman wrote:
On Wed, Nov 15, 2017 at 4:53 PM, Robert Wilton <[email protected]
<mailto:[email protected]>> wrote:
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.
This is not apparent from the text.
I agree that this can be better explained, either in YANG library,
and/or in the datastores architecture. This is implied by the datastore
draft today, but there is no harm to make it a bit more explicit.
The draft-02 library is very out of date at this point.
Yes, sorry. The -02 is out of date with the latest proposal which was
discussed/developed after the cutoff date. Functionality wise they are
intended to be capable of expressing the same things, but the proposal
in this original thread is intended to be simpler.
I only care about restricting the conventional datastores, <intended>
and <operational>.
It will be a massive client rewrite if the client cannot compare
<intended> to <operational>
with 1 schema tree.
<intended> also counts as a conventional datastore so the list of
modules, features, deviations MUST be the same as for <running>,
<startup>, and <candidate>.
But yes, I entirely agree that it must be possible to compare from
<intended> to <operational> in an easy way. Arguably that is one of the
key aspects of this work.
If the updated draft reflects the feature-in-operational requirement
above then
I have no objections to the proposed YANG library functionality.
OK, we will ensure that this is clearly documented.
I am still concerned about per-datastore deviations.
IMO, the server MUST implement the same deviations in these special
datastores.
For a normal server YANG deviation "e.g. changing types, or value space,
etc" then the same deviations MUST be applied to ALL datastores.
If that cannot be done, the operational node will not be present.
Another leaf node
(like admin-state/oper-state) needs to be used instead.
Yes, entirely agree.
The only type of per datastore deviation is to remove a node. Further,
if that deviation is applied to one of the conventional datastores then
it must apply to all of the conventional datastores.
If the server does implement per-datastore deviations,
clients may not work (if they use the conventional datastore schema
tree for <operational>).
The same thing happens if the client ignores plain-old-deviations now,
so this is not a big deal.
I think that I agree.
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.
I still think the WG needs to define YANG conformance for datastores,
The question "what datastores does server implementation X support for
module foo?" is covered.
The question "what datastores MUST, SHOULD, MAY a compliant server
implementation
support for module foo?" is totally ignored.
The RESTCONF NMDA draft states:
An NMDA-compliant RESTCONF server MUST support the operational state
datastore. Such a server identifies that it supports NMDA both by
implementing the {+restconf}/ds/ietf-datastores:operational resource,
and by implementing at least revision 201X-XX-XX of the
"ietf-yang-library" module, as specified in
[I-D.nmdsdt-netconf-rfc7895bis].
The NETCONF NMDA protocol draft should have a similar statement.
Do you think that this conformance statement is insufficient?
Or is your concern about whether modules are expected to be implemented?
Thanks,
Rob
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
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
