All,
Recall that the OpenC2 TC accepted the SLPF profile as a CSD. I am in the process of trying to resolve comments.
I have not touched the conformance section, the example command annex nor has the jadn annex been drafted.
There are a LOT of edits in the document via 'suggest mode'. Many of the edits were to be self-consistent, for example change 'options, modifiers' to 'arguments'. A lot of the edits that you will see involve summarizing and moving the responses and targets
from the 'command' section to the appropriate subsection.
Some of the edits are substantive and we need to achieve consensus. Please consider the following prior to the Wednesday dial in:
- Specifiers to support packet filtering by cloud service providers: There is an email thread regarding how to go about this. The text I put in section 2.1.4 should be considered as a placeholder and will defer to the wisdom of the group if this should
be a list, a delimited string or some other approach. Once we decide on the format, will need to decide on a generic means of specifying a cloud based firewall. As of now, the three fields are account-id, region-id and vm-id.
- Rule-number vs prepend: This topic precedes the recent CSD vote. We needed to support the delete command so that a rule could be removed rather than issue an allow or deny to counteract a previous command. There were two approaches; ONE use a 'pre-pend'
option that would instruct the actuator to put the new deny or allow at the beginning of the rule set (rather than default append) or TWO have the orchestrator explicitly assign the rule number. The first option makes it simpler for the orchestrator (does
not have to maintain a copy of all rule sets for the firewalls) the second option permits finer control (lets the orchestrator insert the firewall rule in a precise spot)
- Update file command: Initially the AP SC suggested a bottoms up approach, that is write the profiles and as time proceeds, identify the common commands and move it to a 'generic' profile. Later it was decided to simply refer to the generic profile and
only have actuator specific commands in the SLPF profile. Currently, we do not have 'generic commands' and we have a comment to remove the generic profile from the language spec. Need to decide one way or the other
- Response table: A start was done on the response table. The idea was to have all the responses in one spot for ease of reference. Should the table be augmented so that the reader can determine the correct response based on the table alone, or should
the table cross reference the appropriate subsection in the command section?
BTW, I know that the following has not been addressed yet:
- Either in the introduction directly, or by referencing some other document, the document needs to explain what an actuator profile is, and how it relates to language specification and transport and especially to other actuator profiles (ie one device can
have more than one profile, including custom profiles).
- Some of the OpenC2 examples, for example on page 31, are not properly formatted JSON.
Thank you
VR
Joe Brule