Re: [netmod] augment YANG 1.0 with YANG 1.1 OK?

[Robert Wilton <[e-mail]>]

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 <[e-mail]> wrote:
>> On Wed, Oct 25, 2017 at 12:49 PM, Martin Bjorklund <[e-mail]> wrote:
>>
>>> Andy Bierman <[e-mail]> 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
> .
>