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 protected]] 代表 Juergen Schoenwaelder 发送时间: 2018年5月29日 20:06 收件人: Rohit R Ranade 抄送: [email protected] 主题: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query Yes, this is why we have draft-ietf-netconf-rfc7895bis-06.txt. /js On Tue, May 29, 2018 at 11:27:42AM +0000, Rohit R Ranade wrote: > 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 protected]] > Sent: 29 May 2018 16:36 > To: Rohit R Ranade <[email protected]> > Cc: Robert Wilton <[email protected]>; [email protected] > Subject: Re: [netmod] draft-ietf-netconf-rfc7895bis-06 deviation query > > On Tue, May 29, 2018 at 10:44:04AM +0000, 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 ? > > > > 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/> -- 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/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
