Is there a requirement to indicate why intended config != applied cfg?

[rgwilton]

Is there any requirement to indicate why an applied cfg node doesn't match the corresponding intended cfg node? E.g. reasons could include: config is in progress, missing hardware dependency, or an internal error or failure.

[einarnn]

If there isn't a requirement to indicate this, I suggest it be added. And I suggest that all proposed solutions should factor this in. If there is some reason why the "applied config state" of the device does not match what was intended by the end user, regardless of how this is represented in the proposed solutions, the device is the best place to provide data on why this is the case as it has all the relevant information to hand.

[kwatsen]

It's nice to have, but not required