STIX 2.0 Tranche Plan (draft) - STIXProject/specifications GitHub Wiki

As discussed at the face to face meeting and briefly on the TC monthly call and the list we plan to work toward our aggressive July target date for draft STIX 2.0, TAXII 2.0 and CybOX 3.0 specs utilizing a more product management approach with roughly monthly tranches focused on resolving all in-scope identified issues relevant to a particular capability area.

A proposed tranche plan is:

  1. February 29th - Run Indicators to the ground. Get these fundamentals worked through to enable us to talk to vendor on the RSA show floor about it. And have something to show them.
  2. March 31st – Run remaining cross-cutting issues to ground. Run Identity-based Victim, Source and Actor top level abstractions to ground.
  3. April 30th – Run Incidents (investigations) to ground. Run Asset top level abstraction to ground. Run Campaign to ground.
  4. May 31st – Run controlled vocabularies to ground. Run automated COA default extension to ground. Run analytic support (opinions, assertions, hypotheses, etc.) to ground.
  5. June 30th – All other remaining top level elements. Review pass for consistency (field name choices, naming conventions, structure patterns, etc) and quality.

This should cover the existing in-scope issues in a coherent and dependency-aware iterative fashion.

For CybOX, the Indicator tranche is likely to cover patterning and key object support decisions with remaining tranches focused on key object refactoring based on decisions from the Indicator tranche.

Detailed monthly tranche plans

Each month a detailed tranche plan will be pulled together and released detailing which particular issues will be addressed and a timeline for when they will be tackled.

Proposed workflow for addressing issues:

  • Raise and describe the issue with a brief wiki writeup
  • Discuss issue on list and/or slack (with summaries made on list). Anyone with proposed solution may add details of their proposal (proposed normative text, examples, diagrams, schema,etc clearly marked as a proposal) to the wiki and announce it to the list.
  • Discuss, debate, review proposals, comment as appropriate within defined time window to work towards consensus.
  • Discuss key issues on weekly working call.
  • If consensus (unanimous or at least no strong objections) reached:
    • Capture normative language in pre-draft spec document
    • Capture consensus changes in JSON Schema implementation
    • Capture consensus changes in UML model
    • Capture statement of consensus in issue tracker
    • Mark issue tracker as “Consensus Achieved"
    • Clearly mark relevant issue wiki pages as “Consensus Achieved” or potentially move them to a separate Consensus repo to avoid confusion
  • If consensus not achieved (strong objection exists) within allowed time window:
    • Discuss and decide whether issue is absolutely necessary for MVP and if not decide to postpone
    • OR
    • Capture current consensus status in issue tracker, mark as “Consensus Stalled”, move on to other issues and revisit the issue during last week of tranche
    • OR
    • Decide to either hold formal vote to decide (more likely for core critical issues)