Re: Command-ID = or != Https Correlation ID

This is part of an almost-persistent blurring of Language and Serialization that is pretty consistent, and that is concerning to me.

In the language of the OMG, the Language and the promised-but-not-here Architecture section of the Language, is in effect the PIM (Platform Independent Model), and each of its Serialization/Binding documents is a Platform Specific Model (PSM). One of the Profiles, i.e., the Actuator Profile, should be expressed in the PIM, but instantiable in each PSM.

The PIM should support all the PSMs, but not specify one. It is an artifact of development and current thinking that the TC has opted to express the language and information model using JSON, but a PIM is still fundamentally abstract, that is, it should not interfere with or dictate the possible PSMs.

The Language document explicitly allows (but does not require) multiple in many places. A message MAY contain many commands. A command MAY contain many Targets. A PSM MAY constrain a message to be a single one of each, Command and Target.

If (as seems the case) the JSON Binding is restricting to one command and one target. That is a fine decision for a PSM, and I have no complaint about that.

The architecture, though anticipates some other interactions. These include:

A single message having multiple commands. At a later time, it may be appropriate (as Duncan’s note suggests) to change or revoke a specific one of these commands.
A Target may wish to respond to individual commands with separate messages.
A Bridge device may need to unpack a multi-command message into multiple messages as it bridges a command to a different PSM
A Bridge device may need to unpack a single-command message into multiple single-target messages as it bridges a command to a different PSM.
A Command or Message may need to be re-transmitted, either because of some sort of race state in the target (it may be under attack, after all) or for incorporation into a suite of responses/commands to a particular situation or incident.

In each of these cases, it is troublesome to have blurring between the transport mechanism (which would include header info) and the message payload.

That said, IF a PSM restricts a Message to a single Command, and IF a PSM expects a MessageID within the command, then it MAY be reasonable to make the MessageID and CommandID identical. Alternately, it is reasonable that IF a PSM requires a single command inside a Message, to require them to be the same.

From: openc2@lists.oasis-open.org <openc2@lists.oasis-open.org> on behalf of duncan sfractal.com <duncan@sfractal.com>
Sent: Sunday, September 30, 2018 10:52:08 PM
To: TC OpenC2
Subject: [openc2] Command-ID = or != Https Correlation ID

I apologize but I will not be able to attend the F2F so I am submitting a comment on the language specification via email. Unlike my other email, this is likely to take more than 2 minutes to discuss in the F2F as it is an objection to a proposed normative change. Dave Kemp proposed to add

“The value of the id field, if present, MUST equal the value of the request_id message field described in section 3.2.”

to section 3.3.1. You can read Dave and I arguing back and forth in the google doc comments and apologies to all who have listened to our arguments in the LSC meetings, but I would like to express my objection via email since I can’t be at the F2F where this will hopefully be decided.

I don’t see the value of making the command-id be the same as transport fields.

We’d previously agreed to have an optional command-id as a field in the openc2 command. I am being specific in saying “in the openc2 command” as there has been much discussion on the topic of an openc2 command having metadata associated with it (sometime called “header” information) that may have common components with transport elements. I am particularly concerned with the field called command-id that is a peer field to action/target/etc.

There are two main uses that have been discussed wrt command-id –

(1) correlating command/response and

(2) canceling a previously issued command, particularly one that hasn’t been executed yet (eg with a future start-time or with duration that isn’t over yet).

I strongly believe the command content (ie the JSON in the block with action/target/id/etc) should not be dependent on information provided by transport. The statement above requires the command-id be dependent on the request-id which is tied to the HTTPS X-Correlation-ID field (or equivalent for other transports). I have several issues on this. First and foremost is I think the command-id should be created by the openc2 producer first thing and not be dependent on anything provided by the transport layer. If they must use the same value (I’m not convinced they must) then I think the transport should be dependent on the command, not vice versa (ie don’t approve statement above in the LS but add it to the transport specs saying HTTPS X-Correlation-ID field must equal command-id). I’d prefer they be independent but if they have to be the same, make command producer the creator. I am fine wth X-Correlation-ID field being used to correlate https (or equivalent) request/response if it is independent of command-id. For the purposes of the ‘delete command’ I think the unique command id should be used (ie for purpose (2) eg deleting the command).

I will go with the will of the group since I do want these standards to be adopted, but I do feel strongly they would be better with the command being transport-agnostic (which I feel this change would break). Since I can not be present, I would like if someone could object to this change for me and at least get it to require other proponents. Ie so a straw poll not just of who objects but who supports vs who doesn’t care. No one objects (since Duncan not present) is different than 10 people think it should be that way. If more people want it than don’t (it it’s more than a 1-0 vote),I’ll concede.

Apologies again for missing the F2F but my conflicting trip has been planned with friends for 2 years and I could not change it when the F2F was scheduled for the same time.

Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

I welcome VSRE emails. Learn more at http://vsre.info/

VSRE: Very Short Reply Expected

vsre.info

VSRE stands for very short reply expected. It's a way to show your email recipients that you expect them to reply with no more than five words -which should make our lives much easier.

openc2 message