----- Original Message ----- From: "Robert Wilton" <[email protected]> Sent: Tuesday, June 20, 2017 1:35 PM
> Hi Tom, > > On 20/06/2017 12:39, t.petch wrote: > > --- Original Message ----- > > From: "Phil Shafer" <[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. > Please can you clarify. The text that you are quoting above is from the > NMDA definition of "configuration". > > Data learned from the system or routing protocols (for YANG config true > nodes) would be classified as "system configuration" or "learned > configuration", which are sub categories of "configuration", and hence > are not excluded from the more general definition of "configuration". Robert The definition of 'configuration' in netmod-revised-datastores-02 is very different from what has gone before in NETCONF and NETMOD. You start with 'Data that determines how a device behaves. ' which is how I would have defined configuration before the days of NETCONF and which I imagine is how many who have not been exposed to NETCONF would still do. NETCONF narrowed the definition a lot; 'Data that determines how a device behaves' opens it up again. You add the qualification 'using "config true" nodes' which doesn't really mean anything in this context, unless you already know some YANG models, and know what is modelled in this way and what is not and so can work it out, reverse engineering. Coming to netmod-revised-datastores-02 with an innocent eye, knowing that the ground has moved, that some of my assumptions of the past 10 years are no longer valid, then these definitions convey to me that configuration acquired from the system or from routing protocols, to take two common examples, will now always be modelled 'config true', that is the first sentence is the definition and the second - 'config true' - is the consequence thereof. Of course, if you come to the I-D knowing otherwise, then you may find a different interpretation but I do not think that that is the obvious interpretation. Tom Petch > Thanks, > Rob > > > > > > 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 > > . > > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
