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

From: Rohit R Ranade <[email-masked]>
Date: Tue, 29 May 2018 09:35:09 +0000

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 ?

With Regards,
Rohit R Ranade

---

From: Robert Wilton <[email-masked]>
Date: Tue, 29 May 2018 10:57:39 +0100

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
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Rohit R Ranade <[email-masked]>
Date: Tue, 29 May 2018 10:44:04 +0000

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:[email-masked]]
Sent: 29 May 2018 15:28
To: Rohit R Ranade <[email-masked]>; [email-masked]
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query

Hi Rohit,

module: ietf-interfaces
    +--rw interfaces

>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-sup…
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

[email-masked]<mailto:[email-masked]>

---

From: Robert Wilton <[email-masked]>
Date: Tue, 29 May 2018 11:57:30 +0100

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:
> “
> Furthermore, the operational state datastore may support 
> non-configurable YANG modules in addition to
>
> ”
> 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:[email-masked]]
> *Sent:* 29 May 2018 15:28
> *To:* Rohit R Ranade <[email-masked]>; [email-masked]
> *Subject:* Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query
>
> Hi Rohit,
>
>     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 ?
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 May 2018 13:06:10 +0200

> 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 ?

A module that has only config false nodes will not add anything to a
conventional configuration datastore but it is not an error list such
a module. For a simple devices, it may be desirable to have just one
schema that applies to all datastores. There is no requirement to
break things apart just because there is a module that contributes
only an empty set to conventional configuration datastores.

Note that the defined term is 'conventional configuration datastore'
and not 'conventional datastore'. Oops, I see that in one place
draft-ietf-netconf-rfc7895bis-06.txt missing the 'configuration' part
of the term. That should be fixed.

OLD

   The recommended approach to populate "/modules-state" is to report
   the schema for YANG modules that are configurable via conventional
   datastores and for which config false data nodes are returned via a
   NETCONF <get> operation, or equivalent.

NEW

   The recommended approach to populate "/modules-state" is to report
   the schema for YANG modules that are configurable via conventional
   configuration datastores and for which config false data nodes are
   returned via a NETCONF <get> operation, or equivalent.

Co-authors, if you agree, how do we track this?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Rohit R Ranade <[email-masked]>
Date: Tue, 29 May 2018 11:27:42 +0000

Hi Juergen,

Consider a device supports a dynamic data-store called "ephemeral". Consider Yang-library 1.1 is NOT implemented in device.
Consider device have 3 Modules ==> Module1 ,  Module2-state and Module3

Module1 : Supported in <running> and <operational>
Module2-state : Supported only in <operational>
Module3 : Supported only in <ephemeral>

So here assumption is that Client knows he cannot do <edit-data> on Module2-state as it has only read-only nodes.
But Client does not know the modules in ephemeral and depends on yang-library 1.1 to know whether an edit-data can be done on Module3 ?

Which modules are supported in which data-stores is not known to Client without Yang-library 1.1 ?

With Regards,
Rohit R Ranade

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: 29 May 2018 16:36
To: Rohit R Ranade <[email-masked]>
Cc: Robert Wilton <[email-masked]>; [email-masked]
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query

> 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 ?

A module that has only config false nodes will not add anything to a conventional configuration datastore but it is not an error list such a module. For a simple devices, it may be desirable to have just one schema that applies to all datastores. There is no requirement to break things apart just because there is a module that contributes only an empty set to conventional configuration datastores.

Note that the defined term is 'conventional configuration datastore'
and not 'conventional datastore'. Oops, I see that in one place draft-ietf-netconf-rfc7895bis-06.txt missing the 'configuration' part of the term. That should be fixed.

OLD

NEW

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 May 2018 14:06:16 +0200

Yes, this is why we have draft-ietf-netconf-rfc7895bis-06.txt.

/js

---

From: Kent Watsen <[email-masked]>
Date: Tue, 29 May 2018 14:47:46 +0000

> Co-authors, if you agree, how do we track this?

As co-author, I agree and view it as an editorial update.  

As co-chair, I recommend the authors commit the fix to 
GitHub now and wait for AD and/or IESG reviews to trigger
an update that it will get swept into.  I don't think that
it's worth fixing any sooner than that, and yet also fear
risking it will be forgotten.

Kent

OLD

NEW

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=fL-imGAsOCm0vM-RDRMkiRFU-5x4dLkKa5-hBOU9Iys&s=jmr0Y7mRCeX05op4h6BICyj9U0l0IhnbM5yBqhtcL4k&e=>

_______________________________________________
netmod mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=fL-imGAsOCm0vM-RDRMkiRFU-5x4dLkKa5-hBOU9Iys&s=i4-lwMctjujC_UiZmGO4s83-jyKmw7jbGsS0cLfFZT4&e=

---

From: Qin Wu <[email-masked]>
Date: Wed, 30 May 2018 01:56:14 +0000

Juergen:
One stupid question I have is, What about the old client and server still support YANG 1.0 since RFC7895bis is designed to replaces RFC7895?
Do we have transition stage before RFC7895bis takes effect?

-Qin
-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Juergen Schoenwaelder
发送时间: 2018年5月29日 20:06
收件人: Rohit R Ranade
抄送: [email-masked]
主题: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query

/js

On Tue, May 29, 2018 at 11:27:42AM +0000, Rohit R Ranade wrote:
> Module1 : Supported in <running> and <operational> Module2-state : 
> Supported only in <operational>
> From: Juergen Schoenwaelder 
> [mailto:[email-masked]]
> Sent: 29 May 2018 16:36

---

From: Rohit R Ranade <[email-masked]>
Date: Wed, 30 May 2018 05:21:29 +0000

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

Sent: 29 May 2018 16:28

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

With Regards,
Rohit R Ranade
From: Robert Wilton [mailto:[email-masked]]
Sent: 29 May 2018 15:28
To: Rohit R Ranade <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query

Hi Rohit,

module: ietf-interfaces
    +--rw interfaces

Thanks,
Rob

With Regards,
Rohit R Ranade

netmod mailing list

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 May 2018 07:39:33 +0200

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

The server implemented an empty set of objects. No client should have
an issue with that and a server may choose to report this (for example
if the server wants to have a single schema for all datastores).

I do not see why making this illegal would simplify anything. It seems
making this illegal just adds complexity for no value.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 May 2018 07:53:12 +0200

This is discussed in section 1 of draft-ietf-netconf-rfc7895bis-06.txt.

/js

---

From: Qin Wu <[email-masked]>
Date: Wed, 30 May 2018 05:59:19 +0000

I find answer in 3rd paragraph of section 1, thanks Juergen for clarification,

-Qin
-----邮件原件-----
发件人: Juergen Schoenwaelder [mailto:[email-masked]] 
发送时间: 2018年5月30日 13:53
收件人: Qin Wu
抄送: Rohit R Ranade; [email-masked]
主题: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query

/js

---

From: Rohit R Ranade <[email-masked]>
Date: Wed, 30 May 2018 06:40:02 +0000

Hi Juergen,

My intention is only to get clarity about what is the meaning of implementing a module in a data-store, as it used in below places,

" It must be possible to NOT implement a module or feature in
       <operational>, even if it is implemented in some other datastore"

"   2.  A dynamic configuration datastore must be able to implement a
       module or feature that is not implemented in the conventional
       configuration datastores."

A module having only "ro" nodes , can be considered to be implemented in any data-store ? operational/ephemeral etc
A module having "rw" nodes,  what is the rules for it to be considered implemented in a data-store ?

RFC 7950 is quite clear for the rules for when a module is considered implemented. Please clarify implementation with respect to data-store also.

With Regards,
Rohit R Ranade

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: 30 May 2018 11:10
To: Rohit R Ranade <[email-masked]>
Cc: Robert Wilton <[email-masked]>; [email-masked]
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query

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

The server implemented an empty set of objects. No client should have an issue with that and a server may choose to report this (for example if the server wants to have a single schema for all datastores).

I do not see why making this illegal would simplify anything. It seems making this illegal just adds complexity for no value.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 May 2018 08:57:37 +0200

> A module having only "ro" nodes , can be considered to be implemented in any data-store ? operational/ephemeral etc

No.

> A module having "rw" nodes,  what is the rules for it to be considered implemented in a data-store ?

You implement the set of nodes that the datastore supports. In case of
a config false module and a conventional configuration datastore, this
set is empty.
 
> RFC 7950 is quite clear for the rules for when a module is considered implemented. Please clarify implementation with respect to data-store also.

I do not understand why this is unclear.

/js

---

From: Rohit R Ranade <[email-masked]>
Date: Wed, 30 May 2018 09:38:05 +0000

Hi Juergen,

Modules which define only notifications(ietf-netconf-notifications) will be defined in <operational> data-store ONLY. Right ?

With Regards,
Rohit R Ranade

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: 30 May 2018 12:28
To: Rohit R Ranade <[email-masked]>
Cc: Robert Wilton <[email-masked]>; [email-masked]
Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query

On Wed, May 30, 2018 at 06:40:02AM +0000, Rohit R Ranade wrote:

> A module having only "ro" nodes , can be considered to be implemented 
> in any data-store ? operational/ephemeral etc

No.

> A module having "rw" nodes,  what is the rules for it to be considered implemented in a data-store ?

You implement the set of nodes that the datastore supports. In case of a config false module and a conventional configuration datastore, this set is empty.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 May 2018 12:56:40 +0200

The phrase 'will be defined' is not good. Anyway, for a notification
nested in data tree, the data tree must exist in <operational> and
the context in which XPath expressions are evaluated is <operational>,
see section 6.1. of RFC 8342.

/js