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] OASIS CTI-wide resolution on the MTI serialization


I second it.

Thanks for putting this together, Trey!

> On Nov 20, 2015, at 10:32 AM, 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



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