[CAEP] device management change is not captured in the existing events

[appsdesh]

In the world of device management, the device management signal is very important. It does not directly map to the device compliance status.

Device compliance status could be the result of evaluating the compliance policy (output of a policy decision engine). In certain cases, device management status maybe needed to evaluate policies (input to the policy decision engine).

Given that a managed device may or may not be compliant and this information is important in the continuous access evaluation.

I am proposing following change to the device compliance CAEP event

Option 1 - Management status via new keys

1. Mark existing current_status and previous_status as optional to avoid mandating compliance status
2. Add additional 2 keys current_management_status and previous_management_status as OPTIONAL fields to communicate current and previous management status.

Pros -

1. Transmitter is able to combine compliance and management changes in the same event, helpful in the scale.

Cons -

1. Increased event size in the case when both compliance and management status is conveyed

Option 2 - Extend the values of existing keys

1. Allow new values in the current_status and previous_status keys
   ** managed
   ** not-managed

Pros -

1. No size increase for the event, reusing the keys
2. Transmitter is able to combine compliance and management changes in the same event, helpful in the scale.

Cons -

1. May not be able to represent management change and compliance change together, due to key reuse

Option 3 - A new event called device management change

Define a new event as device management change to solely communicate device management change. This new event will have current_status and previous_status keys and values defined in the Option 2

Pros -

1. Cleaner separation of two constructs

Cons -

1. A new event to fire and consume for Tx/Rx pair

[timcappalli]

I'd prefer option 3. Device management status and device compliance are very different signals.

Device management status is often one piece of context that is used to determine device compliance.

[appsdesh]

I agree with @timcappalli.

My preference is in the following order -
Option 3 (Most favorable)
Option 1
Option 2 (least)

[tulshi]

I agree that option 3 is a good one, although I'd like to call the event "device management status" (IMO we should stop using "change" in event names, because all events indicate some change). I feel the two events "device compliance" and "device management" are different, so having both of them co-exist is fine.