Bret,
The same version fatigue would happen if we released a 2.1 spec that contained nothing but the extensions process that is being discussed, or if we changed 2.1 to only contain
the “Text Complete” items (including the code part), but not say… COA or Infrastructure.
Sarah Kelley
Senior Cyber Threat Analyst
Multi-State Information Sharing and Analysis Center (MS-ISAC)
31 Tech Valley Drive
East Greenbush, NY 12061
518-266-3493
24x7 Security Operations Center
SOC@cisecurity.org - 1-866-787-4722
From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org]
On Behalf Of Bret Jordan
Sent: Wednesday, March 07, 2018 10:38 AM
To: Piazza, Rich
Cc: Mark Davidson; cti@lists.oasis-open.org
Subject: [cti] Re: [EXT] Re: [cti] Agenda for Today's Working Call - 3/6/2018
This does not address the major driving issue, we need to make sure there are no breaking issues post CS. This means, everything needs to be vetted in code by multiple independent implementations.
Without this, then our appetite for breaking changes and design changes has to be much more accommodating.
Another problem with this proposal is that it does not address the version fatigue aspect. We told the community that 2.0 would be an MVP, a taste, and 2.1 would be feature complete for most use cases. With the idea that 2.1 could be the
version that gains mass market adoption. This proposal means some organizations will not adopt until 2.2.
So I do not support this proposal.
Bret
Sent from my Commodore 64
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
On Mar 7, 2018, at 8:00 AM, Piazza, Rich <rpiazza@mitre.org> wrote:
Work was started on STIX 2.1 at the end of 2016, long before STIX 2.0 was released as a CS. This represents a significant amount of work, as Trey pointed out. There is much “Text Complete” work to show from this period, for instance:
· Location
· Malware
· Note
· Opinion
· internationalization
This work was done under the informal TC process that was used to produce STIX 2.0. I think it is highly disruptive to introduce a new process in the middle of creating a new CS.
Therefore, my suggestion is that we declare STIX 2.1 to be “done”, and start the process for it to be released as the 2.1 CS. No additions will be allowed, and incomplete work will be dropped from 2.1.
We can then start the development of STIX 2.2 using the new fully-defined process discussed at the F2F. This also obviates the need for version numbers other than 2.1, since the only reason for various CSDs will be editorial in nature. STIX 2.0 was accepted as a CS in July of 2017. Given our experiences as editors, and the process itself, STIX 2.1 probably wouldn’t be available as a CS until early summer, which is almost a year later.
I know some will dismiss this suggestion out of hand because it doesn’t include their pet new feature. However, there is good work which could be released to the community sooner if we take this route.
Rich P.
From: <cti@lists.oasis-open.org> on behalf of Mark Davidson <Mark.Davidson@nc4.com>
Date: Tuesday, March 6, 2018 at 4:25 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Agenda for Today's Working Call - 3/6/2018
Here are the notes from today’s call.
The call began by articulating and re-affirming goals for STIX 2.1:
STIX 2.1 will be a strong technical specification that contributes to improving the defensive posture of organizations and institutions that support our societies by:
1. Promoting interoperability along key features, such as internationalization, malware, CoA, etc.
2. Permitting rapid feature iteration, for instance by creating an extension process, so that we can adapt to the evolving threat landscape
3. Including necessary backward breaking changes
4. Enabling broad marketplace adoption
5. Minimizing backward breaking changes for new work, through meeting the TC-approved “definition of done”
We also identified, for the purposes of the call, some terms to use when describing the status of issues:
1. TODO – The TC generally believes the feature is valuable, but has not started work
2. In Progress – The TC is under active deliberation to define a feature
3. Text Complete – The TC agrees on the text for a feature, and is ready to begin validating it through software implementations
4. In Test – The TC is in the process of validating that the feature works in software
5. Done – The feature is complete
After some deliberation, the perspective on the call identified that the critical question facing the TC is:
How do we enable rapid implementation of features that are already text complete without committing ourselves to untested text?
This is the question that, if left unanswered, will stall development of the STIX/TAXII 2.1 specifications indefinitely. Call participants were able to brainstorm some proposals, along with the common objections that have been raised. Most notably, I believe we need to find an answer to the critical question and move forward with specification development, even if the answer has known flaws. As a group, we must find a way to move forward.
The answers brainstormed on the call (and shortly after in slack), along with their known objections, are:
- Use version number on individual STIX objects, i.e., stix2.1-csd01
- This potentially introduces an explosion of version numbers, resulting in interoperability issues
- Use version numbers in the MIME type, i.e., application/stix+json; version=2.1-csd01
- Multiple objections have been raised in various conversations, including slack, email, and GitHub
- Do not make any special distinction for individual drafts
- Objections relate to non-interoperability across draft versions
- Create an extension mechanism and use that
- Objections largely center around wanting to make sure key capabilities are in STIX 2.1
- Create a new STIX 2.0 CSD-03 that includes the changes in spec necessary for extensions going forward. This CSD would then be used as the basis for all 2.1 objects to be added using extensions in a 2.1CSD01
The CTI TC’s must deliberate and select an answer to the critical question, and must proceed in unison once an answer is selected. Please debate the value of the various solutions, and continue to propose new ones.
Thank you.
-Mark
From: <cti@lists.oasis-open.org> on behalf of Mark Davidson <Mark.Davidson@nc4.com>
Date: Tuesday, March 6, 2018 at 12:08 PM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Agenda for Today's Working Call - 3/6/2018
All,
The past week has generated a lot of discussion and varying perspectives on how best to proceed with development of STIX/TAXII 2.1. While there is general agreement on the goals for STIX/TAXII 2.1, the implementation of these goals has uncovered some vigorously debated tradeoffs that warrant further discussion.
On today’s working call we will:
- Articulate and re-affirm the goals for STIX/TAXII 2.1
- Clearly identify the tradeoffs identified through goal implementation and discuss them constructively
- Consider a proposed solution for moving forward
- Arrive at a concrete proposal that we can use for the duration of STIX/TAXII 2.1 development
Thank you.
Mark Davidson | Engineering<image001.png>
NC4 Soltra
1225 S. Clark Street, Suite 1103
Arlington, VA 22202
www.soltra.comDisclaimer: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.
.....
. . . . .