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/

openc2 message