Re: Potential Subcommittee reorganization

All,

I would like the TC to consider the notion of reorganizing the subcommittees such that we have:

OpenC2 Language and Architecture Subcommittee

OpenC2 Actuator Profile Subcommittee

The following is my opinion only:

OBSERVATIONS

· The creation of the initial specifications (Language, HTTPS Transfer and the SLPF) were intense processes. We were required to do multiple iterations of drafting, commenting and resolution of these specifications from end to end.

· The current scope of the Language Specification is to define semantics of the actions, the syntax of an OpenC2 command (and response), how a command is defined, how the language may be extended etc.

· The current scope of the transfer specification(s) is to define what is needed to build interoperable implementations such as transport, security, messaging etc.

· The implementation considerations subcommittee will be leveraging existing standards to the greatest extent practical thus much of what is to be addressed is the engineering of existing components rather than the definition/ creation of new.

· The current scope of the Actuator Profile(s) is to put the language in the context of a particular cyber-function, that is to identify the subset of the language specification that is meaningful (in the context of the actuator) and if appropriate, further specify the commands (and responses) via extensions.

ASSUMPTIONS

· The maintenance of the language specification will not require the level of effort that the version 1.0 production

· The Implementation Considerations efforts (and language specification) are a broader ‘systems’ scope

· The Actuator Profiles are distinct (from the Language and transfer specs) in that they are delving into particular functions to a greater level of detail and refine the abstract language in accordance with the context of the actuator(s)

Again, this is only my opinion, but it seems that the language specification and ICSC are more ‘architectural’ in nature while the Profiles are more ‘component’ in nature, therefore it is logical to load balance the Language and ICSC efforts into a single subcommittee and leave the AP-SC as a separate SC.

I believe that some of the observations and assumptions were validated at the last plug fest. Several issues were identified on Jan 27, 28 (https://github.com/oasis-tcs/openc2-usecases/blob/master/Cybercom-Plugfest/Plugfest-Outcomes.md#issues-identified ). It is interesting to note that the majority of the issues identified were actuator profile specific. It is also interesting to note that our approach (decoupling of the specifications and maintaining separation of concerns) was well received.

I am open to further deliberations, but at this point, I support the notion of defining a “OpenC2 Language and Architecture Subcommittee” and transferring the tasks of the LSC and ICSC to the new subcommittee.

Joe B

Subject: Potential Subcommittee Reorganization

From: Dave Lemire <dave.lemire@g2-inc.com>
To: OASIS OpenC2 List <openc2@lists.oasis-open.org>
Date: Mon, 3 Feb 2020 10:26:46 -0500

This email responds to an action item assigned to the Secretary at the 22 January 2020 TC meeting.

The OpenC2 TC stood up June 2017, and established three subcommittees (SCs):

OpenC2 Actuator Profile (AP) Subcommittee - Defining actuator profiles, the OpenC2 message elements applicable to specific cyber defense functions.
OpenC2 Implementation Considerations (IC) Subcommittee - Providing guidance for implementation aspects such as message transport and information assurance.
OpenC2 Language Subcommittee - Developing, maintaining, and resolving comments to the OpenC2 language documentation.

SC portion of the TC home page:
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=openc2#subcommitteesÂÂ

Links to the individual SC descriptions are there.

At the January 2020 TC meeting, TC co-chair Joe Brule proposed the consolidation of the Language and IC SCs, based on the projection that followingÂthe summer 2019 publication of the three initial OpenC2 specifications, the workload of those two committees would be reduced, while the workload of the AP SC would likely grow. He further proposed that the March co-chairs election be aligned with this proposed structure.

In the discussion, the following points were raised:

A decision on this should be delayed until after the Plug Fest / Hackathon, so that lessons learned and work items identified from that event are known and can be considered in the discussion and decision.
The decision should precede the elections. A decision to restructure can be made at the February TC meeting, as the TC routinely achieves quorum, so that TC members know ahead of time what positions are being filled in March.
Given the OASIS management approach of preserving all artifacts of a TC's operations, the mechanics of this change are likely to be suspending the operation of one of the existing SCs, and folding its mandates into the remaining SC (or suspending both and establishing a new, consolidated SC).

TC members are invited to contribute to this discussion on-line in preparation for the 19 February TC meeting.ÂThis messageÂwill be copied to the Slack general channel. Contributions to the discussion are welcome on either email or Slack.

Dave

Joe Brule

Engineering (Y2D122)

FNX-3, B4A335

410.854.4045

'Adnius ad retinedam puritem noster peciosus corporalis fluidorum…'

I welcome VSRE emails. Learn more at http://vsre.info/

openc2 message