[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti] OASIS CTI-wide resolution on the MTI serialization
As the reigning, official, academic on the list… Just PICK ONE. JSON is just as evil as XML, so we might as well trade our angle brackets for curly brackets. Consider the deck chairs re-arranged. Do vote: https://www.oasis-open.org/apps/org/workgroup/cti/ballot.php?id=2889 For the record (it’s in the record), I voted Yes. > On Nov 20, 2015, at 2:39 PM, Wade Baker <wbaker@threatconnect.com> wrote: > > I will gladly +1 this resolution. > > -- > Wade Baker > ThreatConnect > +1 571.205.8239 > > On Nov 20, 2015, 10:32 AM -0500, Trey Darley <trey@soltra.com>, wrote: >> Hi, everybody - >> >> I'm sure you are well aware of the seemingly endless MTI serialization >> MTI debate (aka, JSON versus XML). Historically, standardization >> efforts following the "rough consensus and running code" model have >> been successful. Standardization efforts following the "endless >> academic debate within committee" model have not fared so well. Rough >> consensus and running code have gotten us to where we're at today and >> it is that same model which will ultimately win the day. >> >> There is a vocal minority within the CTI community who present a >> chicken and egg scenario where we have to fix the model in stone >> before we can decide on the MTI serialization yet no tangible progress >> can be made on the model without a serialization in which technical >> people can express their ideas in running code. It is time to cut that >> Gordian Knot. As one of the co-chairs succintly put it yesterday, "One >> fact, if we do not gain adoption greater than 18-20% of the market in >> the next year or so, this standard will fade away in to obscurity, >> regardless of how neat and perfect the model is. The model is >> important, but not the most important. Adoption is the most important >> criteria." >> >> The TAXII SC has made phenomenal progress towards defining TAXII 2.0 >> and may in fact have draft work product by the end of this year. The >> CybOX SC, while not quite as far along as the TAXII folks, is moving >> rapidly towards a CybOX 3.0 draft spec. What do these SCs have in >> common? They're not merely debating use cases in theoretical terms, >> but simultaneously working through the actual issues on a technical >> level using JSON notation. >> >> Accordingly, the co-chairs are moving to close this debate so that we >> can concentrate our efforts on addressing critical issues within the >> STIX/CybOX models themselves. >> >> This is in no way to discount the need to translate the refactoring >> efforts into UML models for the final OASIS draft specifications. UML >> modelling is putting the icing on the cake. Now is the time to >> actually *bake* the cake. >> >> Likewise, the co-chairs recognize that there will be communities of >> interest requiring alternative serialization formats (XML, protobufs, >> JSON-LD, OWL, etc). The OASIS TC has a role to play in helping to >> standardize these alternative representations to ensure >> interoperabilitity. However, that work effort lies in the future. >> First we must complete the task at hand. >> >> >> Supporters of the resolution: >> * Aharon Chernin (Soltra) >> * Alexander Foley (Bank of America) >> * Bernd Grobauer (Siemens) >> * Bret Jordon (Blue Coat) >> * David Eilken (Soltra) >> * Ivan Kirillov (MITRE) >> * Jason Keirstead (IBM) >> * Joep Gommers (EclecticIQ) >> * John Anderson (Soltra) >> * John Wunder (MITRE) >> * Jon Baker (MITRE) >> * Jonathan Bush (Soltra) >> * Mark Davidson (MITRE) >> * Richard Struse (DHS) >> * Sergey Polzunov (EclecticIQ) >> * Trey Darley (Soltra) >> >> And with that, I present to you the formal resolution text as agreed >> upon by the co-chairs and hereby motion to put the proposal to a >> formal TC-wide vote. Can I get a second to the motion? >> >> <snip >> Resolved: >> ========= >> The CTI community will embrace a JSON/JSON Schema-based MTI >> representation for the TAXII 2.0, STIX 2.0, and CybOX 3.0 refactoring >> efforts. >> >> Elaboration: >> ============ >> By adopting an MTI representation, we are explicitly requiring any >> vendor or software product claiming CTI-compatibility to minimally >> support the JSON serialization. Vendors are free to define and support >> additional serializations (XML, protobufs, etc.) to address their >> specific use cases, but if they do not support the MTI serialization, >> their products are not CTI-interoperable and they cannot claim to >> support the CTI standards. >> >> The committee chairs recognize the need for additional optional >> serialization formats, either now or in the future. The committee >> chairs are prepared to support standardizing alternative serialization >> formats for interoperability purposes in collaboration with the >> interested parties but until the TC has approved the STIX 2.0, TAXII >> 3.0 and CybOX 3.0 specifications we as a community do not have the >> bandwidth to support this effort. >> >> Regardless of what alternative serialization formats may be defined >> and standardized in the future, the JSON MTI will remain the "must be >> this tall to ride" in terms of CTI standards compliance. >> </snip >> >> -- >> Cheers, >> Trey >> -- >> Trey Darley >> Senior Security Engineer >> 4DAA 0A88 34BC 27C9 FD2B A97E D3C6 5C74 0FB7 E430 >> Soltra | An FS-ISAC & DTCC Company >> www.soltra.com >> -- >> "It is easier to move a problem around (for example, by moving the >> problem to a different part of the overall network architecture) than >> it is to solve it." --RFC 1925
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]