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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-stix message

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


Subject: Re: [cti-stix] STIX 2.0 Specification Questions


Terry,

We already have sections in the document that are non-normative...  And I think that works well.  I have always been in favor of helping people understand what we are thinking.... I do not want to try and legislate what it means to have a major version versus a revision, but some text around that would be very helpful and very wise for us to do.

I do not believe this should be a separate document or work product, unless it gets to the point where we have a lot of non-normative text.  


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 Aug 12, 2016, at 13:52, Terry MacDonald <terry.macdonald@cosive.com> wrote:

I still think we could help with some guidance. It might not be right to go in the standard as a normative statement, but maybe we need a non normative 'guidance for implementers' doc that this sort of recommendations go into?

Cheers
Terry MacDonald
Cosive


On 13/08/2016 02:04, "Jason Keirstead" <Jason.Keirstead@ca.ibm.com> wrote:

For the record - I agree with Allan on this. We should not be attempting to define when someone should version an object. This is up to the tool implementer / producer of the intel and is highly context-specific (we will never get it right).

-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


<graycol.gif>Allan Thomson ---08/11/2016 07:21:03 PM---Hi John-Mark – I agree - but it’s a product/deployment question when something is considered ‘signif

From: Allan Thomson <athomson@lookingglasscyber.com>
To: John-Mark Gurney <jmg@newcontext.com>
Cc: "Piazza, Rich" <rpiazza@mitre.org>, "Back, Greg" <gback@mitre.org>, "Wunder, John A." <jwunder@mitre.org>, "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
Date: 08/11/2016 07:21 PM
Subject: Re: [cti-stix] RE: STIX 2.0 Specification Questions
Sent by: <cti-stix@lists.oasis-open.org>





Hi John-Mark – I agree - but it’s a product/deployment question when something is considered ‘significantly changed’ and hence its not a STIX issue.

On 8/11/16, 3:16 PM, "John-Mark Gurney" <jmg@newcontext.com> wrote:

   Allan Thomson wrote this message on Thu, Aug 11, 2016 at 14:07 +0000:
   > Here’s some examples to think about.
   >
   > Example #1: Relationship versioning or not.
   >
   > If I create a relationship R.v1 between 2 objects and the relationship was created a week ago between object A.v1 and object B.v1.
   >
   > Today I change B to B.v2.
   >
   > The relationship was created a time when it was between A.v1 -> B.v1. Not B.v2.
   >
   > There may be legitimate reasons why I don’t want that relationship to automatically resolve to B.v2. But it’s a product question not a STIX exchange question.
   >
   > Therefore, it’s the product implementer’s choice whether a relationship tracks the latest versions of the ID or not.

   IMO, if B.v2 changed significantly enough that the relationship does not apply, then
   B.v2 should be a new object C, and not a new version.

   --
   John-Mark







Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail



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