Update openid-caep-1_0.md#329
Conversation
Add an 'unmanaged' option to current_status in device compliance change event.
| > | ||
| > * `compliant` | ||
| > * `not-compliant` | ||
| > * `unmanaged`: The device is no longer being managed, and additional compliance change events may not be sent for this device. The device’s compliance state is unknown |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
@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).
There was a problem hiding this comment.
Please change title to "1.1 - Draft"
There was a problem hiding this comment.
How do we ensure the date is automatically updated? @jischr you had investigated this, right?
There was a problem hiding this comment.
Yep - remove line 6 and then the date gets automatically populated when the html and xml are built
Add an 'unmanaged' option to current_status in device compliance change event.