search

oasis-tcs / openc2-oc2ls

OASIS OpenC2 TC: GitHub repository used to propose and track changes to the OpenC2 Language Specification as new working draft level revisions are created and the associated CSDs mature
https://github.com/oasis-tcs/openc2-oc2ls
Other
15 stars 19 forks source link

Include grammar in language specification #132

Closed sparrell closed 5 years ago

sparrell commented 5 years ago

LS-006 (https://lists.oasis-open.org/archives/openc2-comment/201811/msg00003.html):

The Language and the (unwritten) Architecture should be treated together as an abstract Platform Independent Model (PIM) and all things downstream as specific Profiles for specific technology and interaction choices (Platform Specific Models)(PSMs).

As generally used, a PSM is a specific set of extensions to or constraints on a PIM, and therefore conformant to the PIM. Each PSM then is interoperable with any other PSM by a sort of transitory rule, as each can be transformed into the PIM, and form the PIM into the other PSM. A PIM is never meant to be a specification in and of itself, although I have developed in the past a specific PSM that was as close to the PIM as possible, for use in integrating into other specifications.

As OpenC2 moves beyond a set of Products with mere faceplate conformance to an interoperable suite of communication specification, each with quite different assumptions and serialization requirements and communication challenges, the PIM-PSM model is how one enables long-term wide interoperability.

Although it predates the PIM-PSM language, consider the standard 802.11 as a PIM. It is unlikely that if you and I sat down with the Standard and began coding and selecting radios that our two systems would be able to interoperate. The industry has instead created a number of profiles that are interoperable (802.11 A, B, G, C, AC) and any device that opts to implement more than one of these profiles can easily route between the two because of their mutual conformance with the 802.11 PIM.

The rule that a Command must implement only one action (or one target) MAY be part of a Restriction Profile created as a PSM of the PIM, or other Profiles that permit them must explain how to translate to the PIM, but either model would fit. In either case, that translation to the Abstract PIM defines how interoperable routing or aggregation is achieved.

Under this approach, we HAPPEN to describe the abstract information model in JSON, and we require profiles for JSON-based serialization profiles to conform, to that in the PIM, but we do not restrict other serialization schemes. Any other serialization MUST define how it treats each PIM data element, i.e., define its conformance to the PIM.

In a similar vein, we use HTTPS to describe the interaction patterns of OpenC2, and MAY declare that HTTPS bindings must conform. Other Bindings MUST define how they conform to the interaction patterns of the PIM.

A Profile then defines the Serialization and/or Bindings to create a specific PSM

I think this is the path to achieving long-term interoperability and evolvability within this Specification and its derivative Specifcations

jmbrule commented 5 years ago

If I understand the reviewers comment correctly, then I am in agreement. Let me ask Mr. Considine a question: Are you stating that the language specification should converge on a common abstract data notation and a set of constraints (i.e. syntactical rules), then leave the technology specific matters to the profiles and the transfer specs? If that is an accurate capture, in agreement but would ask for suggested edits/ additions to address your concern

romanojd commented 5 years ago

At F2F, 01/2019, we agreed that this could be considered in the future.

romanojd commented 5 years ago

Agreed to close: LSC Meeting, 1/29/2019.