Re: [cti-stix] Versioning terminology

[John-Mark Gurney <jmg@newcontext.com>]

Wunder, John A. wrote this message on Wed, Jun 01, 2016 at 13:26 +0000:
> That makes sense, though I think we’ll need to add another sentence to clarify that tools are not required to practice STIX versioning internally.

That phrase "and the changed object is shared in a STIX ecosystem" was
added to address the issue of internal changes causing version bumping
when not shared...

Without that phrase it could be read that every change to a field
requires a new version, even w/o that version being shared.

> From: Allan Thomson <athomson@lookingglasscyber.com>
> Date: Wednesday, June 1, 2016 at 9:19 AM
> To: "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
> Subject: Re: [cti-stix] Versioning terminology
> 
> John – I think the following needs to be changed
> 
> “: if the fields and values of that version are changed and the changed object is shared in a STIX ecosystem”
> 
> This sentence suggests that versioning applies to objects when the object is changed AND shared. Not just changed. I believe that it would be better/easier if versioning occurs when objects are changed regardless of whether a specific object is shared or not. It will be simpler to track in products.
> 
> My reason is
> 
> 
> a)      I share a v1 obj1 with vendor A.
> 
> b)      Then I change the object to v2 obj1 and share with vendor B.
> 
> c)      Then change the object again to v3 obj1 and share again with vendor B.
> 
> 
> Do I have to remember that I only shared v1 with vendor A? So if I change the object again (a 4th time) and share with vendor B that this is now v2 for vendor A?

No.  It is not.  If the object has the same ID, then the version will
be the same.  So sending a v2 object to A where the v2 object to B is
different is a violation of the spec.

> Basically my sequence would require producers to keep track of all versions of objects and to whom they have shared them with.

Now if you are trying to share different sets of changes to A and B,
I would say that the spec does not support that, and you should call
those objects by different id's if you want to have two different
objects that are "current" to two different recipients..

> I suggest that would never work in practice.
> 
> So the sentence should be changed to ““: if the fields and values of that version are changed” and remove the statement on sharing with STIX ecosystem.

-- 
John-Mark