Rich can we present it on February
19th - I would like some time
to prepare a presentation. - Jason Keirstead Lead Architect - IBM Security Connect
www.ibm.com/security "Things may come to those who wait, but only the things left by those
who hustle." - Unknown From:
"Struse, Richard
J." <
rjs@mitre.org> To:
Jason Keirstead <
Jason.Keirstead@ca.ibm.com>,
"cti-taxii@lists.oasis-open.org" <
cti-taxii@lists.oasis-open.org> Date:
02/08/2019 03:21 PM Subject:
[cti-taxii]
Re: [EXT] [cti-taxii] Alternate Query Proposal Walk Through February 19th Sent by:
<
cti-taxii@lists.oasis-open.org> Jason, I agree â you should have an opportunity
to present your proposal and answer questions. Letâs add it to the agenda
for the next working call. Thanks, Rich From: <
cti-taxii@lists.oasis-open.org>
on behalf of Jason Keirstead <
Jason.Keirstead@ca.ibm.com> Date: Friday, February 8, 2019 at 8:31 AM To: "cti-taxii@lists.oasis-open.org" <
cti-taxii@lists.oasis-open.org> Subject: [EXT] [cti-taxii] Alternate Query Proposal Walk Through February
19th I would like to be given the opportunity
to walk the TAXII SC through the alternative Query proposal that Terry
MacDonald and I created over 12 months ago This proposal is located here -
https://docs.google.com/document/d/1Cy_9Bh5tKEkDHGg2iv5c3AwriqVr7ygbKXWOv4-uHxs/edit#heading=h.1jcqb6vc5y7z We have floated this proposal several times to the SC - yet, there has
never really been any debate, discussion, or any significant comments
on the document or with either of us, while others have created these alternative
proposals. My understanding is this proposal may have been presented very
briefly at the F2F, however no one involved in the creation of it was present
to defend it. Most of the arguments I hear people give against the proposal, I believe
are based on false understanding of how it works. Which is why we would
like to be given the opportunity to defend it. I would like to plan to present this to the TC on the working call on February
19th. The benefits of this proposal over the current relationship one: - Ease of implementation. There is a lot of misinformation
about how hard this would be to implement. Because query types are optional
for implementations, it is actually extremely simple to implement, much
simpler than the current proposal is. It is also simple to add query types
to your software in the future. - Interoperability and Optionality. No implementor is required to implement
any specific type of query , however code implementations can 100% interoperate,
due to trivial discoverability of the types of supported types of queries - Combinations . You can combine supported query types to get what you
want . I can ask for indicators that match an observable *and* combine
this with a request for relationships - Modularity. We can add other types of queries , without creating
"endpoint hell". Vendors can even make their own query types
using STIX SEP process, and have them interact with other query types in
a 100% interoperable fashion. - Sets you up for asynchronous queries . STIX queries against data
lakes of hundreds of TB can take some time to fulfil. To expect one to
be able to always fulfill a TAXII query in a synchronous REST endpoint
in all scenarios, is not realistic. In this implementation, because the
query resource is POSTed to the endpoint, it allows results to be fulfilled
asynchronously via an alternate channel (ie, TAXII channels). Once TAXII
channels exist, this will be extremely useful. However, even right now,
software could still use existing technologies like OpenDXL to make this
feature useful. - Jason Keirstead Lead Architect - IBM Security Connect
www.ibm.com/security "Things may come to those who wait, but only the things left by those
who hustle." - Unknown