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: Impressions of the F2F


The Face-2-Face was productive, and it was good to meet many voices that I knew only by phone.

Highlights included a presentation of the DODCAR (DOD Cybersecurity Analysis and Review) taxonomy of security events.
https://www.nsa.gov/Portals/70/documents/what-we-do/cybersecurity/professional-resources/ctr-nsa-css-technical-cyber-threat-framework.pdf
There were also detailed walk-throughs actual product based on OpenC2. Clearly, momentum is building.

Preparing those products based on OpenC2 led to detailed and pointed critiques of the PR02 documents. Those issues are listed on Github and I will not repeat them here. The relevant point was that if you are trying to actually program to the sped, there are a number of ambiguities in PR02. Ambiguities lead to different coding choices, and different coding choices lead to lack of interoperability failures. We had to address these issues before finishing up 1.0.

The changes manifested themselves in two ways: a change in specific JSON style, and a conversation that firmed up some architectural details.

The changes in JSON style can be seen in the examples, and in some of the detailed language. We are no aligned better with the COMMAND/RESPOSNE language, even in multiple profiles come back from the same COMMAND. Custom Profiles can, in the new drafts, coexist in the same RESPONSE with Standard Profiles. We can now provide much better guidance to those creating Custom Profiles on what they should look like. The new drafts will reflect a standard “OpenC2 way of serializing things” which should speed development and make coding easier.

The JSON issues highlighted some Architectural muddling. Because we have no clear Architectural guidance in the PR02 documents, there is repeated material—and we now believe that repeated material is wrong. The long and the short of this as that material changes were made to all three specifications. All three will require an additional public review.

The editors were directed to make the changes as per the pull requests, and to prepare additional Working Drafts as soon as they can manage. The TC Chairs plan to request a Special Online Ballot as soon as they are ready requesting that (1) these Working Drafts (WD) become Committee Specification Drafts (CSD) and that these CSDs be released for a third public review.

Expect these votes soon. If you choose to vote now, please include the reason why in the comments, to start the conversation in the next TC meeting.

We expect the architectural conversations from the F2F to be represented in OpenC2 1.1. While we made every effort to make the current specification “forward compatible” with the discussed architecture, we opted not to include it at this time. Doing so would have caused large changes in organization of the current documents at least, and possibly an additional document. It was the sense of the attendees that this would delay the release of OpenC2 1.0 substantially for little benefit.

The F2F finished with a discussion of JADN. Some of the changes in the JSON (see above), accomplished some of the immediate purpose of JADN. The remaining ambiguities are manageable so long as the non-JSON specifications are ahead. (This is part of why the Architectural material was pushed forward as well). JADN will help insure interoperation once the types of implementation increase.

There was discussion of spinning off JADN to another TC, with the intent of re-including JADN once it is done. This may enable us to bring a more focused effort on JADN, one that includes a few experts who would never participate in OpenC2. No decision has been made, but the Chairs are exploring options.

tc




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