OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: Draft tranche plan for achieving our July target date for draft specs (STIX 2.0, TAXII 2.0, CybOX 3.0)



Is there a place for Internationalization of text fields?

I would like very much to see it in STIX 2.0 (or CTI Common?)

and I am willing to contribute.






From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Barnum, Sean D.
Sent: Tuesday, February 02, 2016 3:49 AM
To: cti@lists.oasis-open.org
Subject: [cti] Draft tranche plan for achieving our July target date for draft specs (STIX 2.0, TAXII 2.0, CybOX 3.0)




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.


  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.

Please let us  know if you see any issues with this tranche plan.



The first tranche (Indicators) is the most relevant for now as it begins today.

Below is a draft plan for the Indicator tranche. This draft Indicator Tranche plan is also in the wiki.

This is a very aggressive plan considering the amount of issues to discuss and decide and the limited time to do it.

We will strive to achieve this plan and encourage active collaboration from everyone to help us accomplish it.

If you have comments, feedback or issues with this draft plan please let us know so that we may adapt as appropriate.




Indicator tranche plan


To discuss and reach consensus on all in-scope tracker issues for STIX 2.0 that are required to support common indicator use cases.

Target completion date:

February 29, 2016

Proposed workflow:

  • 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 writeup 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)

Proposed prioritization/plan for dealing with Indicator tranche issues (as laid out below):

  • Week 1 (2/1 - 2/5)
      1. IDable construct fields
      2. Source reference approach and fields
      3. Relationships
  • Week 2 (2/8 - 2/12)
  • Week 3 & 4 (2/15 - 2/26)
    1. Tackle Patterning (Thinking on this is currently occurring and will not stop. This is only a time set aside for focused discussion.)
    2. Tackle Versioning (Likely okay if we don’t completely tie this one off)
    3. Tackle Time range format, Indicator_Type vocab and ability to assert indicator as false positive


  • CTI Common
      • Object ID format and requirement (STIX #301, 221)
      • Remove abstract base types for “top-level” objects (STIX #311, 386) (F2F consensus)
      • Remove Short_Description (STIX #194) (F2F consensus)
      • External_IDs property on all IDable constructs (STIX #358, 187) (F2F consensus)
      • Controlled Vocabularies (STIX #141)
        • Simplify structure for Controlled Vocabularies (F2F consensus)
      • Refactor report object (STIX #385) (F2F consensus)
      • Data Markings (STIX #8, 231, 379, 378, 185)
      • Discrete Timestamp format (STIX #294)
      • Key constructs all extend from a common IDable construct base type (STIX #148)
        • Consensus on approach
        • Open questions on which fields and names of fields
      • Relationships (STIX #291, 201, 139)
        • Subclassing
        • Develop one or more vocabularies for RelationshipType/Relationship (STIX #4)
      • Separate Source construct (STIX #233, 263)
        • Consensus on approach
        • Open questions on how to relate it to content
        • Which fields belong on Source?
    • Open topics
      • Time range format
        • Separate fields or leverage ISO 8061 use of “/“ as extension of consensus discrete timestamp approach.
      • Patterning
        • Separate patterns and instances (STIX #375)
        • Add capability for variable substitution in CybOX for patterning (CybOX #317)
        • Add capability to incorporate temporal context and ordering into CybOX patterns (CybOX #316)
        • Lists in CybOX object fields (CybOX #380)
        • Separate Patterns and Instances in CybOX Observables and Objects (CybOX #381)
        • Create Separate Patterning Syntax/Language (CybOX #420)
        • Determine Patterning Language Operators (CybOX #421)
        • Determine Patterning Language Syntax (CybOX #422)
        • Indicator Composition (STIX #200)
      • Versioning
  • CybOX-specific
      • Refactor/Deprecate Base DataTypes (CybOX #416)
      • Issues around Object Subclassing (CybOX #411)
      • Common object refactoring complete
    • Open topics
  • General STIX
      • Flatten all aggregating list layers (STIX #262)
      • Flatten all the list types in STIXType STIX #382)
      • Refactor TTP (STIX #360) (F2F consensus)
      • Kill Chains (STIX #47, 117, 241, 208, 190, 191)
    • Open topics
  • Indicator-specific
    • Consensus asserted
    • Partial consensus asserted (some open questions remain)
    • Open topics
      • Sightings (STIX #306, 359, 240, 198)
        • 2-ended-Relationship or 1-ended-assertion?
      • Indicator structure (refactoring so that Observable and Test Mechanism are integrated into a single approach)
        • Indicator structure simplification (STIX #376)
      • Indicator_Type vocab (STIX #243)
      • Ability to assert that an indicator is a false positive (STIX #307)




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]