OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

openc2 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: FW: RE: Use of the word "profile"


 

Toby.Considine@unc.edu writes:

Ø  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.

 

We do need to get that (unwritten) Architecture / “Philosophy” document written, as it will capture many of the ideas that you have articulated so well here.

 

The motivation for creating JADN back in the Forum days was to have a Platform Independent way of defining the *information* needed by OpenC2 producers and consumers without getting tied to specific *data* structures.  The IETF uses the terms “Information Model” and “Data Model” (https://tools.ietf.org/html/rfc3444, https://datatracker.ietf.org/meeting/86/materials/slides-86-i2rs-3) to refer to PIMs and PSMs.   We wanted to leverage CybOX (https://cyboxproject.github.io/) objects that were defined in XML as targets in the new OpenC2 language that was being developed using JSON, while not tying OpenC2 inextricably to that JSON PSM the way STIX 1 is tied exclusively to XML and STIX 2 is tied exclusively to JSON.

We discussed bridging in passing at the October F2F.  But your description of allowing one PSM to interoperate with *different* PSMs by transforming into the common PIM and then back out using a different transformation makes the bridging idea concrete.  That is the core concept that needs to be documented in our “Philosophy”.   The serialization specifications (and yes, there is more than one JSON “flavor”, more than one way to transform the PIM into a JSON PSM), and the transfer specifications together define the transformations between PIM and PSMs.   And those transformations are defined independently of the content of the PIM – the content could be core OpenC2, it could be packet-filter-specific OpenC2, or it could be something else entirely – as long as the content is defined in a Platform Independent manner.  Platform Independent information modeling is JADN’s raison d’être.

 

Dave



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]