Query Features Level of Inception Issue

[dmg2]

In 4.2.2 Example 2 of the LCS

Problem: We see an example of Query/Features. The following response shows "version", "rate_limit", and a list of multiple "profiles" supported. Although seemingly a useful command/response pair I am confused as to how I would implement this practically.

Assumption: 1) Consumers can support multiple actuator profiles.

Discussion: Almost every example prior to this one makes reference to a specific actuator profile in order to respond, but in this case it seems as if the response is being generated by a high level process that has some unified understanding over all of the actuator profiles present on a consumer. Furthermore if my query features command included not only "profiles" but also "pairs" how would this result look? which pairs correlate to which profiles? Is this the only case in which we make reference to the whole consumer? How do we validate this response? Is the need to recreate level of inception in this case on purpose or oversight?

It seems to me that keeping our level of inception the same through out all of the interactions would be a better course of action. One way to achieve this may be to create a "consumer" actuator profile which is supported by all consumers to promote "query features". The information returned from this default actuator profile would pertain to the whole consumer. It would have a schema that would allow for this type of validation. Then we utilize "query features" in each individual actuator profiles to return information specific to the profile, not the whole consumer.

[patconnole]

I like your solution of a mandatory Consumer-level Actuator Profile, to address Consumer-level OpenC2 Commands, such as query-features["profiles, pairs"], etc. To respond to that command, a consumer needs a higher level process that is aware of what Transport is used, and what Actuator Profiles are implemented.

Let's put a name on that higher-level process and call it Consumer Actuator.

The use of a higher-level process isn't new to anyone, the language calls it a Consumer; but let's define its behavior in its own Actuator Profile.

---

Spring-boarding here, the above solution to the query-features problem could also address other issues. We could let this Consumer Actuator Profile define the interface between the Consumer's transport-termination and Actuators, which is otherwise murky.

A Consumer Actuator Profile could define the Consumer's...

1. Behavior when answering Consumer-level commands, such as query features, rate limit, etc
2. Behavior if it implements multiple actuator-profiles, overlapping pairs, etc. Dispatch to all, some, etc?
3. Transport behavior: delayed response, out of session, multiple responses, etc

While the regular Actuator Profiles define..

1. What commands the specific actuator will accept
2. What the actuator does in response to a command
3. What its own response(s) to that command are. (Though the Consumer Actuator determines if the regular Actuator even receives the command, and final decision if, when, how, the response(s) are delivered).

This "Consumer Actuator Profile" is starting to look like a meta-profile, or a way to unify multiple profiles on one consumer; i.e. "Hey - it would be easier if we only allowed one actuator profile on a device! Can we do that? No? Ok, how about just combining them all into one into one profile/schema? Best of both worlds!" It seems otherwise, we are left with undefined behavior, especially with multiple actuator profiles.

[davaya]

Parallel to our document structure (Architecture + LS + profiles + transfer specs), another word for the "Consumer Actuator Profile" is Language Spec. The LS defines universal commands and their behavior (currently only query-features, but others could be added) at the device/consumer level. Reponses to profile-defined commands appear under the profile name, responses to the consumer are at the top level.

Example: consumer that supports slpf and blinky profiles:

Command:

{
  "action": "query",
  "target": {
    "features": ["versions", "profiles", "pairs", "rate_limit"]
  }
}

No actuator profile is specified in the command - response should contain data for device and all profiles.

Response:

{
  "status": 200,
  "results": {
    "versions": ["1.1"],
    "profiles": ["slpf", "blinky"],
    "pairs": {
      "query": ["features"]
    },
    "rate_limit": 30,
    "slpf": {
      "pairs": {
        "allow": ["ipv6_net", "ipv6_connection"],
        "deny": ["ipv6_net", "ipv6_connection"],
        "delete": ["slpf/rule_number"],
        "update": ["file"]
      }
    },
    "blinky": {
      "pairs": {
        "query": ["blinky/device"],
        "set": ["blinky/display"]
      }
    }
  }
}

The separation of LS responses and profile responses affects examples in the LS and all profiles, which will need to be updated. Examples are not normative.

Note that profile-defined targets (slpf/rule_number, blinky/device) are paths starting with the profile property name and using the path separator (/), not a namespace prefix with a colon.

[dlemire60]

Parent of other issues identified above. next version. @davaya and @Vasileios-Mavroeidis to address