Add an option to report device management status change to device compliance change signal

[ysarig75]

Add an 'unmanaged' option to current_status in device compliance change event.

[martingalloar]

I believe using "unmanaged" here might be confusing, and also from a flow/transitioning perspective can potentially lead to dead end scenarios if the previous status is "unknown".

I'd suggest normalizing into the same value (either "unknown" or "unmanaged") for both previous and current status.

[ysarig75]

@martingalloar previous_status and current_status are not symmetrical. I added unknown to previous_status because it is possible that the transmitter doesn't have information on the previous status to send. For current_status, unknown is not very useful to send as it is not clear what a receiver will do with such a status.

[thomasdarimont]

Since the previous_status is required how about using "unmanaged" as the initial "null" value.
With this we might not need the "unknown" value anymore IMHO.

So a device could transition from (initially) unmanaged -> not-compliant -> compliant -> unmanaged (again once removed / retired).

[ysarig75]

@thomasdarimont The problem is not the transition of the device status (which is communicate using current_status field but the fact that the previous state is currently required and the transmitter doesn't necessarily know what was the previous_state. So a transmitter may send a current_status=compliant and a a month later, the device become unmanaged and the transmitter want to send a current_status=unmanaged signal but at that point, the transmitter may not know what was the previous_state.

[appsdesh]

@ysarig75, what if the device becomes managed from unmanaged? How would it be represented, as previous_status does not have unmanaged

My alternate proposal is to add a new key current_management_status to the event with the values unknown, managed, unmanaged

This way, we do not need to worry about Tx/Rx that do not know how to process new values in the existing claims.

[ysarig75]

@appsdesh I like adding current_management_status as you described but we will also need to add unknown to both previous_status and current_status because they are mandatory (you can't just send a current_management_status in a signal).

[appsdesh]

@ysarig75 related issue and proposal I had long back here #131

[tulshi]

Please change title to "1.1 - Draft"

[jogu]

That's already been handled in #310 - I'd suggest finishing that MR first.

[tulshi]

How do we ensure the date is automatically updated? @jischr you had investigated this, right?

[jischr]

Yep - remove line 6 and then the date gets automatically populated when the html and xml are built

[jogu]

I think we should clarify who can use them, although maybe some of that belongs in the interop profile. But for here it could be useful to e.g. say if we recommend that transmitters should continue to support the 1.0 events so that 1.0 receivers interoperate with them.