Add all-slpf-devices query-profile example to CDS04

[sparrell]

in addition to issue #19, an example of a profile query to all slpf would help in understanding.

I think this example should be in the appendix (complete with topic, message, content) and referenced in section 2.2 as example of
topic: oc2/cmd/ap/[actuator_profile]

[dlemire60]

I think this raises an interesting question: if query features profiles is directed at devices with a specific AP (either by pub/sub topic selection or using the actuator field in the request), is the desired response "all profiles supported by that consumer"?

Example 1 (pub/sub): producer sends a query features profiles request to oc2/cmd/ap/slpf, with no actuator field in the request. I think the correct response is that any consumer that implements the SLPF AP should respond with all APs that consumer implements. But it's worth considering that at least for a moment.

Example 2 (pub/sub): producer sends a query features profiles request to oc2/cmd/all, with 'slpf' specified in the actuator field in the request. Is the correct response that any consumer that implements the SLPF AP should respond with all APs that consumer implements, or just respond with slpf so that the producer can identify consumers that implement slpf?

Example 3 (point-to-point): producer sends a query features profiles request over, e.g., HTTP(S) to a consumer with 'slpf' specified in the actuator field in the request. Is the correct response for that consumer if it implements the SLPF AP to respond with all APs that consumer implements, or just respond with slpf so that the producer can confirm the consumer implements SLPF? And if the consumer in this point-to-point case doesn't implement SLPF, is the response some kind of error, or just the list of profiles it does support?

[sparrell]

I think we need to straighten out terminology between device, actuator, actuator profile. I think we allow a device to have multiple actuator profiles. I personally do not think of the functionality associated with a profile (eg slpf) as a 'different' device. It's not clear to me if it is a 'different' actuator. I do think we should distinguish between 'actuator' (the thing doing the function and the 'actuator profile' (metadata about the 'actuator'). I personally think actuators are functions of a device, not 'sub-devices' (ie they are not things in themselves). I pretty sure others think differently. I think we need to resolve this to be able to resolve the other issues.

[dlemire60]

I agree this should be clarified, and then documented in the architecture. Is it worth raising the topic at the January TC meeting to tee it up for an in-depth conversation at the February L-SC?

[davaya]

I'd start by assuming that device id is what goes in the message to/from field - URL or pub topic. Thus device = message sender / receiver = OpenC2 producer / consumer.
A profile is a functional area = metadata about a device.
A device can support multiple profiles.
The actuator field (= profile name) of a command limits execution of commands received by the device to those defined by a single profile.
Responses to commands without an actuator field must be separate, a query to a device must respond [profile A: response A, profile B: response B]. The query features command is defined in the LS so it's response would not be under a profile.

So a message can be directed to a set of devices by topic, but not by actuator field.
Example 1: any consumer <that implements the SLPF AP> should respond with all APs that consumer implements. (<...> indicates strikeout.) The response is as documented in the LS.

Example 2: producer sends a query features profiles request to oc2/cmd/all, with 'slpf' specified in the actuator field in the request. Because query features is an LS command, the response contains all profiles supported by every device that received the message, not just devices that support slpf.

Example 3: (point to point). Response contains all profiles supported by the device. E.g., for commands defined by the LS the actuator field of the command is always ignored.

A device supports all LS commands and all commands defined by its supported profiles, but when the actuator field is present it responds only to LS commands and the single specified profile. We wanted V1.0 to KISS, but in theory v2 could list more than one actuator and its supported specifiers in the actuator field. That's a non-compatible change so would have to wait for a new major version if we wanted it.

[davaya]

See oasis-tcs/openc2-oc2ls#365