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] OC2LS CS02

Great questions Duncan.

Yes, a CS is a final deliverable at OASIS just like an OS is a final deliverable. However, a CS unlike an OS can have multiple releases. Meaning, a TC can release multiple versions of the CS, CS01, CS02, CS03, etc.  That is not the case for the OS. 

The problem we all have at one point or another is thinking of OASIS work products like software. Software usually has semantic versioning and OASIS work products do not.  Now some TCs elect to have their own version of semantic versioning on what they do, but that is not enforced by OASIS.  Technically you could release OpenC2 Lang V9.0 and then release OpenC2 Lang V8.0.  Yes, it would not make sense and it would confuse the market, but there is nothing stopping you.

So a Working Draft number only increments on the current release train.  Once that product, loosely defined at OASIS, ships and the TC moves on, then it would be expected that you would start over with a new Working Draft number (aka 01) since you are on a new release train. A release train can stop at a CS or an OS.  

So for example. STIX 2.0 had a series of WDs, CSDs, CSPRDs, and finally a single CS.  At that point, the TC was âdoneâ with that release and started on a new follow on specification, aka STIX 2.1. We could have easily called it STIX 3 but some in the TC want more software-like semantic versioning. So with STIX 2.1 we started over with WD01 and did a bunch of those, along with several CSDs, CSPRDs, and finally a CS.  We do plan to take STIX 2.1 to a full OS.  

OASIS has these concepts of âstagesâ of a release, you start with WD, then CSD, then CSPRD, then CS, and then maybe an OS.  In software we have a major version, a minor version, and some times a patch version, and even sometimes a build version. At OASIS the documents are released as a version and those versions are in a various stage of development. So you do not actually release 1.0, then 1.0.1, 1.0.2, 1.1.0, 1.1.1 etc where each digit corresponds to a stage in the process.  You would have Version 1.0 WD ##, or Version 1.0 CSD ##, or Version 1.0 CS ##, etc. 

Does this help? Or does it muddy the water more? 

I am glad you like the landing page idea, I am trying to help OASIS work towards something like this for all documents. I think it would really help.

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

On Apr 7, 2020, at 10:59 AM, duncan sfractal.com <duncan@sfractal.com> wrote:

Bret, Thank you. Your diagrams are very helpful. I like the landing page.
But of course I have questions. They donât affect the process, just I want to actually understand a working example. I still donât totally get how version numbering of Spec (eg Taxii 1.0, 1.1, 2.1, 2.2) ties in. It is in the title of the Spec (either CS or OS) and increments based on break (first digit) or backwards compatible (second digit). Do I understand correctly that WDâs do not âstart overâ even if you go to new version of Spec at CS level, only if you go to new version at OS level?
Since working documents start over only at OS, can I assume from the landing page that Taxii 2.0 was made an OS sometime prior to April 2018 (since that is date of WD01 for Taxii 2.1)? Is that correct?
Hypothetical example to help me understand.
OpenC2 Language Spec is at WD15 and we have an approved CS but have not requested OS. So when we make next WD it would be WD16. Letâs say we make WD16 and WD17 as we work on enhancements that will eventually be 1.1 and theyâd have v1.1 in title. If we were to decide to ask OASIS for the V1.0 CS to be a OS, and it would be approved, then the next WD, which would have been 18 in the old sequence, would be WD01? It seems to me it would be simpler to have WD01 of v1.1 (eg WD16 above would be WD01 of V1.1), or to stay on consecutive numbers (eg WD18) but weâll do whatever is right.
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 Bret Jordan <bret.jordan@broadcom.com>
Date: Tuesday, April 7, 2020 at 11:02 AM
To: Toby Considine <Toby.Considine@unc.edu>
Cc: openc2-lang <openc2-lang@lists.oasis-open.org>
Subject: Re: [openc2-lang] OC2LS CS02
Toby, et al.,
You are correct. As a Board member I have been trying to clean up and make some of this easier to understand and remove weird language in the TC Process that makes this confusing.
Keep in mind the following:
1) the working draft numbers increase sequentially for any given specification until it reaches an OS.   
2) errata is only for an OS and errata can only have non-material changes (aka spelling, grammar, broken links, incorrect examples, etc). 
I created the following diagram of the process for releasing standards track documents at OASIS.   I also created this concept of a document landing page for OASIS. The landing page shows how all of the various released versions relate back to a working draft number. 
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."


On Apr 7, 2020, at 6:04 AM, Considine, Toby <Toby.Considine@unc.edu> wrote:
We got our feet tangled up in process and then stumbled in the meeting yesterday. Some points:
While Oasis Specifications (OS), Committee Specifications (CS), Committee Specification Public Review Drafts, Committee Specification Drafts (CSD) and Working Drafts are all numbered, the numbers do not necessarily have work in lockstep.
  1. We have never released an OS for OC2LS. Therefore ever CS, every CSD, every WD is a step on the road to OS 1.0. There is no need to focus on 1.x  or 1.0.x or any similar numbering.
  2. Every time we âfreezeâ the specification for looking, we create a WD. While I have never gone to 3-digit working drafts, they are not forbidden. I have been on TCs that published 2 and occasionally 3 WD a week. They would all be, in this case, OC2LS-01-WDnn.
  3. Whenever we lock a draft with a vote, the TC can designate, by vote the TC can designate a named CSD.
This can end up with numbering similar to OC2LS-01.0-WD01, OC2LS-01.0-WD02, OC2LS-01.0-WD03 == > OC2LS-01.0-CSD01, OC2LS-01.0-WD04.
  1. We can vote to release a CSD for public review, that is release a specific CSD as a CSPRD. Often these are numbered the same as the CSD, but that is only by chance.
The sequence above could continue, if the of CSPRD2 is released for public review as OC2LS-01.0-WD04, OC2LS-01.0-WD05, OC2LS-01.0-WD06  == > OC2LS-01.0-CSD02   == > OC2LS-01.0-CSPRD01, OC2LS-01.0-WD07. Note that these are all still documents on the way to 1.0
  1. After a public review, we can vote to advance the CSPRD to a CSD. This is still a step on the road to a CS (although not always) There can be some options of the numbering of the CS.
The OASIS process only allows Errata only for Specifications S. Therefore we have no eratta document. What we produced was
OpenC2 Language Specification v1.0 Committee Specification 02. 
I hope this explains some of the confusion about the numbering process that was in yesterdayâs meeting.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

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