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] TAXII


Ditto. It the goal is to ensure we never have CTI, then let’s continue to change our minds right as we are about to publish. We can go for decades and our bosses will think we are hard at work.

Given I’m effectively my own boss. I veto that idea.

Let’s finish what we’ve got. Then we can work on something better later.

On Mar 12, 2017, at 5:27 AM, Dave Cridland <dave.cridland@surevine.com> wrote:

I also agree with everything Allan says here.

Dave.

On 11 Mar 2017 19:56, "Allan Thomson" <athomson@lookingglasscyber.com> wrote:

+1 on ‘if we are going to re-open things up then we should consider alternative proposals from across the community and do a formal review of both requirements, pros/cons of each approach and then choose as a community which path is best.

 

However…

 

We should not re-open things up. TAXII 2.0 is fairly close and despite it not being perfect; it is a good step forward towards a mechanism to share STIX content.

 

Will it be the only mechanism to share STIX 2.0 content. Absolutely not.

 

XMPP, Email, FTP, SSH….etc are all protocols that could and will be used for conveyance of STIX content.

 

Lets finish TAXII 2.0 and get some interoperability on it before we start consider alternatives.

 

Allan

 

 

Hello all - I have been making numerous arguments against this JSON-API proposal on Slack, but figured I had better send them to the mailing list as the whole TC does not monitor Slack.

 

- First, let me preface this by saying personally I do not agree at all with how this proposal has come about. We have been working on TAXII 2 as a community for over a year, and many, many TC members have contributed to it. To come in at the RC stage with an "out-of-the-blue" ground-up re-proposal is far from ideal. It is in my opinion very hard to consider a proposal solely on its merits with timing such as this.

 

- In my opinion, in order to make an argument to re-visit all of TAXII at this late stage, one should have a compelling set of reasons for this re-visit - ie a list of problems that exist in the RC proposal that either do not exist or are solved in the new proposal. There is no such set of reasons presented here - it is simply a ground-up re-think with no compelling arguments presented as to why it is superior to the current RC TAXII proposal. As such, to me this JSON-API proposal to me is very much a solution in search of a problem... what are the specific problems it is solving?

 

- The new JSON-API based proposal is **extremely verbose**. It is difficult to put an exact number on the "data bloat" occurring here, but I would conservatively place it at around 10x vs. the RC1 proposal. We must keep in mind that most vendors are potentially dealing with extremely large data set sizes when it comes to CTI production and consumption, and size matters - both on the wire, and in memory, and at parse time. The argument "CPU/Memory/Disk is cheap" does not hold water in the world of big data. Data size still matters. In return for this data bloat, I would hope that this proposal came with a large set of concrete benefits, but I don't see them.

 

- Finally - If we were actually going to re-open everything and spend another 3/6/9/12 months on TAXII 2, then I would humbly also request time to submit a proposal for OData as well - http://www.odata.org/ - as this is an existing OASIS standard developed over a long period of time, and backs large scale enterprise services already, so I have a lot more confidence in it than JSON-API for our use cases, and it would also give us TAXII Query as well as many other capabilities out of the box.

 

-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown

 

 

----- Original message -----
From: Patrick Maroney <pmaroney@wapacklabs.com>
Sent by: <cti@lists.oasis-open.org>
To: Bret Jordan <Bret_Jordan@symantec.com>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] TAXII
Date: Wed, Mar 8, 2017 11:22 AM
 

The Eclectic-IQ slide on Objects (slide 8) is a compelling argument (as are arguments for json-api, etc.).  As is the general argument for looking to and fully vetting mature transport mechanisms like XMPP. 

 

My .02: With all due respect to the efforts of those folks who've expended significant effort to get us to where we are, I don't think one week is adequate for the community to fully assess and understand these counter-proposals.


Patrick Maroney

Principle Engineer - Data Science & Analytics

Wapack Labs


On Mar 7, 2017, at 12:24 PM, Bret Jordan <Bret_Jordan@symantec.com> wrote:
 

All,

 

On the working call today, we had two presentations about possible additions / changes / modifications to the current TAXII RC 1 specification.  The first presentation was from EclecticIQ on the possible use of JSON-API.  The second presentation was from Cisco on the use of XMPP-Grid.  At a minimum, I would like this community to use these presentations as a sanity check for what we have done. 

 

Call to action: As a member of this open community, if you are in support of either of these technologies, or would like the TAXII Community to focus more time on either of them, please speak up.  If you have questions about what these technologies would mean for TAXII, please ask here on the email list and we will defer to either EclecticIQ or Cisco to answer. 

 

With all suggestions, it is up to the sponsor of that idea to gather support, drive the discussion, and help write any and all normative text that would support it.

 

As a reminder, the current TAXII specification is nearing completing.  So if we need to adopt or change anything based on these presentations, we really need this community to identify that within the next week.  

 

Bret

 

 

 


--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


Attachment: signature.asc
Description: Message signed with OpenPGP



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