[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cti-stix] RE: STIX 2.0 Specification Questions
|
Thanks Allan! I think this covers the use cases very well. And I’m glad you brought up Example 1, because we need to determine the implications, if anything, for the spec. I agree that Example 2 is not a STIX spec issue. I even think Example 3 is not a spec issue. But I also think they are
tangential use cases. The STIX spec states the following: This specification does not address how implementations should handle versions of the object that are not current. So even managing all of the versions, to support those use cases, is outside the scope of the spec. The sentence in question doesn’t
prohibit you from implementing a “history viewer”. Additionally, what to send (current or all versions) seems more like a TAXII issue, especially if I’m asking the TAXII server to “resolve” an id. I’m more concerned about the semantics – what does the reference
mean? What information is available to me from an id reference? My claim is that we want to state that it means the most current version of the “referred to” object – other older versions are interesting only for the tangential use cases (Example 2
and 3). As for example 1, the relationship is between object A and object B, not A.v1 and B.v1. The relationship object doesn’t contain version numbers for the source/target refs. It is up to the relationship’s
object creator to determine if it needs to be revoked. This gets confusing, because the relationship’s object creator might be different than the object creators of A and B. I’m not sure if the spec should say something about this. Rich From: Allan Thomson [mailto:athomson@lookingglasscyber.com]
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]