You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CSDPR01 comment email https://lists.oasis-open.org/archives/openc2-comment/201812/msg00000.html contains many issues. All will be included here for expediency and also to serve as status point ie don't close this issue until all the issues listed here (and in other children issues) are closed.
`Comments on OpenC2 Language Specification 1.0, Public Review Draft 01
(Locations are identified by Page#-Line#, or by Page#-StartLine:EndLine for a range)
8-30 “All…names and terms are between three and 40 characters long”. This is stated as a Document convention, but reads as a language restriction. Is it intended as a language restriction?
9-5 The term “Actuators” reads as if it is normatively defined, but it is not. Not clear of re-working of sentence, or defining of actuator is required. This concern continues throughout this section. In Section 2.1, it appears that Actuator is defined normatively.
9-13 Suggest word ”MAY” as in profiles MAY extend the language by adding specifiers…
9-22:28 Consider moving section to above paragraph that starts with 9-9 and using the definitions in the intervening paragraphs
9-34: Is there a normative meaning to the phrase “captured or necessary” Can other information be transmitted? Logs / Sums / Statistics / Ongoing analysis…
10-26: Are any authentication protocols intended in rectangle on left?
11-35: Consider a section between current 1.7 and 1.8 on Rules for Extension. Alternately, this could be another bullet in the paragraph that ends before. Such rules can affect interoperability, especially when a Producer and intended Consumer may be separated by some sort of message routing or broadcast domain.
11-38:44 If the specification defines the “set of actions that may be used” then it would appear that extensions are forbidden—yet rules for extension are in scope. Re-work.
11-43: Scope is a JSON serialization. (1) Are other serializations permitted? Does this scope include protocol bindings? Suggest language that JSON is used in this document to define the encodings and message handling in this document. This implies that (1) JSON-based implementations MUST use the encoding and message handling indicated in this specification (and in the JADN), and that other encodings and serializations (is there a difference?) must specify (the mapping between the encoding they use and this specification and (2) how they handle the message routing functions in this specification. (Note: I think that what I call the message handling functions cleanly delimited by the specification that they appear in the HTTP header.
11-51: Alternate serialization etc. Suggest call-out both commands and to routing functions, i.e. those elements specified in the HTTP header. Must alternate serializations reference the “Specification for Transfer…via HTTPS” to find the full requirements that they must match?
12-18. Should the final “target” be “TARGET”
12-24 It is unclear what the difference between Target and Actuator is. This MAY be answered in 12-41:51, but the usages seem in conflict (can in conflict with similar language in section 1.6 Overview.
13-7: Unclear what “meaning of response means”. Should machine actions / decisions be based solely on the STATUS? Is this for Display only?
14-51. Duration s defined in milliseconds. Consider Duration as defined in ISO 8601 and its derivatives (RFC 3309). Aside from durations in milliseconds, one may wish a duration in, say, weeks, or months (et al.), as well as the possibility of repeating intervals. For example, For example, "P3Y6M4DT12H30M5S" represents a duration of "three years, six months, four days, twelve hours, thirty minutes, and five seconds”. Duration is implemented in the common Java library Duration.
This is part of a larger conversation about time and schedule. Assume a particular set of Stateless Packet Filtering commands. Can they be specified to apply to all After-hours periods for the next month? How is After Hours defined? (The security team goes home at 9:00 each evening. The weekend is considered After Hours).
In general Internet use of Schedule is specified in RFC 5545: the recurrence section seems particularly APT here. The derivative specification WS-Calendar PIM simplifies the information model for M2M communications. The complementary model for “Availability” (and its reciprocal “Unavailability”) (RFC 7953 and WS-Calendar) seem apt here. The former specification is widely used in internet processing, and the latter derivative in Power Grid negotiations (OASIS Energy Interoperation, OpenADR, now IEC 62746-10-1) and in building scheduling (ASHRAE 201). Both Power Grid and Building systems are areas or Cybersecurity concern where informational compatibility would be beneficial.
16-21:38. Are these rules for JSON Serialization, or conformance points for non-JSON serialization or…We seem to be bleeding between levels here. Suggest a section on JSON serialization and moving this section to there. Suggest moving sections 3.1.5.1 and section 3.1.5.2
16-42: Suggest moving to Section 2 (or possibly to 1.7 as a goal). Prefer 2 because I think this is normative.
17-9:10 Message Types:Consider if there are “report” interactions (and message types).
Reporting has various aspects, from alarms and notifications (tell me if this happens) to logging (write this down and I will ask for some or all of it later) to reporting (track the following bits of information over time and send it to me at defined intervals). For a description of one approach to this, see http://docs.oasis-open.org/energyinterop/ei/v1.0/os/energyinterop-v1.0-os.html#_Toc388604017
17-43: Consider “The OpenC2 command specifies an action to be performed by a Target”
17-41:55 Should this section be moved to 2.1? It is defining the basic grammar of the language, not any specific requirements or commands.
18-45:46 It would seem that the intent here is to “reserve” words for the future to prevent future barriers to interoperability. Recommend that Implementers should be cautioned to avoid these terms or risk that future specifications may invalidate (cause to not interoperate) their work.
18-41: Investigate. Previous comment on “Reporting” and “Report Specifiers repeated here.
Reporting has various aspects, from alarms and notifications (tell me if this happens) to logging (write this down and I will ask for some or all of it later) to reporting (track the following bits of information over time and send it to me at defined intervals). For a description of one approach to this, see http://docs.oasis-open.org/energyinterop/ei/v1.0/os/energyinterop-v1.0-os.html#_Toc388604017
18-43: What is the intent of “remediate” It sounds like it is inviting violation of the directive on status text in 13-6:7. Or is this the purpose” of a command for forensics reasons?
19 7:9 Is there a provision for extending the conformant actions list?
19-46: The target slpf is indicated. This is an extension. Is there an extension registry planned? If so is there a prefix for registered/unregistered targets? Is it possible to taget “all SLPF” in a CIDR range?
19-48:20-6. It is unclear what the purpose of this statement is. Should makers of these targets but an “x-“ prefix on each to indicate is an extension but not of the core standard? It seems the intent is not to invalidate any security commands directed towards [disk_partition], but to warn that in future versions they may be a standard profile, and any work before that future MAY not conform to the eventual standard. Does the version number (in the header) handle this, in which case we have created an expectation that one not [disk_partition] without also comparing it to the version… Clarity is required.
20-38: And that is?...
20-45:21:15 May be bridging space between information model and serialization requirements. If specific serialization requirements are expected, they should be described with others in the JSO encoding section.
21:39 Is any particular action expected on a “Moved Permanently” (301). If authorizing to send to a new URI (and not send to this one anymore) does this require any particular level of authorization or trust?
22: Imported data. This is the first discussion of extensions. Should this be called out in the table in 3.3.1.2? Are there specific requirements for the “namespaces” in 10:12. Who is importing? Is this rules for code? Should a generic OpenC2 “watcher” be able to import spaces to log what is going on? Or is this limited namespace collision management?
Is understanding JADN to understand imports a requirement for conforming Producers and Consumers?
22-23: Is nsid a normative term? Where is it defined?
22-44:45 This states requirements for conforming extensions. These should be gathered together either within the document, or with a specific conformance extension for specifications that claim to conform to this specification.
23-4:6 This states requirements for conforming extensions. These should be gathered together either within the document, or with a specific conformance extension for specifications that claim to conform to this specification.
23-44. “MUST reject command” is a specific conformance point that should be called out in the Conformance section
23-44:45: What if the target is a bridge, or is a CIDR range? What are the requirements then? There is introduced complexity (to the extent using HTTP headers for “routing”) that should be balanced with the requirements for a router to do something.
See also previous comment on “MUST UNDERSTAND”
25-35:47 Does this table support multiples and for which variables? Lists or CIDR for addr? List or range for ports?
26-40 Consider ISO8601 or its IETF derivative RFC 3339.
26-45 Consider ISO8601 Duration and related Java class DURATION. Must support granularity down to milliseconds.
28-11 Can a system respond with a status episodically, perhaps on a fixed interval (duration)?
28-37 What is the relationship between this Target and the Targets in the Command table?
29-31:40 Is this a sufficiency of Bounds? Recurrence limitations, max durations, minimum throttle windows, perhaps even more complex (max messages in a duration). Can discuss formal operating constraints in meeting if interest.
31-6 Identifier. This is a more general question. Should there be a generic OpenC2 Identifier type sub-typed to Message ID, Command ID, Message/Routing ID, Report Id, etc.? This MAY make bridging and aggregation simpler.
Section 3.4 Overall: Throughout Section 3.4, terms are defined as used, leading to some duplicate definitions, definition overrides, etc. Suggest overrides, etc. Suggest single dictionary (or a few ones by type), followed by description of messages that use the now pre-defined fields.
Section 4: reads like an abortive grammar for language. Such a section could be better placed, with other grammar items, in early section 2. Either that, or expand here.
Section 5 (Conformance): The TC rejected a section on specifications that claim conformance here, but then added such clauses in several other locations (pages 22, 23) that do just that. Suggest bringing together in coherent sub-section on conforming derivative specifications here.`
The text was updated successfully, but these errors were encountered:
CSDPR01 comment email https://lists.oasis-open.org/archives/openc2-comment/201812/msg00000.html contains many issues. All will be included here for expediency and also to serve as status point ie don't close this issue until all the issues listed here (and in other children issues) are closed.
`Comments on OpenC2 Language Specification 1.0, Public Review Draft 01
(Locations are identified by Page#-Line#, or by Page#-StartLine:EndLine for a range)
8-30 “All…names and terms are between three and 40 characters long”. This is stated as a Document convention, but reads as a language restriction. Is it intended as a language restriction?
9-5 The term “Actuators” reads as if it is normatively defined, but it is not. Not clear of re-working of sentence, or defining of actuator is required. This concern continues throughout this section. In Section 2.1, it appears that Actuator is defined normatively.
9-13 Suggest word ”MAY” as in profiles MAY extend the language by adding specifiers…
9-22:28 Consider moving section to above paragraph that starts with 9-9 and using the definitions in the intervening paragraphs
9-34: Is there a normative meaning to the phrase “captured or necessary” Can other information be transmitted? Logs / Sums / Statistics / Ongoing analysis…
10-26: Are any authentication protocols intended in rectangle on left?
11-35: Consider a section between current 1.7 and 1.8 on Rules for Extension. Alternately, this could be another bullet in the paragraph that ends before. Such rules can affect interoperability, especially when a Producer and intended Consumer may be separated by some sort of message routing or broadcast domain.
11-38:44 If the specification defines the “set of actions that may be used” then it would appear that extensions are forbidden—yet rules for extension are in scope. Re-work.
11-43: Scope is a JSON serialization. (1) Are other serializations permitted? Does this scope include protocol bindings? Suggest language that JSON is used in this document to define the encodings and message handling in this document. This implies that (1) JSON-based implementations MUST use the encoding and message handling indicated in this specification (and in the JADN), and that other encodings and serializations (is there a difference?) must specify (the mapping between the encoding they use and this specification and (2) how they handle the message routing functions in this specification. (Note: I think that what I call the message handling functions cleanly delimited by the specification that they appear in the HTTP header.
11-51: Alternate serialization etc. Suggest call-out both commands and to routing functions, i.e. those elements specified in the HTTP header. Must alternate serializations reference the “Specification for Transfer…via HTTPS” to find the full requirements that they must match?
12-18. Should the final “target” be “TARGET”
12-24 It is unclear what the difference between Target and Actuator is. This MAY be answered in 12-41:51, but the usages seem in conflict (can in conflict with similar language in section 1.6 Overview.
13-7: Unclear what “meaning of response means”. Should machine actions / decisions be based solely on the STATUS? Is this for Display only?
14-51. Duration s defined in milliseconds. Consider Duration as defined in ISO 8601 and its derivatives (RFC 3309). Aside from durations in milliseconds, one may wish a duration in, say, weeks, or months (et al.), as well as the possibility of repeating intervals. For example, For example, "P3Y6M4DT12H30M5S" represents a duration of "three years, six months, four days, twelve hours, thirty minutes, and five seconds”. Duration is implemented in the common Java library Duration.
This is part of a larger conversation about time and schedule. Assume a particular set of Stateless Packet Filtering commands. Can they be specified to apply to all After-hours periods for the next month? How is After Hours defined? (The security team goes home at 9:00 each evening. The weekend is considered After Hours).
In general Internet use of Schedule is specified in RFC 5545: the recurrence section seems particularly APT here. The derivative specification WS-Calendar PIM simplifies the information model for M2M communications. The complementary model for “Availability” (and its reciprocal “Unavailability”) (RFC 7953 and WS-Calendar) seem apt here. The former specification is widely used in internet processing, and the latter derivative in Power Grid negotiations (OASIS Energy Interoperation, OpenADR, now IEC 62746-10-1) and in building scheduling (ASHRAE 201). Both Power Grid and Building systems are areas or Cybersecurity concern where informational compatibility would be beneficial.
16-21:38. Are these rules for JSON Serialization, or conformance points for non-JSON serialization or…We seem to be bleeding between levels here. Suggest a section on JSON serialization and moving this section to there. Suggest moving sections 3.1.5.1 and section 3.1.5.2
16-42: Suggest moving to Section 2 (or possibly to 1.7 as a goal). Prefer 2 because I think this is normative.
17-9:10 Message Types:Consider if there are “report” interactions (and message types).
Reporting has various aspects, from alarms and notifications (tell me if this happens) to logging (write this down and I will ask for some or all of it later) to reporting (track the following bits of information over time and send it to me at defined intervals). For a description of one approach to this, see http://docs.oasis-open.org/energyinterop/ei/v1.0/os/energyinterop-v1.0-os.html#_Toc388604017
And some associated open source libraries
http://xpower.xlab.si/unofficial-javadoc-openadr/org/openadr/profile_b/ReportSpecifierType.html
http://xpower.xlab.si/unofficial-javadoc-openadr/org/openadr/profile_b/SpecifierPayloadType.html
For another approach to specifying and querying reporting from a remote system, see
http://docs.oasis-open.org/obix/obix/v1.1/csprd01/obix-v1.1-csprd01.html#_Toc361929131
17-43: Consider “The OpenC2 command specifies an action to be performed by a Target”
17-41:55 Should this section be moved to 2.1? It is defining the basic grammar of the language, not any specific requirements or commands.
18-45:46 It would seem that the intent here is to “reserve” words for the future to prevent future barriers to interoperability. Recommend that Implementers should be cautioned to avoid these terms or risk that future specifications may invalidate (cause to not interoperate) their work.
18-41: Investigate. Previous comment on “Reporting” and “Report Specifiers repeated here.
Reporting has various aspects, from alarms and notifications (tell me if this happens) to logging (write this down and I will ask for some or all of it later) to reporting (track the following bits of information over time and send it to me at defined intervals). For a description of one approach to this, see http://docs.oasis-open.org/energyinterop/ei/v1.0/os/energyinterop-v1.0-os.html#_Toc388604017
And some associated open source libraries
http://xpower.xlab.si/unofficial-javadoc-openadr/org/openadr/profile_b/ReportSpecifierType.html
http://xpower.xlab.si/unofficial-javadoc-openadr/org/openadr/profile_b/SpecifierPayloadType.html
For another approach to specifying and querying reporting from a remote system, see
http://docs.oasis-open.org/obix/obix/v1.1/csprd01/obix-v1.1-csprd01.html#_Toc361929131
18-43: What is the intent of “remediate” It sounds like it is inviting violation of the directive on status text in 13-6:7. Or is this the purpose” of a command for forensics reasons?
19 7:9 Is there a provision for extending the conformant actions list?
19-46: The target slpf is indicated. This is an extension. Is there an extension registry planned? If so is there a prefix for registered/unregistered targets? Is it possible to taget “all SLPF” in a CIDR range?
19-48:20-6. It is unclear what the purpose of this statement is. Should makers of these targets but an “x-“ prefix on each to indicate is an extension but not of the core standard? It seems the intent is not to invalidate any security commands directed towards [disk_partition], but to warn that in future versions they may be a standard profile, and any work before that future MAY not conform to the eventual standard. Does the version number (in the header) handle this, in which case we have created an expectation that one not [disk_partition] without also comparing it to the version… Clarity is required.
20-38: And that is?...
20-45:21:15 May be bridging space between information model and serialization requirements. If specific serialization requirements are expected, they should be described with others in the JSO encoding section.
21:39 Is any particular action expected on a “Moved Permanently” (301). If authorizing to send to a new URI (and not send to this one anymore) does this require any particular level of authorization or trust?
22: Imported data. This is the first discussion of extensions. Should this be called out in the table in 3.3.1.2? Are there specific requirements for the “namespaces” in 10:12. Who is importing? Is this rules for code? Should a generic OpenC2 “watcher” be able to import spaces to log what is going on? Or is this limited namespace collision management?
Is understanding JADN to understand imports a requirement for conforming Producers and Consumers?
22-23: Is nsid a normative term? Where is it defined?
22-44:45 This states requirements for conforming extensions. These should be gathered together either within the document, or with a specific conformance extension for specifications that claim to conform to this specification.
23-4:6 This states requirements for conforming extensions. These should be gathered together either within the document, or with a specific conformance extension for specifications that claim to conform to this specification.
23-44. “implementations must”. Suggest “Consumers must”
23-44. “MUST reject command” is a specific conformance point that should be called out in the Conformance section
23-44:45: What if the target is a bridge, or is a CIDR range? What are the requirements then? There is introduced complexity (to the extent using HTTP headers for “routing”) that should be balanced with the requirements for a router to do something.
See also previous comment on “MUST UNDERSTAND”
25-35:47 Does this table support multiples and for which variables? Lists or CIDR for addr? List or range for ports?
26-40 Consider ISO8601 or its IETF derivative RFC 3339.
26-45 Consider ISO8601 Duration and related Java class DURATION. Must support granularity down to milliseconds.
28-11 Can a system respond with a status episodically, perhaps on a fixed interval (duration)?
28-37 What is the relationship between this Target and the Targets in the Command table?
29-31:40 Is this a sufficiency of Bounds? Recurrence limitations, max durations, minimum throttle windows, perhaps even more complex (max messages in a duration). Can discuss formal operating constraints in meeting if interest.
31-6 Identifier. This is a more general question. Should there be a generic OpenC2 Identifier type sub-typed to Message ID, Command ID, Message/Routing ID, Report Id, etc.? This MAY make bridging and aggregation simpler.
Section 3.4 Overall: Throughout Section 3.4, terms are defined as used, leading to some duplicate definitions, definition overrides, etc. Suggest overrides, etc. Suggest single dictionary (or a few ones by type), followed by description of messages that use the now pre-defined fields.
Section 4: reads like an abortive grammar for language. Such a section could be better placed, with other grammar items, in early section 2. Either that, or expand here.
Section 5 (Conformance): The TC rejected a section on specifications that claim conformance here, but then added such clauses in several other locations (pages 22, 23) that do just that. Suggest bringing together in coherent sub-section on conforming derivative specifications here.`
The text was updated successfully, but these errors were encountered: