Re: [cti] STIX 2.0 Path Forward

I do not support option 2 and will vote no, and here is why.

1) I do not feel like our model is mature enough yet to be called a CS. We have major additions that we already know we need to add in the next 1-2 releases. We have also postponed major design elements like confidence, location, and others. This says to me, that we are not yet ready to go beyond a formal Committee Specification Draft (CSD).

2) Moving to a Committee Specification (CS) from a Committee Specification Draft (CSD) will NOT give us any more adoption. The IPR aspects with a CS did not prevent vendors from adopting the MITRE publications which were NOT even as formal as our current Committee Specification Drafts. So in regards to the MITRE standards we are further along with our CSDs.

3) This initial release was meant to be a "minimally viable product" that early adopters could start working with and playing with and we need early adopters to start using it so we can identify any issues or problems.

4) Having a 30 day public review is not going to be sufficient time for us to find problems. What we need is people to start coding solutions and working through workflows. This will take longer than 30 days and if major problems are found, it is a lot easier to fix them at the CSD level than at the CS level.

5) The recent Location issues that were brought up, show that we do not yet know if this version is solid. I believe we have a lot of work to do verifying our model before it is worthy of the CS designation.

6) For vendors, every CS version is going to require you to get your OGC (office of general council) involved to declare IPR. If our plan is to release a new CS version every 6 months, that will probably be a huge issue for those building products.

7) Staying at a CSD level for the next few releases will enable us to be more agile and move more quickly. At the cadence we need, moving to a CS will just slow us down (by the order of months). The TC has proven over the past few months that it is only capable of working on one major thing at a time. For example, all work on STIX stopped back on Aug 22nd once RC2 went out, so the TC could focus on CybOX and then Patterning.

8) If we move forward with our initial release as a CS, then we will be setting a president that all versions will be a CS and as we will be producing a lot of versions initially, this may come across as churn from a marketing/PR perspective. Kind of like, we did not have our stuff fully done and baked yet.

Bret

My opinion is that we should continue to take STIX 2.0 RC3 forward to Committee Specification as currently scoped. I feel like this has several advantages:

1. We said that STIX 2.0 was going to be a minimally viable product release. To me, that means we’re able to support the critical use cases that STIX 1.x supported, as defined by actual usage of that specification. I believe that we’ve met that goal…STIX 1.x was mostly used – especially for public information sharing – to share indicators, and we support that (presuming patterning works out). Incident is the major item I wish we could have gotten in, but I believe it’s also a major topic that we need to spend several months discussing and so I’m OK to have a release without it.

2. I’m confident that what we have in the specifications will work. Yes, there’s things we’re not covering yet that eventually we do need to cover, but what we have there is solid.

3. I think if we tried to make STIX “complete” in this first release we would be making a mistake. In my opinion getting a solid foundation on which to build the rest of the specification is critical, and I think taking STIX 2.0 RC3 through the process to make it a CS will help us solidify that foundation. This is exactly why we decided to do “minimally viable product”.

4. At the Brussels F2F there was good consensus (though not unanimity) that going to a CS now was important. One of the reasons they gave, as Rich Struse mentioned on the TC calls, was that getting public review early is important. We don't want to get to Summer 2017, go to public review, and realize that people outside the TC hate what we’ve done. While we can always get informal review now, nothing will get people to comment more than an actual open comment period. This will let us identify and resolve critical issues now.

5. Getting more real-world usage of STIX is important, and having the IPR protections in place as a covered product will do a bunch to encourage that. We can then use that actual usage to inform what we do in 2.1+.

6. This is more psychological, but to be honest I think we’ll all feel better once we can point to STIX 2.0 and say “we finished that”.

7. Some organizations may not choose to implement until STIX 2.1, and that is totally fine. We shouldn’t hold off on publishing something just because we can’t cover everyone’s use cases.

Also I don’t want to delay adding the new capabilities that we feel are necessary. I don’t think going to a full Committee Specification now will do that…while it will certainly take time and attention from TC members, we can continue to have discussions about Incident, broader malware capabilities, confidence, and other critical topics while the review period is open.

John

From: <cti@lists.oasis-open.org> on behalf of John Wunder <jwunder@mitre.org>
Date: Friday, October 21, 2016 at 9:42 AM
To: "cti@lists.oasis-open.org" <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 two 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

cti message