Hi Rich - my main issue with this is there
are things in your list - most notably malware and i18n, but you
could really name anything - that while "text complete", are
actually far from complete as we don't have anyone who has proven that
they work. This was discussed in detail at the F2F and everyone agreed
that we really need working code for some of this stuff before we put it
in the spec, to avoid making mistakes again. This is precisely why we're proposing
this extension process, so that folks can actually use some of these objects
in the wild, via STIX, to prove them out. - Jason Keirstead STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security "Things may come to those who wait, but only the things left by those
who hustle." - Unknown From:
"Piazza, Rich"
<
rpiazza@mitre.org> To:
Mark Davidson <
Mark.Davidson@nc4.com>,
"cti@lists.oasis-open.org" <
cti@lists.oasis-open.org> Date:
03/07/2018 11:00 AM Subject:
Re: [cti] Agenda
for Today's Working Call - 3/6/2018 Sent by:
<
cti@lists.oasis-open.org> 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: TODO – The TC generally believes
the feature is valuable, but has not started work In Progress – The TC is under
active deliberation to define a feature Text Complete – The TC agrees
on the text for a feature, and is ready to begin validating it through
software implementations In Test – The TC is in the process
of validating that the feature works in software 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
Mark.Davidson@nc4.com NC4 Soltra 1225 S. Clark Street, Suite 1103 Arlington, VA 22202
www.soltra.com Disclaimer: 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.