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] Re: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO


Here is the text from the spec:

 

Any time a change indicates a material change to the meaning of the object, a new object with a different id should be used. A material change is any change that the object creator believes substantively changes the meaning of the object

 

Notice, that the “should” in the first sentence is not the normative SHOULD, so as you say, the specification doesn’t prevent anyone from using versioning to make “material changes”.  Further, the spec says:

 

The object creator should also think about relationships to the object when deciding if a change is material. If the change would invalidate the usefulness of relationships to the object, then the change is considered material and a new object id should be used.

 

Once again, the non-normative “should”.

 

I guess the point is – how much do we add to the spec to allow object creators to do something we explicitly warn them against doing??

 

 

 

From: <cti@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Monday, June 19, 2017 at 9:20 AM
To: Rich Piazza <rpiazza@mitre.org>, John-Mark Gurney <jmg@newcontext.com>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, John Wunder <jwunder@mitre.org>, Patrick Maroney <pmaroney@wapacklabs.com>, "Jason Mr. Keirstead" <Jason.Keirstead@ca.ibm.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "Back, Greg" <gback@mitre.org>, "Nathan.Reller@jhuapl.edu" <Nathan.Reller@jhuapl.edu>
Subject: Re: [cti] Re: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO

 

Hi Rich – I think your point on versioning of a SDO materially is important to understand (by all implementers) and it’s important to note that there is nothing in the standard that precludes such changes.

 

Other than the object-id which remains immutable after object creation all other attributes are mutable for SDOs in the current specification.

 

I’m not sure we can change the specification to enforce anything else. Therefore, it’s possible that intel changes significantly from one version of an object to another.

 

 

Allan Thomson

CTO

+1-408-331-6646

LookingGlass Cyber Solutions

 

From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Piazza, Rich" <rpiazza@mitre.org>
Date: Friday, June 16, 2017 at 6:10 AM
To: John-Mark Gurney <jmg@newcontext.com>
Cc: Bret Jordan <Bret_Jordan@symantec.com>, "Wunder, John" <jwunder@mitre.org>, Patrick Maroney <pmaroney@wapacklabs.com>, Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, "Back, Greg" <gback@mitre.org>, "Nathan.Reller@jhuapl.edu" <Nathan.Reller@jhuapl.edu>
Subject: Re: [cti] Re: [EXT] Re: [cti] [EXT] [cti] Location as a Top-Level SDO

 

John-Mark, you bring up an important point, which I, and maybe others, often forget – material changes should not be handled via versioning.

 

Therefore, no one should be changing their SDO, that your SDO is related to, in a way that makes the relationship invalid. 

 

Your work flow below is the way this should he handled – revoke the SRO, and create a new one to the new SDO.

 

I’m not sure I understand your argument about the final flag – but based on the rest of your email – I think it is unnecessary (at least for this use case).

 

On 6/15/17, 6:53 PM, "John-Mark Gurney" <jmg@newcontext.com> wrote:

 

    Piazza, Rich wrote this message on Wed, Jun 14, 2017 at 20:58 +0000:

    > I don't think we should give up on the idea of reusing Locations so quickly.  Assuming we go with Locations as SDOs, it certainly is a problem if you reuse someone's Location and they change it from underneath you.   I was first thinking that there should be immutable SDOs - in other words, the unique USA Location SDO CAN'T be changed.   If we had a set of the common ones (defined in some library/repo somewhere)  then we could just use their ids.   Duplicates are allowed, but hopefully few people would need to create their own USA Location SDO.   I was thinking of an extra property (on all SDOs?)  - final.  If final is true for an SDO, then a new version couldn’t be created. 

    

    I'd like to point out we already have an "imutable" SDO.  The versioning

    spec specifically calls out that if you make a material change to an

    SDO, that you need to create a new one, and not reuse an existing one.

   

    We might want to extend the text to say that if you created an SDO

    and link it, but that the linked SDO was incorrect, say USA vs

    USA Major Islands, that you need to create a new Location object,

    and revoke the original relationship, and that changing the original

    object is NOT the correct work flow.

   

    The idea of a final flag is an interesting one, but what would the

    handling of when a new final object is created?  Or a new one that

    had the modified date before the other one?  This is just changing

    the problem slightly w/o solving it.

   

    Other solution is to simply say the Location objects cannot be versioned.

   

    I cannot really think of a good reason/way to version/update a Location

    object w/o materially altering it's meaning.

   

    > Adding immutable objects to the spec might be a good idea in general, but I think a simpler way to handle this is just to "trust" that the library/repo contains objects that will not change.  In other words, locations created by a certain (well-known) identity (SDO-Immutable-Library) could be reused with little concern that they are going to change.  And if they DO change - maybe that is a feature - after all, all those Soviet-Union Location SDOs are no longer too useful...

   

    --

    John-Mark

   

    



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