Resolved: OpenC2 commands shall embed conditional logic within the frame.
jmbrule opened this issue · 5 comments
PROBLEM
Statement for: Embedding conditional logic within a command will enable 'contingency', reduce the burden on the orchestrator and provide a better response if information regarding state is incomplete.
Statement against: General increase in delays & processing overhead to parse/ execute the commands as well requires additional complexity/ capabilities on OpenC2 compliant devices. Conditional logic should be left in the analytics and decision engines.
POTENTIAL SOLUTION
(Propose a potential solution.)
I like leaving the logic in the orchestrator. I suggest leaving the commands straight forward and simple.
Once a command is send with imbedded logic it's actions are frozen until the action device can sort through the logic and execute.
The time spent crafting a complex command may render the information that was used, to become "past due date" (like chunky yogurt) before it's sent.
I worry about spending cycles crafting a command with imbedded logic without knowing if the action device can't accept or act on the command due to circumstances known only to the action device.
So I like letting the orchestrator have the opportunity to see an ACK from the action device (yes I am alive !) and letting the orchestrator use info resulting from "responses" with other information at it's disposal or breath of view at that instance of time craft the next command.
I'm opposed to conditional logic in OpenC2 message frames. Conditional execution introduces too many ambiguities about the final state of the actuator, making it difficult for the orchestrator to know the end result.
If logic such as "(do U and V) or (do W and X)" is allowed, then the possible outcomes are [ nil, (U), (U,V), (U,W), (U,W,X), (W), (W,X) ].
Seven different outcomes:
- three forms of success [ (U,V), (U,W,X), (W,X) ]
- four forms of failure [ nil, (U), (U,W), (W) ]
The orchestrator will not know the final state of the actuator simply by identifying "success" or "fail". I feel that conditional logic also blurs the line between "decisionmaking" and "acting" since evaluating conditional results is a simple form of "decisionmaking". I feel a complex sequence of actions and conditions is better termed a "workflow", and should be labeled an external dependency.
In other words, if people need it, maybe someday there can be a portable Workflow language, but better to get OpenC2 working with simple actions first.
I would like to close this action. Please provide additoinal comments by COB 5/23/2016. I will take an action to produce a construct.
Closing with recommended resolution:
Keep conditional logic out of the base OpenC2 action language. Reserve conditional logic for domain-specific and/or extension languages.
We will be adding explicit statements into the language document that this is external to the language. I don't believe that a construct is needed. This thread provides the rationale very well.