[[ I wasn t planning to comment on the SLPF spec for the PRD-02 deliverable, since I m not supporting it in my product today, but a quick scan through it caught a few topics of discussion, so even though this is
after the official PRD review timeframe , please consider them as comments from myself as a TC member]]
As a member of the Technical Committee, the OASIS process requires that I send my own comments to the TC directly, as opposed to using the openc2-comments mailing list. As such, I have combined all my comments
into this single message (and, hopefully, sent them to the proper list!).
These comments are related to Profile for Stateless Packet Filtering Version PRD-02 (dated April 04, 2019; PDF version).
Section 1.4, Page 10: Should have a link to the Active Cyber Defense paper, which is
https://www.semanticscholar.org/paper/Active-Cyber-Defense-%3A-A-Vision-for-Real-Time-Cyber-Herring-Willett/7c128468ae42584f282578b86439dbe9e8c904a8 Section 1.4, Page 10: Should have a link to the Integrated Adaptive Cyberspace Defense paper, which is
https://www.semanticscholar.org/paper/Integrated-Adaptive-Cyberspace-Defense-%3A-Secure-by-Willett/a22881b8a046e7eab11acf647d530c2a3b03b762 Section 1.5.2, Page 11: The first example shown for OpenC2 in the spec is not compliant with the spec as it refers to a user_account target, which is not part of the language. The very first example
that readers see should accurately reflect a compliant command, like a deny/file/hashes/sha256 command. I can supply an example if necessary, but using user_account definitely feels wrong to me at this spot in the document.
Section 1.6, Page 14: The description for the Message layer uses the term requests and responses . In the Terminology section (1.2, Page 8) there is no definition of what a
request is; only what a command is. The previous page (13) describes a Command and Response payload, which is correct, yet we seem to talk about Message in terms of Request and Response . I think there is a disconnect in the Language Spec. I think
the description of the Message layer should read: The Message layer provides a transfer- and content-independent mechanism for conveying Commands and Responses. A transfer specification maps transfer-specific protocol elements to a transfer-independent set
of message elements consisting of content and associated metadata. This clarification should bubble up into the other specs (since this is common boilerplate that is currently copied to all 3 specs), and the msg_type description in the Language Spec
(Table 3-1, Page 31) should be changed to say One of command or response . For the application/openc2 content_type the request content is an OpenC2-Command and the response content is an OpenC2-Response. , which is correct and also more consistent
(the command and response stuff now matches perfectly). And finally, note that the Language Spec request_id field in that same table says A unique identifier created by the producer and copied by consumer into all responses, in order to support reference
to a particular command, transaction or event chain. which, even though the field has request in its name, describes only a command in the description (and also doesn t appear to properly capitalize the Producer or Consumer or Command
parts here either, but that s a different subject). There is clearly some terminology looseness that I feel can be tightened up easily.
Table 2.1.3-2, Page 22: The running field seems oddly named to me. The description explains that normall any config changes are made persistently, but the word used to change this fact is running . Why wouldn t we choose persist as the Boolean or persistent
instead? So, the default for the persist field would be TRUE, but you could override this by setting persist to FALSE. To me, that is clearer than running , which is a state that is independent of whether a configuration is persistent (or non-volatile).
I don t feel strongly about this comment, but wanted to throw it out there for discussion
Table 2.1.3-2, Page 22: For the direction field, I find it odd to use an enumeration here, as there appears to be only two possible things that would be enumerated ( ingress or egress . If there are only ever two possible options, a Boolean may make more
sense, or the addition of a both option to the enumeration to explicitly set the rule to include both (which is the default). Again, I don t feel strongly about this, but the use of enumerations for two possible items would usually result in an architectural
discussion for me
Table 2.3-1, Page 26: Love the table, and it s a great example for other Profiles to use. However, this particular profile does appear to support OPTIONAL action/target pairs, and it would be nice to indicate the OPTIONAL ones in this table (like with an asterisk
[*] or something) instead of having to discover the OPTIONAL ones in the text details. This is strictly an editorial suggestion to improve readability.
Section A.1.1, Page 42: The example Command uses an actuator with a single field of slpf:asset_id , but this does not match the exact same example included with the Language Spec PRD-02 Section 3.1.5, Page 28, which shows an example of a higher-level slpf
field with a sub-field of asset_id . These discrepancies need to be resolved at our Face2Face meeting
Section A.1.2, Page 43: The example for deny/ip_connection is specifying a Target of ip_connection , which is not a valid target in the Language Spec, so this example is invalid and misleading.
Section A.1.3, Page 44: Same comment as above about the use of the slpf field in the actuator object (the Language spec implies that all these fields should be under the slpf filed, which is itself under the actuator top-level field.
Section A.3, Page 46: The example update/file Command uses an actuator with a single field of slpf:named_group , but this does not match the similar example included with the Language Spec PRD-02 Section 3.1.5, Page 28, which shows an example of a higher-level
slpf field with a sub-field of asset_id . These discrepancies need to be resolved at our Face2Face meeting
Section A.4.1, Page 47: The example included for the query Action is using an openc2 target, which no longer exists. This needs to be changed to features to be a compliant example. Section A.4.3, Page 48: The example response for the query/features/profiles command implies that a returned profile can have more than 16 characters ( iot-front-door-lock ), though the Language Spec
PRD-02 says in Section 4.4.2.10, Page 45, that the NSID for a Profile must not be longer than 16 characters. So, we need to fix one or both of these to be consistent. Section A.4.4, Page 49: The example response for the query/features/pairs command is using the wrong JSON response format. The Language Spec PRD-02, Section 3.4.2.1, Page 43, defines the pairs field
as being a Map where the key is the Action (as a String) and the supported targets for that Action is an array of Targets (as a string). Annex C, Page 51: Feel free to add me to the Acknowledgements section if you apply any of these comments to the final version (Thanks!).