Re: [cti-taxii] Re: [EXT] [cti-taxii] Alternate Query Proposal Walk Through February 19th

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

Hi folks;

Unfortunately through traveling last
week to SF and back I have come down with quite a bad cold, that has come
with it a bad case of laryngitis. I can't really speak.

Can I request we delay until next week...

-
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 


__________________



Yes.

 

From: Jason Keirstead <Jason.Keirstead@ca.ibm.com>
Date: Friday, February 8, 2019 at 3:57 PM
To: Richard Struse <rjs@mitre.org>
Cc: "cti-taxii@lists.oasis-open.org"
<cti-taxii@lists.oasis-open.org>
Subject: Re: [cti-taxii] Re: [EXT] [cti-taxii]
Alternate Query Proposal Walk Through February 19th

 

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