Refine Command Argument: direction

[Vasileios-Mavroeidis]

In section 2.1.3.2 We have defined a new command argument direction of type Direction and we specify that the argument

"Specifies whether to apply rules to incoming or outgoing traffic. If omitted, rules are applied to ingress packets."

I propose removing the second sentence.

What is stated is actuator-specific - the default behavior of the technology. An actuator that gets an OpenC2 command without the argument direction populated will treat the command based on its default behavior (vendor's decision). If the actuator requires specifying the direction, then we should do it. If we don't specify the direction and the actuator does not have a default behavior for such use cases, then the command is invalid.

[Vasileios-Mavroeidis]

The usage requirements of the argument specify that:

If absent or not explicitly set, then the Command MUST apply to both.

This is in opposition to the description of the argument.

I suggest removing this description/sentence too.

[Vasileios-Mavroeidis]

At the Feb 9th meeting we agreed to refine the language in the spec than eliminating the default behavior of the actuator in the case that the direction argument is not populated. It is a fact that many packet filters dictate default behavior "ingress" when the direction is not specified. An example can be seen here: https://cloud.google.com/vpc/docs/firewalls#direction_of_the_rule

Also, the usage requirements of the argument specify that when absent or not explicitly set, then the Command MUST apply to both. This is wrong and will be removed.

[dlemire60]

Notes from 9 Feb 2022 working meeting read:

Discussion of "optional with default" or "mandatory" options. Some members desire non-ambiguous operation. Neither existing wording or proposed changes correctly capture what is desired. Changes needed.

No proposed changes have ever been presented.