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] Thoughts on STIX and some of the other threads on this list [formats discussion]


Hi everyone,

In order to document some evaluation criteria (requirements) and an analysis of the different format options against those criteria I put up a wiki page: https://github.com/STIXProject/schemas/wiki/MTI-Format-Analysis

Please take a look and add your thoughts, pros, cons, etc. I know there was more discussion below about not having an MTI format and instead choosing just a single one (not going to weigh in on that), but either way we need to choose a format so have to go through this evaluation.

I had a note in there about some examples of equivalent constructs in XML Schema vs. JSON Schema and XML vs. JSON. If anyone has those examples already built (maybe for STIX 1.1 or STIX 1.2) can you link them?

John

> On Sep 17, 2015, at 12:28 PM, Jerome Athias <athiasjerome@GMAIL.COM> wrote:
> 
> For now I just want to salute and thank the efforts and John and Bernd
> in this thread.
> 
> I personally don't think tweeter-like discussions have been effective
> over the last few months regarding this topic.
> As it was suggested an in-depth analysis, and face to face meeting,
> I would personally appreciate some kind of Powerpoint presentation
> over webex in few weeks with tangible arguments/comparison of pros and
> cons of XMLvsJSONvsAnythingelse.
> I just think that would be a more effective approach
> 
> My 2c
> 
> 2015-09-15 19:02 GMT+03:00 Wunder, John A. <jwunder@mitre.org>:
>> Hi everyone,
>> 
>> In an effort to come to some agreement on this topic and move forward I
>> attempted to summarize a bunch of points that I think I saw general
>> agreement on. I ran these points by a bunch of my MITRE co-workers (Sean
>> Barnum, Mark Davidson, John Wunder, Ivan Kirillov, and Jon Baker) and they
>> all agreed both with the points themselves and that there was general (not
>> complete) agreement on the points.
>> 
>> 1. It makes sense to have a single binding specification be “mandatory to
>> implement” (MTI).
>> 2. We should allow for the development of any number of other binding
>> specifications that the community would find useful given sufficient
>> interest.
>> 3. All of these binding specifications will be driven off of a single
>> high-level model.
>> 4. Both the high-level model and each binding specification should be
>> formalized as CTI work products.
>> 5. The python-* APIs developed by DHS/MITRE would only support the MTI
>> binding specification. Obviously, support for other bindings (or alternative
>> versions of the MTI format bindings) could be developed by others.
>> 6. We need more discussion over what the MTI format should be. There’s a lot
>> of support for JSON but we haven’t seen a lot of concrete discussion of
>> requirements and trade-offs.
>> 7. We should start the work to identify the single MTI format now in order
>> to get some informal consensus soon so that going forward we can focus our
>> efforts on improving the data model.
>> 8. All of these agreements that we reach on format in the near-term are
>> informal and if a substantive requirement is identified later in the data
>> modeling work (or even outside of that) that changes the analysis we can
>> revisit the decision.
>> 
>> There wasn't a lot of list discussion on this, but in my opinion in order to
>> ensure best compatibility among the OASIS CTI specs the MTI format should be
>> consistent across STIX, CybOX, and TAXII.
>> 
>> So my proposal is that over the next few weeks, let’s have an in-depth
>> discussion at the TC level about what the single MTI format should be. We
>> can talk about our requirements and why we prefer one or the other, discuss
>> the trade-offs of each, put together some examples, and hopefully hear from
>> some more people. Once we have rough consensus (note: not complete
>> agreement), we’ll document the entire discussion (requirements, trade-offs,
>> examples, final decision) on the wiki and move on. If the topic comes up
>> again, we refer people to the wiki. Once the time comes to formalize the MTI
>> decision (ie. we’re preparing a release of STIX, TAXII, and/or CybOX) we
>> review the analysis to see if it’s still valid against our updated
>> requirements and, if so, go with that. If not, revisit it with those new
>> improved requirements in mind.
>> 
>> As many people have said, format is not the most pressing topic we have to
>> deal with. This path will allow us to get some closure on it near-term and
>> move on to the more important work of improving the model.
>> 
>> What do you think?
>> 
>> John
>> 
>> === snipped a massive amount of previous discussion about format(s) ===



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