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] Advertising a CSD version of STIX and TAXII

Mark – I generally agree with your points.


However, when issues occur in interoperability having the version of 2.1-CSD01 vs 2.1-CSD02 shared between systems will help debug/issues to be resolved.


I don’t see including the longer version information hurts your goals/statements but helps interop/debug.






From: Mark Davidson <Mark.Davidson@nc4.com>
Date: Thursday, March 1, 2018 at 9:30 AM
To: Allan Thomson <athomson@lookingglasscyber.com>, Bret Jordan <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Advertising a CSD version of STIX and TAXII


I’m in favor of option #1, as indicated by my comments on the issue, which I’ll reiterate here:


I'm personally in favor of using the plain version string, e.g., version=2.1 for all CSDs, for the following reasons:

1.       I don't understand why the stated problem is important to solve - no supporting evidence has been given in this thread, just a problem statement and various proposed solutions.

2.       Each new CSD and CS will require code changes to content negotiation, which increases the chances of interoperability breaking. If the change had supporting arguments, then I might view this tradeoff as worthwhile.

3.       I don't think the community in general will support multiple CSDs at once, I see the community supporting the latest CSD/CS. For instance, I don't see testing multiple CSDs at a plugfest - I see us doing interop testing for just the most recent CSD or CS.

I guess my biggest concern is - why is this a problem worth solving? I can see drawbacks for the various solutions proposed, though I'm not able to reason whether or not there are benefits to them.


In terms of what I'd bring to a plugfest or use as a baseline for a vendor integration, I'd only bring something that implements the most recent CSD or CS, and I would not care one bit about compatibility with older CSDs.


want TAXII 2.1 compatibility issues to arise when two vendors implement different CSDs/CSs, because that's how we'll move the fastest toward interoperable TAXII 2.1 implementations in the marketplace.



Thank you.



From: <cti@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
Date: Thursday, March 1, 2018 at 12:13 PM
To: Bret Jordan <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Advertising a CSD version of STIX and TAXII


I suggest Option 2) is preferred.


For orgs that don’t care about the sub-version information they can parse the version string for the <major>.<minor> information and ignore the rest.


For orgs that care they can use the full version information.




From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of Bret Jordan <Bret_Jordan@symantec.com>
Date: Thursday, March 1, 2018 at 9:06 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Advertising a CSD version of STIX and TAXII




We have been having a discussion on Slack (#taxii) and in the TAXII Github issue tracker for issue 49 (https://github.com/oasis-tcs/cti-taxii2/issues/49) about how to handle, or if we should handle, the ability to advertise a CSD / draft version that is supported by a solution.  As we have not been able to come to consensus, I am asking the broader community for comments and feedback.  



As we begin to release CSDs for STIX and TAXII 2.1 and the amount of time between releases grows, I believe it will be important for systems to know and understand which version, even a draft version, that the solution currently supports to make sure it can work seamlessly. 



1) Do nothing. Always advertise "2.1".  So for CSD01, CSD02, CSD03, etc, you would always just advertise "2.1". 


The risks to this that I see are, clients will have no way of knowing if their product is talking to another product that supports that same version of features. If everything was always additive, this "might" be okay. However, given our new process and how concepts can be dropped before the final CS, if they do not have support or code, then a client with support for CSD02 might not work with a client that supports CSD03. And there would be no way for the clients to know that, without two humans talking it through.  


Also we may have a situations where something is added to CSD01 and then radically changed in CSD02 due to issues that are found during development. If this happens, a server that is hosting content and is able to update more quickly, will have no way of telling a client (that has not yet updated) that it is using the newer version.


2) Add some sort of designation or suffix to the end of the version that represents an ever increasing value that can easily distinguish  the version you are using.  Say for CSD01 through CSD03 you could do 2.1-draft01, 2.1-draft02, 2.1-draft03, and then when the final version is ready for a CS level release, the suffix would be dropped and the version would be just 2.1.  













Disclaimer: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received.

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