This seems contradictory to me. Allan says : “ would be better/easier if versioning occurs when objects are changed
regardless of whether a specific object is shared or not” and you say “ tools are not required
to practice STIX versioning internally”
From:
cti-stix@lists.oasis-open.org [mailto:
cti-stix@lists.oasis-open.org]
On Behalf Of Wunder, John A.
Sent: Wednesday, June 01, 2016 9:27 AM
To: Allan Thomson <
athomson@lookingglasscyber.com>;
cti-stix@lists.oasis-open.org Subject: Re: [cti-stix] Versioning terminology
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.
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 4 th time) and share with
vendor B that this is now v2 for vendor A?
Basically my sequence would require producers to keep track of all versions of objects and to whom they have shared them with.
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.
allan
From:
"
cti-stix@lists.oasis-open.org " <
cti-stix@lists.oasis-open.org > on behalf of "Wunder, John" <
jwunder@mitre.org >
Date: Tuesday, May 31, 2016 at 6:10 PM
To: "
cti-stix@lists.oasis-open.org " <
cti-stix@lists.oasis-open.org >
Subject: [cti-stix] Versioning terminology
Hey all,
I was talking with Terry just now and one thing he mentioned was that our usage of the terms “object” and “object series” in versioning might not be super intuitive to new users. As
a reminder, here’s the current definitions:
·
Object Series:
An object series consists of all versions of a STIX object, identified by having the exact same value in the
id field. Only the original object creator of an object series is permitted to issue new versions
in that object series.
o
For example, an object series might be created to describe a certain threat actor. Even as the description and other details of that threat actor change
over time, the object series stays the same. Thus, that threat actor representation by that producer is identified by the
id field for that object series.
·
Object:
An object is a single version (instance) of a STIX object series. STIX TLOs are immutable: if the fields and values of that object are changed and the changed object is shared
in a STIX ecosystem, these versioning processes must be followed. A TLO is identified by the
id and
revision fields. Only the original object creator (the creator that created the ID and published the
first version of the object series) is permitted to issue new revisions of an existing object series.
o
For example, a particular version of the object series describing that threat actor, consisting of a single object in the object series, is identified
with the id and revision field.
The way we use these terms in versioning is very solid and overall I think we’re all pretty happy with how versioning works in general. Terry pointed out, though, that the use of the
term object/object series could be better. People, for the most part, think about objects as the persistent thing that get versioned over time. So, if anything, the thing we call “object series” should really be called just “object”. We could then call what
we now call “object” an “object revision”. So, the new definitions would be:
·
Object:
An object consists of all versions of a STIX object [ this definition clause is now kind of circular,
which suggests to me that the rename is probably smart] , identified by having the exact same value in the
id field. Only the original object creator of an object is permitted to issue new versions of that
object.
o
For example, an object might be created to describe a certain threat actor. Even as the description and other details of that threat actor change over
time, the object ID stays the same. Thus, that threat actor representation by that producer is identified by the
id field for that object.
·
Object Version:
An object version is a single version (instance) of a STIX object. STIX object versions are immutable: if the fields and values of that version are changed and the changed
object is shared in a STIX ecosystem, these versioning processes must be followed. An object version is identified by the
id and
revision fields. Only the original object creator (the creator that created the ID and published the
first version of the object series) is permitted to issue new versions of an object.
o
For example, a particular version of the object describing that threat actor, consisting of a single version of that object, is identified with the id
and revision field.
So…what do you think? Do you like these new terms? I do, I think they make it significantly more clear for the majority of people who think about objects and versions rather than object
series and objects in that series.
John