Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query

Hi Robert,

An example has been shown in the "Appendix B.  Example YANG Library Instance for a Basic Server"

     <schema>
       <name>config-schema</name>
       <module-set>config-modules</module-set>
     </schema>
     <schema>
       <name>state-schema</name>
       <module-set>config-modules</module-set>
       <module-set>state-modules</module-set>
     </schema>

     <datastore>
       <name>ds:startup</name>
       <schema>config-schema</schema>
     </datastore>
     <datastore>
       <name>ds:running</name>
       <schema>config-schema</schema>
     </datastore>
     <datastore>
       <name>ds:operational</name>
       <schema>state-schema</schema>
     </datastore>

This example shows <operational> having state-modules, but <running> has only configuration modules. This and introduction statement, convinced me the <operational> and <running> will have different schema in a Basic server.

Also what does it mean that state-modules have been "implemented" in the <running> data-store ?

With Regards,
Rohit R Ranade

From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: 29 May 2018 16:28
To: Rohit R Ranade <rohitrranade@huawei.com>; netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query

Hi Rohit,

If you have a module, "mod-state-only", that only contains "config false" nodes then either of the following approaches is valid:

(1) You include the "mod-state-only" module in the schema for both conventional datastores and <operational>.  All config false leaves will be ignored anyway for the configuration datastores.

(1) You define separate schema for the conventional datastores vs operational.  "mod-state-only" isn't present in the schema for the conventional datastores, but is present in <operational>.

Either approach is valid, and I don't recall the YANG library bis draft stating any preference.

Thanks,
Rob

On 29/05/2018 11:44, Rohit R Ranade wrote:
Hi Robert,

The Introduction section has :
"
Furthermore, the operational state datastore may support non-configurable YANG modules in addition to
   the YANG modules supported by conventional configuration datastores.
"
I infer that in the new Yang-library structure,  the schema for "conventional" data-stores should not include the non-configurable YANG module. Is my inference correct ?

With Regards,
Rohit R Ranade
From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: 29 May 2018 15:28
To: Rohit R Ranade <rohitrranade@huawei.com><mailto:rohitrranade@huawei.com>; netmod@ietf.org<mailto:netmod@ietf.org>
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query

Hi Rohit,

On 29/05/2018 10:35, Rohit R Ranade wrote:
Hi All,

Consider the below YANG tree, which contains both "rw" and "ro" nodes.

module: ietf-interfaces
    +--rw interfaces
    |  +--rw interface* [name]
    |     +--rw name                        string
    |     +--rw description?                string
    |     +--rw type                        identityref
    |     +--rw enabled?                    boolean
    |     +--rw link-up-down-trap-enable?   enumeration {if-mib}?
    |     +--ro admin-status                enumeration {if-mib}?
    |     +--ro oper-status                 enumeration
    |     +--ro last-change?                yang:date-and-time
    |     +--ro if-index                    int32 {if-mib}?
    |     +--ro phys-address?               yang:phys-address
    |     +--ro higher-layer-if*            interface-ref

>From what I understand, in the new yang-library structure the schema for <operational> data-store will have the complete YANG tree. The schema for <running> will need to add deviations with "not-supported" for all the "ro" nodes for this module ?
No need for the deviations for <running>.  <running> only contains the "config true" parts of the schema.

So, for a normal, NMDA compliant server, the same schema can be used for all datastores.

Thanks,
Rob

With Regards,
Rohit R Ranade

_______________________________________________

netmod mailing list

netmod@ietf.org<mailto:netmod@ietf.org>

https://www.ietf.org/mailman/listinfo/netmod