Re: [netmod] [Netconf] Alternative YANG library structure for 7895bis

[Andy Bierman <[e-mail]>]

On Wed, Nov 15, 2017 at 4:53 PM, Robert Wilton <[e-mail]> 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. The draft-02 library is very out of
date at this point.

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.

If the updated draft reflects the feature-in-operational requirement above
then
I have no objections to the proposed YANG library functionality.

I am still concerned about per-datastore deviations.
IMO, the server MUST implement the same deviations in these special
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.

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.




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.


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 <[e-mail]> 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 [e-mail]://www.ietf.org/mailman/listinfo/netconf
>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>
>