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

 


Help: OASIS Mailing Lists Help | MarkMail Help

openc2-lang message

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


Subject: Planning to next steps in Language Specification Suncommittee


Two pressing issues for Language Spec this week:

1)      Co-Chair to for the rest of Jason’s Term (until next April)

2)      A fog of things we are calling “Architecture”

And one strong area of old business

3)      JSON Schemas for OpenC2

Summary of some of the issues on “Architecture”

  • Each of the three current specifications has identical introductory material. We would prefer not to be able to say the same when we have 10 specifications. A single normative narrative of approach and model and how the TC thinks about OpenC2 interactions would be better.
  • Many of us suspect that this introductory material is mostly correct but not complete. It is an open issue how much is needed to complete it.
  • If the TC expands to Messages other than a Command, it would be useful to be able to have a coherent way to talk about the messages.
  • We may be trying to create a Reference Model rather than a Reference Architecture.

Methods of Work:

  • If the Architecture section grows to 30 additional pages, then we should request and create a new document for  the Specification “OpenC2 Architecture”
  • If the Architecture section needs only an additional paragraph, then it may be that revising and extending the current Language Spec may be better. This would require reviewing the format of the 1.1 LS with an eye to being able to call out a specific section in references from other specifications.

The decision of how to go starts with the text. We plan to begin creating the Architectural Description, and see where it leads us. One of the two methods above will likely become the obvious answer.

 So, for now, we are looking for text for Architecture. Straw men appreciated.

What does Architecture look like in an OASIS Specification?  Links to the two approaches are below:

  1. The abstract SOA reference model has been accepted by many other standards groups and has been used as a seed model for many other specifications (including, to some extent, OpenC2). I am including it because it is a stand-alone specification.
    https://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf
    This is a Reference Model rather than a Reference Architecture. It is possible that this is what we actually want. The same TC produced a Reference Architecture 6 years later.
    https://docs.oasis-open.org/soa-rm/soa-ra/v1.0/cs01/soa-ra-v1.0-cs01.pdf

    I am including this because it is a non-OASIS source talking about SOA-RM
    https://en.wikipedia.org/wiki/OASIS_SOA_Reference_Model

  2. The Energy Interoperation Specification included an architecture for power grid interactions that is oft-cited as an internal component of a specification.
    https://docs.oasis-open.org/energyinterop/ei/v1.0/os/energyinterop-v1.0-os.pdf
    This specification includes an “Architectural Background” (section 1.8) because the approach of SOA is so different than used by the then-existing power system and distribution management control systems (likely not needed for the IT-heavy Cybersecurity world) as well as a full section on Interactions (section 2) and a full section on Architecture (Section 3)

OpenC2 needs an editor willing to lay out what we he thinks we need for this specification, so we can start.

Thanks

tc






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