OASIS OpenC2 TC: GitHub repository used to propose and track changes to the OpenC2 Language Specification as new working draft level revisions are created and the associated CSDs mature
Some Actions are defined in the LS very specifically such that they seem designed to only apply to certain targets. Actions not being extensible is a good standardizing feature, but makes the specificity of certain actions difficult. Investigate in particular seems to have Targeting explanations written into its definition, such that it cannot be used outside of security events or incidents. This could lead to proposal of new APs where the most intuitive description of an action is reserved for a specific target. In our PACE scenario, our decision maker sends an OpenC2 command to an intermediate OpenC2 device, which then creates a new command derived from the original to be sent to subordinate OpenC2 consumers. These consumers send data back which is stored in a data repository. The original command is currently being done with Query, since information exchange is involved, as it cannot use Investigate. The intermediate does not have the data queried, nor any ability to get it necessarily, so the fact that it is sending a query seems correct, but the same command syntax for the upstream command seems strange. The decision maker is attempting to gather data and store it somewhere else for evaluation, but Store is not an action and Investigate is defined in the LS for a particular use.
Similarly, "Update" being specifically reserved for Software Update functions puts Config and other file updates in an awkward position of technically being outside the LS usage.
Some Actions are defined in the LS very specifically such that they seem designed to only apply to certain targets. Actions not being extensible is a good standardizing feature, but makes the specificity of certain actions difficult. Investigate in particular seems to have Targeting explanations written into its definition, such that it cannot be used outside of security events or incidents. This could lead to proposal of new APs where the most intuitive description of an action is reserved for a specific target. In our PACE scenario, our decision maker sends an OpenC2 command to an intermediate OpenC2 device, which then creates a new command derived from the original to be sent to subordinate OpenC2 consumers. These consumers send data back which is stored in a data repository. The original command is currently being done with Query, since information exchange is involved, as it cannot use Investigate. The intermediate does not have the data queried, nor any ability to get it necessarily, so the fact that it is sending a query seems correct, but the same command syntax for the upstream command seems strange. The decision maker is attempting to gather data and store it somewhere else for evaluation, but Store is not an action and Investigate is defined in the LS for a particular use.