RE: STIX 2.0 Path Forward

["Back, Greg" <gback@mitre.org>]

In the spirit of an "MVP" release as soon as possible, I support option 2, assuming we are confident that what is in 2.0 RC3 will not need to be changed in backwards-incompatible ways.

> -----Original Message-----
> From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of
> Wunder, John A.
> Sent: Friday, October 21, 2016 8:43 AM
> To: cti@lists.oasis-open.org
> Subject: [cti] STIX 2.0 Path Forward
> 
> All,
> 
> 
> 
> One of the topics we discusson the TC calls yesterday (or this morning
> depending on time zone) was whether or not we want to take STIX 2.0 RC3
> through the process to becoming a full Committee Specification (CS). See my
> attached slides for a roadmap and brief comparison of Committee
> Specification vs. Committee Specification Draft, but to summarize here…
> 
> 
> 
> Committee Specification Draft
> 
> -          First level approval stage for standards track work products
> 
> -          Requires a full majority vote of the TC to approve (i.e. you need
> quorum and over 50% of the votes must be YES)
> 
> -          TC can release as many CSDs for a given work product as we want. It
> can be very fluid, and previous decisions aren’t really locked in.
> 
> -          Does not require any public review or public approval
> 
> -          Is published by OASIS
> 
> -          Is not an OASIS final deliverable with regards to OASIS IPR policy and
> does not require IPR disclosures
> 
> 
> 
> Committee Specification
> 
> -          Second level approval stage for standards track work products
> 
> -          Cannot be modified once it’s published
> 
> -          Will go through a public review phase
> 
> -          Is published by OASIS as a “final deliverable”, which confers OASIS IPR
> policy protections as a “covered product”
> 
> 
> 
> The process to turn a CSD into a CS is:
> 
> -          Full majority vote of the TC to open the public comment period on the
> CSD
> 
> -          The TC identifies external stakeholders for review, who are notified. TC
> members must also disclose any IPR related to STIX 2.0.
> 
> -          Public comment period is open for 30 days. All comments must be
> tracked and adjudicated.
> 
> -          If there are substantive changes to the specification as a result of the
> public comment period, it requires another full majority vote to open a 15
> day comment period…rinse and repeat
> 
> -          Once there’s a public comment period where the TC certifies there are
> no substantive changes, they hold a special majority vote to approve the CS.
> Special majority requires at least 2/3 of voting members voting yes and no
> more than ¼ of voting members voting no.
> 
> 
> 
> So hopefully that helps everyone understand the distinctions. Now, we
> essentially have to options as we’re finishing up STIX 2.0 RC3.
> 
> 
> 
> Option 1: Approve STIX 2.0 as a CSD (after we resolve open items), but do
> not continue the process to Committee Specification. Instead, work to add
> new capabilities to STIX while it’s still at the CSD level. Then, when we feel it’s
> “complete”, approve it as a CS. That can be a judgement call we make as a TC,
> so depending on how much we add it could be sometime between Spring
> 2017 or Summer 2017.
> 
> 
> 
> Option 2: Approve STIX 2.0 as a CSD (after we resolve open items), and then
> continue to approve STIX 2.0 as a CS. This would take us through the process
> above and, assuming things go well, we’d have an approved STIX 2.0
> Committee Specification in January 2017. Note that work can start on STIX 2.1
> concurrent with the approval of STIX 2.0…there’s no reason we need to stop
> working on things like Incident just because we have a public review period
> open for what’s already in 2.0.
> 
> 
> 
> If anybody has any other ideas on paths we can/should take, please speak
> up. As I mentioned on the TC calls we’ll be opening a ballot on this topic early
> next week. In the meantime though, hearing everyone’s thoughts on the list
> would be great. I’ll give you my own opinion in a reply to this e-mail.
> 
> 
> 
> John