There are many different layers and all, or none of them could be called configuration depending on your perspective. Consider the current set of routes on a router. I think we can all agree that from the point of view of the Linux kernel, or a hardware routing chip, this is configuration data. But from the point of view of an OSPF process it is operational data. OSPF will reconfigure Linux every time the routes change. Even *static* routes may be considered operational data at an even higher level (such as a network monitoring system).
________________________________________ From: netmod <netmod-boun...@ietf.org> on behalf of Joel M. Halpern <j...@joelhalpern.com> Sent: Wednesday, 21 June 2017 6:19 a.m. To: t.petch; Robert Wilton; netmod@ietf.org Subject: Re: [netmod] Defining configuraiton: was I-D Action: draft-ietf-netmod-rfc6087bis-13.txt I was going to just watch this, but I can't. To call protocol negotiated values "configuration" is to create a usage which will confuse MANY people. Even worse, configuring protocol learned values is liable to break things. To use one example, many protocols negotiate timers. The value that a given systems starts with is the configured value. The value that it learns from the protocol exchange is the operational value. In fact, you better not try to configure that value or you are liable to break the protocol. Yours, Joel On 6/20/17 1:51 PM, Juergen Schoenwaelder wrote: > On Tue, Jun 20, 2017 at 05:36:12PM +0100, t.petch wrote: >> >> 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. >> > > Is your proposal to take out "This data is modeled in YANG using > "config true" nodes."? > > Note that the NMDA document further defines > > o conventional configuration: Configuration that is stored in any of > the conventional configuration datastores. > > o dynamic configuration: Configuration obtained via a dynamic > datastore. > > o learned configuration: Configuration that has been learned via > protocol interactions with other systems that is not conventional > or dynamic configuration. > > o system configuration: Configuration that is supplied by the device > itself. > > o default configuration: Configuration that is not explicitly > provided but for which a value defined in the data model is used. > > There are corresponding origin attribute definitions. (With the minore > caveat that the origin value for conventional configuration is > intended since this is the datastore conventional configuration > finally originates from.) > > /js > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
