Re: [cti-stix] Question on Versioning with 2.1

I agree that allowing someone besides the object creator to upgrade the spec version of an object could be problematic.

However, there is no guarantee that the object creator will do this, which means that CTI could be lost or "orphaned" in an old spec version.

My thought is that anyone could upgrade the spec version of an object, but only in a restricted way. In other words, you can only change the spec_version property, and perhaps some other properties, in a prescribed way (described in normative text in the spec). A special relationship would be used to relate the old spec version object to the new spec version object (“upgrade_spec_version”).

Anyone can make this upgrade, but the new object should be identical (except for the new ID) regardless of who does it. This might help with the signature issue, but I have to think about that more…

Rich P.

On 4/9/18, 7:53 PM, "cti-stix@lists.oasis-open.org on behalf of John-Mark Gurney" <cti-stix@lists.oasis-open.org on behalf of jmg@newcontext.com> wrote:

Bret Jordan wrote this message on Fri, Apr 06, 2018 at 20:08 +0000:

> On our editor's call today, John Wunder, Rich Piazza, and myself had a question about how to handle the new spec_version property that the TC decided to add to all objects.

> Question:

> Does changing an object from 2.0 to 2.1 schema result in a version change? And as such can it only be done by the object creator?

> The knee jerk reaction I think most people will have will be similar to our initial reaction which was "yes, it requires a version change". However, upon careful consideration, I am not sure that is a good thing. Content should be content, regardless of how it is serialized. Also, without allowing this, there is no good way to upgrade content in the wild. Products will have to support older versions of STIX for a very very long time. Further, if you do the derived relationship type, then you need something in TAXII that will say, given this relationship, go find any derived from relationships, and then walk the graph to find all of the new relationships. This will get ugly really fast and will cause analysts to not see the whole picture.

Yes, it should require a version change.. This is partly why I was

not a fan of this...

The reason it requires a version change is that there may be signifcant

differences between how an object is parsed and understood between

versions... And allowing non-authors to change versions may result

in bad inteligence being distributed...

Also, if/when we add signing, not signing the version field would be

bad in that you could down grade CTI to hide important fields.. The

downgrade converts fields that can change the meaning, say

a future patterning_language property on an Indicator, into a custom

field, and possibly change the behavior...

This is exactly my argument against adding the draft specifier to the

version field. We really need to keep data forwards compatible, that

is, if you parse version 2.0 content by a version 2.5 parser, that it

will be semantically the same as being parsed by a 2.0 parser...

> So while I think we initially thought it would be "yes", I think we might now be leaning towards "no". But this is not a decision that we editors can make. So we are bringing up to the TC to decide.

Please take into account signatures... there's a reason why we only

allow authors to change properties, and version should be included.

John-Mark

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail. Follow this link to all your TCs in OASIS at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

cti-stix message