Hi,
A refined version of the proposed text is below (because "schema" isn't
defined):
On 26/10/2017 11:10, Martin Bjorklund wrote:
Andy Bierman <[email protected]> wrote:
On Wed, Oct 25, 2017 at 12:49 PM, Martin Bjorklund <[email protected]> wrote:
Andy Bierman <[email protected]> wrote:
I think NMDA is creating much more complexity and disruption than is
required.
The original issue was the OpenConfig-style config/state trees.
The WG agreed that an RPC-based solution was needed so that the
YANG modules would not need to change (far too disruptive!).
Then the IETF proceeds to redo all the YANG modules anyway.
Now the server is allowed to implement the same module differently in
each
datastore.
Now comparing the configured and operational value is even harder than
before.
None of this added complexity was in the OpenConfig proposal.
It was not even possible to have different features and deviations for
the
same object in that proposal.
Actually, this is not correct. In both OC and the old IETF split tree
solutions, the configuration and operational state were modelled with
duplicate nodes, and you could certainly deviate these nodes
differently.
This said, I share your concern about complexity. I also agree that
the only model that makes the client simple is that if all objects in
the config are also available with the same types in operational
state. Otherwise comparison won't work (or be complicated).
But at the same time, the converse is not true. I.e., if an object is
present in operational, it doesn't have to be configurable.
So what I think we want is that the schema for the conventional
datastore is a subset of the schema for operational.
This would allow an implementation that cannot support configuration
of let's say the MTU, to deviate the mtu with "not-supported" in the
conventional datastore, but it will still be available for inspection
in operational.
Does this make sense?
OK -- deviations for not-supported make sense per datastore
to resolve the missing-object ambiguity problem.
It is not realistic to expect every object in a module to be able
to report its operational state in the same release.
It is better to report not-supported than return nothing or return the
configured value as a guess.
If the admin-state and oper-state objects are different, 2 objects should
be used instead of per-datastore deviations of the syntax of 1 object.
Agreed.
So based on this, how about this text:
The schema for <operational> MUST be a superset of the combined
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.
Given that "schema" isn't defined, we propose using "datastore schema"
instead:
NEW:
schema node - A node in the schema tree. The formal definition is in
RFC 7950.
datastore schema - is the combined set of schema nodes for all modules
supported by a particular datastore, taking into consideration any
deviations and enabled features for that datastore.
The below text is changed from "schema" to "datastore schema":
5.1. Conventional Configuration Datastores
The conventional configuration datastores are a set of configuration
datastores that share exactly the same datastore schema, allowing
data to be copied between them. The term is meant as a generic
umbrella description of these datastores. The set of datastores
include:
The proposed new text for operational would change to:
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.
Thanks,
Rob
/martin
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
