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

[Robert Wilton <[e-mail]>]

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