Definition of Actuator

[davaya]

The Architecture Spec, being derived from the Language Spec, inherits the inconsistent meanings of "Actuator" that have existed since the beginning of OpenC2. The Glossary definition:

Actuator: The function performed by the Consumer that executes the Command (e.g., "Packet Filtering")

directly conflicts with the Command definition:

Actuator (optional): The Actuator executes the Command.

Since the English meaning of actuator is "a device that causes a machine or other device to operate", and the Command has always named the Actuator Profile that describes the operation to be performed, the choice of "actuator" as the Command property name was incorrect. Given the ongoing confusion caused by that choice, the property name should be fixed so that it does not conflict with the intended meaning: Command should have properties {action, target, args, profile(s)}.

Because modifying property names is a breaking change it will have to wait for a new OpenC2 major version (v2.0). In the meantime, the planned modification should be documented in v1.1, and all descriptions related to the "actuator" field should be made consistent with the field named "profile".

Decisions to be made:

• Should profile be singular or plural? (Can a single command perform operations defined in more than one AP?)
• Can actuator/profile specifiers be moved to command arguments, simplifying the command and eliminating questions like "does this belong in args or specifiers?".

Related to ER Issue #31 (oasis-tcs/openc2-ap-er#31)

[Vasileios-Mavroeidis]

Agree that the planned modification should be documented but also the Command definition for Actuator MUST be updated.

Similarly, this confusion has influenced what we have included as actuator specifiers in SLPF and PF. Ill open an issue soon for the PF actuator profile to address that.

With regards to questions:

1. How do you envision such a command? What comes to my mind as an example is the following. A command block/ipv4_address with profile specifiers "edr" and "pf". Devices that support each profile will implement the command in a different way.

2. At the end of the day we have concluded that actuator currently refers to profile, but what about specifiers? Do you have an example set of "profile specifiers", other than specifying only the profile (e.g. "er")? It will help make a decision.

[davaya]

1. A command deny/ipv4_address with profiles "edr" and "pf" would be executed by a device that supported both profiles, and would be implemented in a different way. The result would have separate profile sections but only a single status - that could be a problem. And the command would have to be the same for both profiles; an edr-defined target would not be understood by pf.

So allowing multiple profiles seems like premature optimization - it has known issues to be resolved but unknown benefits. The only pro is that it doesn't have to be used; implementations can always specify a single profile in an array "[edr]", and if a use case that doesn't have any issues comes up, it could be accommodated without a breaking syntax change "[edr, pf]".

I think profile should be singular, not a list.

2. I can't think of any example "profile specifiers". I think "profile" should be be just a name, not a structure with specifiers.

[dlemire60]

This appears to be related to LS issue 90: oasis-tcs/openc2-oc2ls#90

[dlemire60]

Related to LS PR 404. Ideally should be addressed before finalizing v1.0 of the Architecture Spec as a CS.