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