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


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

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

Subject: Re: [cti-cybox] Re: [cti-stix] CybOX Versions in STIX?

(Sorry for the double reply to the topic)

I think the approach of allowing multiple versions of CybOX makes conformance difficult. I do agree that CybOX could move faster than STIX (especially if “adding an object” requires a revision to CybOX), and that should be addressed by the CTI TC.

Allowing a new version of CybOX to be used in conjunction with an existing version of STIX would mean that even though two implementations supports "STIX 2.1”, one implementation might actually have substantially different capabilities because it supports a newer version of CybOX. 

In the scenario where a “newer CybOX" implementation sends information to an “older CybOX" implementation, the “older CybOX" implementation will either reject the payload (because it has unknown fields) or drop part of the payload on the floor (because this is JSON and that’s how we do things). In both cases, two things that say “STIX 2.1” on the label will not interoperate the way people expect.

Maybe I’m missing something, but I just don’t see how allowing arbitrary CybOX versions is workable unless we invent a general purpose “anything can go here” extension point, complete with media types.

Thank you.

From: <cti-cybox@lists.oasis-open.org> on behalf of Paul Patrick <ppatrick@isightpartners.com>
Date: Wednesday, May 11, 2016 at 8:29 PM
To: "Kirillov, Ivan A." <ikirillov@mitre.org>
Cc: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Subject: [cti-cybox] Re: [cti-stix] CybOX Versions in STIX?


Actually I could see CybOX evolving faster than STIX due to the fact that CybOX has more potential consumers (MAEC, DFAX, OpenC2) that would drive faster evolution than STIX. If we follow the rules for evolution that minor revisions MUST backwards compatible with previous versions and any incompatible change requires a major release, why wouldn't we need the spec_version and that the dependency from STIX would be to a specific major version and a base minor version from which later minor versions could be used?

Sent from my iPhone

On May 10, 2016, at 3:07 PM, Kirillov, Ivan A. <ikirillov@mitre.org> wrote:

At this point I think the assumption has been that a particular version of STIX would support a particular version of CybOX, and only this version.

  • STIX 2.0 would support CybOX 3.0
  • STIX 2.1 would support CybOX 3.1
  • Etc.
Does this align with the existing community perceptions? Are there any particular needs or cases where STIX would want to support multiple versions of CybOX at one time? The only hypothetical example I can come up with is if STIX incorporates data from another source, such as MAEC, that uses a different version of CybOX. However, I would imagine that, for compatibility reasons, STIX would only want to incorporate data sources that use the same version of CybOX that it uses.

This came about from some recent discussions in CybOX about the spec_version field and whether we need to incorporate it in the CybOX Container/ArgleBargle. If the assumption is that STIX, MAEC, and other CybOX users will only support a particular version of CybOX for any one release, then perhaps this field isn’t needed.


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