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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

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


Subject: Re: [cti] Sanity checking on references to other objects


Terry MacDonald wrote this message on Fri, Jun 16, 2017 at 08:06 +1200:
> I thought of opinion object applying to all versions of an object for
> exactly the reason I've highlighted - the opinion would apply to all
> versions of an object as any substantive changes would be released under a
> different STIX id (as a new and different STIX object), meaning that the
> 'old' opinion would no longer apply to the new (and hopefully fixed) STIX
> object.

Also, it is obvious that if the Opinion object is dated before the latest
modified date of the referenced SDO, that it is likely/possible that the
information in the Opinion object may not be 100% correct/accurate.  So,
it is up to the analyst to determine/decide if/why the Opinion no longer
matches the referenced SDO.

Or as you said, if substantive changes were made, a new object would be
issued.

> On 16/06/2017 08:00, "Wunder, John A." <jwunder@mitre.org> wrote:
> 
> > I was going to respond to the earlier discussion with exactly what Terry
> > said…we specifically decided that relationships should be valid across all
> > versions of an object. That may not apply 100% of the time (i.e. to
> > opinion, which is presumably an opinion on a specific version) but I would
> > worry about adding it as a general capability on relationship and having
> > this get bifurcated. I’d like to see more actual usage of STIX 2.0 before
> > we plan to add this (i.e. would like to revisit in the 2.2-2.3 timeframe if
> > it seems necessary).
> >
> >
> >
> > My worry would be that a consumer considers relationships valid across all
> > versions of an object (doesn’t validate the hash) while a producer
> > considers it only to the hashed version, and you have a miscommunication.
> >
> >
> >
> > John
> >
> >
> >
> > *From: *<cti@lists.oasis-open.org> on behalf of "Struse, Richard J." <
> > rjs@mitre.org>
> > *Date: *Thursday, June 15, 2017 at 3:52 PM
> > *To: *Terry MacDonald <terry.macdonald@cosive.com>, Marlon Taylor <
> > Marlon.Taylor@hq.dhs.gov>
> > *Cc: *CTI TC Discussion List <cti@lists.oasis-open.org>
> > *Subject: *Re: [cti] Sanity checking on references to other objects
> >
> >
> >
> > The concept of having an optional hash(es) for the SDOs referenced in a
> > relationship would essentially tie the relationship to a specific version
> > of an object because any change to an SDO would change the hash…  How does
> > that impact your thinking?
> >
> >
> >
> > *From: *<cti@lists.oasis-open.org> on behalf of Terry MacDonald <
> > terry.macdonald@cosive.com>
> > *Date: *Thursday, June 15, 2017 at 3:45 PM
> > *To: *Marlon Taylor <Marlon.Taylor@hq.dhs.gov>
> > *Cc: *CTI TC Discussion List <cti@lists.oasis-open.org>
> > *Subject: *Re: [cti] Sanity checking on references to other objects
> >
> >
> >
> > My understanding was that we decided in the referencing/versioning working
> > group that references would apply to all versions of an object. Therefore
> > we don't want to specify particular versions of an object when we are
> > lining them with references.
> >
> >
> >
> > We managed the possibility of the references data changing greatly by
> > mandating that if the meaning of an object changes greatly then it has to
> > be released under a different STIX id,  so that the relationship should
> > apply through all of the versions of an object.
> >
> >
> >
> > As an aside, this fact show alleviate concerns that Bret has about the
> > location object, as any major changes/revisions to a location object will
> > have to be released as a new object with a new STIX ID.
> >
> >
> >
> > Cheers
> >
> > Terry MacDonald
> >
> >
> >
> >
> >
> > On 16/06/2017 02:14, "Taylor, Marlon" <Marlon.Taylor@hq.dhs.gov> wrote:
> >
> > Hi All,
> >
> >
> >
> > I’m consolidating the discussion on “linking to other objects” to this
> > thread.
> >
> >
> >
> > References from various threads:
> >
> > ·         http://markmail.org/message/5me3xvamzadvu4jg
> >
> > ·         http://markmail.org/message/cbbw5zilfgzodcpf
> >
> > ·         http://markmail.org/message/githhm4kns6hceom
> >
> >
> >
> > http://markmail.org/message/cbbw5zilfgzodcpf - suggest the use of an
> > object hash.
> >
> >
> >
> > I suggest use of the modified_time of the referenced object.
> >
> >
> >
> > The modified_time is a single comparison which also provides temporal
> > positioning which end recipients can leverage for decision marking either
> > manual or automated.
> >
> >
> >
> > Example:
> >
> > ·         Entity_B creates Object_B at with create/modify_time = 0
> >
> > ·         Entity_A creates an Object_A with reference to Object_B and
> > create/modify_time = 1
> >
> > ·         Entity_B updates Object_B at with modify_time = 2
> >
> > ·         Entity_C gets Object_A and all Object_Bs and has the ability to
> > determine which instance of Object_B Entity_A is referencing.
> >
> >
> >
> > This is less trivial in a fast sharing environment where multiple versions
> > of an object are shared independently.
> >
> >
> >
> > Thoughts?

-- 
John-Mark


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