Proposing a new approach to state and configuration

[adammontville]

I believe we have poor definitions for configuration and state.

We define configuration as non-volatile endpoint attributes and state as volatile endpoint attributes. This feels dissatisfying. I would propose that we take an approach indicating that endpoint state embodies endpoint attributes (they may as well be synonymous), and that state may be volatile or non-volatile. Then, configuration is sometimes used interchangeably with state or attributes.

[henkbirkholz]

A comparison in a nutshell: Configuration is static and modified via the management plane. State is non-static result of interacting functions (and corresponding components) via the the control plane. A distributed automated system cannot function without a working control plane (as it cannot create state via interaction of components/functions), a system can survive for quite a while without a working management plane (configuration cannot be changed and components/functions cannot be monitored though).

I.e. no - state is not configuration. I would recommend to never refer to configuration as non-volatile state. Configuration of multiple system entities begets state. Please note, in my personal opinion the sometimes colloquially used term "endpoint state" combines two of the most misleading words used in the SACM WG into an even more misleading term.

I'd rather adopt the rather exotic and still emerging terminology - and therefore moving target - from I-D.ietf-netmod-revised-datastores: intended, dynamic, system, learned and default configuration. In this realm of definitions (which significantly diverges from 4949 at some points) "origin" is the taxonomic parent of these terms (origin being a specific subset of the term data provenance wrt "how did this value came to be") and learned configuration would be the semantically closest to state as currently defined in SACM wrt to YANG.

I am opposed to change the core semantics of the current definition, but in strong favor of improving it. In consequence, I propose to word-smith the current text instead of trying to introduce a third realm of definitions, where "state" is the taxonomic parent of every other term. In general, I think it is vital to state (sry for the pun) that configuration is imperative guidance.

[strazzie123]

I agree with Adam that the current definitions of configuration and state are insufficient (sorry Henk!).

Also (sorry again Henk!) I fail to understand why either is tied to an endpoint. If we go back to control theory, the behavior of a functional block is defined by a transfer function that, for a given set of inputs and state, produces a given set of outputs. An endpoint is an externally visible point of the functional block, but do we really, really, really want to expose all endpoints? That would produce a huge attack surface.

Henk wrote: A distributed automated system cannot function without a working control plane (as it cannot create state via interaction of components/functions), a system can survive for quite a while without a working management plane (configuration cannot be changed and components/functions cannot be monitored though).

I disagree. The management plane is used to configure the control plane. If the management plane dies, so does the control plane.

Henk wrote: state is not configuration. I would recommend to never refer to configuration as non-volatile state.

Absolutely agree (see Henk, I still luv ya :-) ) Note that this is true in YANG as well (assuming that we want to build YANG data models at some point).

Given the above, I agree to wordsmithing the current definition.

best regards, John

On Thu, Dec 14, 2017 at 5:54 AM, Henk Birkholz notifications@github.com wrote:

A comparison in a nutshell: Configuration is static and modified via the management plane. State is non-static result of interacting functions (and corresponding components) via the the control plane. A distributed automated system cannot function without a working control plane (as it cannot create state via interaction of components/functions), a system can survive for quite a while without a working management plane (configuration cannot be changed and components/functions cannot be monitored though).

I.e. no - state is not configuration. I would recommend to never refer to configuration as non-volatile state. Configuration of multiple system entities begets state. Please note, in my personal opinion the sometimes colloquially used term "endpoint state" combines two of the most misleading words used in the SACM WG into an even more misleading term.

I'd rather adopt the rather exotic and still emerging terminology - and therefore moving target - from I-D.ietf-netmod-revised-datastores: intended, dynamic, system, learned and default configuration. In this realm of definitions (which significantly diverges from 4949 at some points) "origin" is the taxonomic parent of these terms (origin being a specific subset of the term data provenance wrt "how did this value came to be") and learned configuration would be the semantically closest to state as currently defined in SACM wrt to YANG.

I am opposed to change the core semantics of the current definition, but in strong favor of improving it. In consequence, I propose to word-smith the current text instead of trying to introduce a third realm of definitions, where "state" is the taxonomic parent of every other term. In general, I think it is vital to state (sry for the pun) that configuration is imperative guidance.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sacmwg/draft-ietf-sacm-terminology/issues/63#issuecomment-351716762, or mute the thread https://github.com/notifications/unsubscribe-auth/AJgkSayrLG-4VS7pefIMP9KSSN5guRgaks5tASiQgaJpZM4Q8hfK .

-- regards, John

[henkbirkholz]

Okay, lets delve into the finer nuances of this.

tl;dr the definitions of configuration and state require some work. Jarrett already indicated that at the mic, if I remember correctly. Functions are essential to the architecture.

I admit to simplifying the topic at hand. I still disagree with the notion of the control plane dieing, if the management plane dies. It continuous to function, but probably not with the intend it is supposed to function, if environmental requirements change (as you are unable to influence behavior of the control plane anymore). It might not act in a way you require it to do anymore, but it does not die. It "just" not acts according to updated requirements imposed to it by management plane updates and therefore it will not be compliant to current imperative guidance. It is "just" deprived of imperative guidance updates.

I.e., it will not be in compliance with current imperative guidance anymore, but it does not "die" and the SACM domain should be aware of that state (see, I still agree with you :-) )

And yes, the definition most certainly requires some love, I agree with that, too.

I also agree with the notion that control plane behavior should not be tied to "endpoints" but "functions". Alas, the term function has been pruned currently and as a result "endpoint" is the next level in the taxonomy of terms it can be tied to in the current version of the draft. Essentially, control plane behavior is of course steered by control plane functions (located on SACM components that are endpoints), but I agree it is not the endpoints that are in charge of orchestrating control plane behavior, the corresponding functional blocks located on SACM components are. In consequence, no - we really do not want to expose all the endpoints in this scope. That is the reason why there was the definition of functions that just got removed, in the first place.

[adammontville]

Then the proposal would be to bring back SACM Function and clean up state/configuration, possibly by adopting some terminology from I-D.ietf-netmod-revised-datastores: intended, dynamic, system, learned and default configuration. ??

[henkbirkholz]

This might be partially resolved via issue https://github.com/sacmwg/draft-ietf-sacm-terminology/issues/31 soon.