[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-stix] RE: STIX 2.0 Specification Questions
|
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. Example #2: Version history display/use Similarly, products show history of objects and what have changed over time. In this case the ID is shared across all versions of an object so it does not resolve to just one 1 version it resolves to a list
of versions. This is a product issue not a STIX issue. Example #3: Object version sharing Finally, if I want to share that history of objects with another system I will send the list of objects with their IDs + version #s per object to the other system. Again in that case the object id alone does
not resolve to the latest version. STIX does need to support sharing of multiple versions of an object and it does by having the id and version # in the objects as required.
In summary: I think there are multiple reasons why even keeping the SHOULD statement is not that valuable in the spec and by keeping it you might introduce confusion rather than help. Allan From: "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org> on behalf of "Piazza, Rich" <rpiazza@mitre.org> I am uncomfortable with not using a MUST in that sentence. But I could live with a SHOULD. I would be against taking the sentence out entirely. From: cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Back, Greg I dislike the idea of MUST requirements on how data is to be interpreted. Particularly if receiving a new version of a common object (such that a new version is “available”) requires
a change to how existing data is interpreted. SHOULD at most, but I wouldn’t be opposed to removing it entirely. Greg From:
cti-stix@lists.oasis-open.org [mailto:cti-stix@lists.oasis-open.org]
On Behalf Of Wunder, John A. Do we need a line in the specification to indicate that ID references between objects MUST always be resolved to the newest version of the object? Right now, we have text in the IDs and References section which says this: ID references resolve to an object when the value of the ID reference property (e.g.,
created_by_ref) is an exact match with the
id property of another object.
If an ID reference resolves to an object for which multiple versions exist, the reference
MUST be resolved to the latest available version of the object. ID references
MAY refer to objects to which the consumer/producer may not currently have. This specification does not address the implementation of ID reference resolution. (https://docs.google.com/document/d/1HJqhvzO35h62gQGPvghVRIAtQrZn3_J__0UcDAj-NXY/edit#) Note the sentence in red. We added that a couple weeks ago because some people felt it was not fully specified to resolve an ID reference to an object…they felt that ID
references should implicitly always resolve to the newest version of the object. On the other hand, Allan has said that resolving ID references within a tool is a function of that tool and we should not have normative requirements around it. Some tools may
want to resolve it to all versions of an object and show the full history, others may show the newest, etc. His full comment is available in the google doc. So the question is…should that sentence remain in the document? If so, is it a MUST requirement or a SHOULD requirement? |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]