I think since we call the spec version field “spec_version” and it’s been moved out of the TLOs, that makes total sense. I’m also fine with revision btw…in all honestly people are going
to see either of those fields and know exactly what they do.
I’ll work on this text with Bret and send an update when we’re finished for another quick round of reviews. We seem very close here though.
From:
Terry MacDonald <
terry.macdonald@cosive.com>
Date: Thursday, June 2, 2016 at 5:56 AM
To: Bret Jordan <
bret.jordan@bluecoat.com>
Cc: Allan Thomson <
athomson@lookingglasscyber.com>, "Wunder, John A." <
jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <
cti-stix@lists.oasis-open.org>, Rich Piazza <
rpiazza@mitre.org>
Subject: Re: [cti-stix] Versioning terminology
Is it worth aligning the Revision field name with that analogy then?
Cheers
Terry MacDonald
On 2/06/2016 8:58 AM, "Jordan, Bret" <
bret.jordan@bluecoat.com > wrote:
The one problem you have with the term Revision is that people assume that the first version of the object will have an empty Revision field and it will only get populated when their is a "revision". This is generally why I think most
of us like the term "version". This way the first version can have a version=1
Thanks,
Bret
Bret Jordan CISSP
Director of Security Architecture and Standards Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
On Jun 1, 2016, at 15:26, Terry MacDonald <
terry.macdonald@cosive.com > wrote:
One more question...
Should we change Object Version terminology to Object Revision? If we use the
revision field to describe the differences in versions of the object, maybe we should align the heading and name of the concept to being Object Revision as well?
At the moment we talk about object version in the text and then record that as a Revision change. That seems less intuitive to me. I'm interested in what others think.
Cheers
Terry MacDonald
Cosive
On 2/06/2016 04:41, "Piazza, Rich" <
rpiazza@mitre.org > wrote:
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