All,
I attempted to resolve all of the comments to the reviewers satisfaction and provide an end to end administrative review, but to be quite blunt, am too close to it to catch all of the defects. Request an end to end review and please do violence with your
red pens.
Here are some issues that I know about.
- Need full citations for the Language Spec and the HTTP/TLS spec
- Need to draft Annex C (sample JSON serialized commands). Intentionally waited on this one until the body of the text is near final
Here are some issues that need your comments/consent
- There are only FIVE status codes defined in this spec (102 processing, 200 OK, 400 parsing error, 500 server error and 501 not implemented). The status text may have human readable additional precision for logging/ debugging but for Machine to Machine
interactions there are five codes. Question: Is this sufficient for this version of the spec or do you think we need more status codes (or define results property tables)
- In the context of response codes for error conditions, a ballot issue was raised along the lines that the following strategy be adopted:
- MUST NOT respond with 200 OK
- SHOULD respond with (400 or 501 for some error conditions)
- MAY respond with 500
- The motivation for this strategy is along the lines of: Distinguishing between a parsing error from a not implemented error is beneficial, but for very simple actuators, it makes sense to permit a generic 'server error' status code regardless of what caused
the error. In the case of very simple actuators, leave the debugging and refined error analysis to something other than openc2. Question: Look over sections 2.3.1 through 2.3.5 and determine if the error handling is satisfactory.
- Conformance section: Based on some comments received via slack and via google docs, the following approach was taken:
- Create a traceability matrix that binds the SLPF and language spec to the conformance targets.
- Create a 'basic' producer and 'basic' consumer conformance target that captures the bare minimum that must be complied with
- Create a 'complete' producer and 'complete' consumer conformance targets that captures the entire spec.
- Section 2.1.4 has four actuator specifiers defined, however this section is not reflected in the conformance section because they are optional. Should they be captured in the 'complete' conformance targets?
When you get a chance, please review. In a perfect world would like to achieve general consent from the subcommittee on Sept 12.
Thank you
VR
Joe Brule