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]


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]