defining configuration

[djhaynes]

At the 3/9/16 SACM Virtual Interim Meeting, there was a question as to whether or not configuration covered the settings of software, hardware, or both. Given this, it may be useful to provide more information (or maybe define) what we mean by configuration. Likewise, we will need to determine our information needs for configuration, but, that can go in the Information Model.

[henkbirkholz]

first draft is now in the editor's version (including a corresponding definition of state)

[henkbirkholz]

Please note that:

1.) the NETMOD wg started to define provenance metadata ("origin") in https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/, which also includes

2.) a definition of static configuration data ("data that determines how a device behaves. Configuration data can originate from different sources. In YANG 1.1, configuration data is the "config true" nodes.").

Some of the terminology defined in draft-ietf-netmod-revised-datastores-00 does not align very well with our definitions. I am under the impression that the "dynamic configuration" defined in the document ("obtained dynamically during the operation of a device through interaction with other systems and not persistent.") is actually state.

The draft provides good examples of state in cases where configuration consists of the selection of an available automation feature that results in a specific state (section 7.1.). "auto-negotiation of link speed" is one of them.

For now, I tried to address the discrepancy by highlighting in our definition of state that dynamic configuration is state. We should reach out and try to find out the line of thought behind the terminology in draft-ietf-netmod-revised-datastores-00 (including the choice of the term "origin", which is seems to be the equivalent to our term "data source").

[adammontville]

I like that they're decomposing "configuration data", but I do not follow the decomposition as defined. Reaching out seems like a good idea. @henkbirkholz did you have a recommendation about how such outreach should be done? I'm happy to do so initially, but I presume one of our terminology authors would then be in the loop with one of the draft-ietf-netmod-revised-datastores-00 authors...

[henkbirkholz]

As discussed at the last virtual interim, I will try to get the task at hand started quickly at the next meeting. Please stay tuned for further updates on this issue.

[henkbirkholz]

NMDA is an RFC now (that took longer than expected).

In general, I'd recommend to read this section and its sub-sections: https://tools.ietf.org/html/rfc8342#section-5

This is the taxonomy of configuration from NMDA in a nutshell:

• Conventional Configuration
  • running
  • candidate
  • startup
  • intended
• Dynamic Configuration (configuration that does not survive a boot-cycle but is not state....)
• Operational Configuration (configuration and its state (!) that is actually used by the target endpoint)
• "some important flavors of configuration that seem to have no parent term"....
  • learned configuration: neither dynamic configuration nor conventional configuration....)
  • system configuration: configuration that is supplied by the hardware components themselves)
  • default configuration: configuration that is not explicitly provided, but a default value exists)
  • applied configuration: configuration that is actively in use by a device.

As a complement there is:

• system state: the additional data on a system that is not configuration, such as read-only status information and collected statistics. System state is transient and modified by interactions with internal components or other systems. This is pretty much what SACM always defined as State.

In essence, the configuration interesting to SACM is "applied configuration" and then the "system state".

The composite of both is actually also defined by NMDA:

• operational state: The combination of applied configuration and system state.

In consequence, my proposal is to directly adopt the three terms "applied configuration", "system state" and "operational state". Alternatively, we could just retain configuration and highlight that it means applied configuration and retain state and highlight that is means system state.

The term "operational state" would be a new addition and basically refer to the composite of current configuration and current state -> a big chunk of our collectible target endpoint attributes.

There might be a few types of conventional configuration (e.g. not activated features or inactive configuration) that I cannot personally map to the NMDA terminology. But maybe a more proficient group member can?