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: Re: [openc2-lang] Phased Completion of the Language Spec


I agree with Tobyâs points 1-4 on how to move forward. I reserve the right to disagree in the future on the PIM/PSM model â it is âaâ way to model, it is not the only way. I think once we get to his point #4 (i.e. enough data to work with), we will be in a better position to decide what model to use. Iâm not against using PIM/PSM â I just think itâs too soon to make that determination. Letâs get the 3 specs we have out, and then get cracking on more actuators and transport specs, and then look at what we have once we have enough data to work with.

 

Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

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

 

 

From: openc2-lang <openc2-lang@lists.oasis-open.org> on behalf of Toby Considine <Toby.Considine@unc.edu>
Date: Tuesday, March 19, 2019 at 10:05 AM
To: openc2-lang <openc2-lang@lists.oasis-open.org>
Subject: [openc2-lang] Phased Completion of the Language Spec

 

I said this on the call last week, but that is a small list.

 

It has been a continuing thorn, the attempt to future proof the language spec. Assuming the model that the language is the PIM, or abstract reference to the language, and all the dependent specs are PSMs, or specific implementations of that model, the Sub-Committee wants to get the abstract model complete and correct. On the other hand, we only know what we know, and we have one fully fleshed out specification to wotk with.

 

This has delayed work.

 

The model I proposed on the call was

 

  1. We donât worry about it. The Stateless Packet Filter is released with a normative reference to Language 1.0
  2. Some new device/interaction comes along, and we need to expand the Language Spec to 1.1. The new device spec is released with a normative reference to Language 1.1. We donât worry about updating the Stateless Packet Filter.
  3. Another new device/interaction comes along, and we need to expand the Language Spec to 1.2. The new device spec is released with a normative reference to Language 1.2. We donât worry about updating the Stateless Packet Filter or the 1.1 device(s).
  4. At some point, we decide that we have enough general language of the PIM the language spec is adequate. We can then cycle back and update each of the [device] specs to use this finally complete spec. If it breaks compatibility, the language spec and all of the device specs can be 2.0. If it does not break compatibility, all of the specs can be, for example, 1.5

 

This places the compatibility issues and the future functionality issues in the language as on hold and out of scope for the 1.0 release, so we can quickly close up the patient.

 

tc



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