--- Original Message ----- From: "Phil Shafer" <[email protected]> To: "Andy Bierman" <[email protected]> Cc: <[email protected]> Sent: Tuesday, June 20, 2017 7:05 AM
> Andy Bierman writes: > >This draft addresses all remaining open issues, include the rewrite of the > >opstate section. > > >>In YANG, any data that has a "config" statement value of "false" > >>could be considered operational data. The relationship between > >>configuration (i.e., "config" statement has a value of "true") and > >>operational data can be complex. > > The NMDA draft includes the following in its terminology section: > > - configuration: Data that determines how a device behaves. This > data is modeled in YANG using "config true" nodes. Configuration > can originate from different sources. > > - operational state: The combination of applied configuration and > system state. > > It would be nice to use matching terms, either by importing the > NMDA terms directly, or by mimicing them in this draft. If your > "operational data" means "config false" and NMDA's "operational state" > means both config true and config false, readers will be confused. Phil Well, it would if the definitions in NMDA brought clarity but I think the opposite. 'Data that determines how a device behaves' seems clear until you read on and find that this excludes data learnt from the system or data learnt from routing protocols. I find the idea that the behaviour of a device is not determined by routing protocols or a hot-plugged card an odd one. This definition is rather different to that in NETCONF and seems unlikely to bring clarity so I think it would be a mistake to incorporate it in rfc6087bis.. Tom Petch > Also you say "operational state and other data such as statistics" > which inconsisent. Under either set of terms, statistics are > part of operational state. > > >>The original set of datastores defined in NETCONF (i.e., candidate, > >>unning, and startup) are not sufficient to fully manage a device > >>ith multiple sources of configuration data. In additional, a > >>separate datastore is needed to store operational state and other > >>data such as statistics. Refer to > >>[I-D.ietf-netmod-revised-datastores] for details on this new "revised > >>datastore" architecture. Guidelines for usage of the new datastores > >>(including the operational datastore) is defined in > >>[I-D.dsdt-nmda-guidelines]. > > "not sufficient to fully manage" is too broad a claim. Can I suggest > a more positive spin: > > The Network Management Datastore Architecture (NMDA) defines a > new set of datastores that improve visibility into the device, > both in terms of the "intended" configurations values and the > true operationally "in use" values. Refer to > [I-D.ietf-netmod-revised-datastores] for details. Guidelines for > moving existing data modules to the NMDA are defined in > [I-D.dsdt-nmda-guidelines]. > > Thanks, > Phil > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
