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,

 

here is a little picture that captures some of the concepts contained in John's email

(I have added something I call 'translations' to the picture, because I think we may need them):

 

 

 

The questions below have been touched upon here and there in various emails on the various lists:

I feel it is important to restate them in a structured way, so that we consider them all when choosing

HLM and MTI binding:

 

 

1) What is our requirement on how the 'derive from' relation comes about?

    Do we require an automated or semi-automated
    process? We are talking about very sizable models, so a completely manual process will pose some challenges.

 

    My current feeling is that if no HLM-MTI-pair with an at least semi-automated process can be found, then the

    nature of the HLM is  documentation rather than 'ground truth' and we should think twice about spending
    effort for a HLM which we then transform by hand into a binding. Without an HLM, the MTI-binding
    would have to serve as HLM, as is the case with XSD in the pre-OASIS MITRE standards.

 

2) What is our requirement on how the MTI binding is actually defined?

    I would argue that some kind of schema definition is required and "definition by code" is not sufficient.

 

   So, with XML we have XSD. It seems there are schema-definition schemes for JSON, but I do not
   know how powerful/stable/universally-accepted these are, nor what the status regarding item 3) below is.

 

3) How much automated support for deriving an API for the MTI binding do we require?

     Obviously, we need APIs to produce/consume content in the binding(s). Especially for the MTI,

     we should think about how much automated support we require for producing an API for a given binding.

 

     Currently, MITRE's STIX/CybOX APIs are based on automated mechanisms that turn XSDs into

     Python code for parsing and generating XML conforming to the XSD. Given the size of the models
     we are contemplating, writing an API from scratch might be quite a bit of effort.

 

4) What are our requirements regarding translations between the MTI binding and alternative bindings?

 

    Without some kind of executable translation between two bindings, there is a danger that

    the standard becomes fragmented, because a system supporting  one binding may not be able
    to interpret data that is available in some other binding.

 

    Of course, this problem could be solved "by policy", stating that each OASIS-CTI-compatible system
    must support the MTI binding (thus forcing the implementors who work with an alternative binding
    to also implement a translation fromt/to the MTI), but the danger remains that we suddenly
    have systems that exclusively speak an alternative binding. So maybe there should be a requirement
    that an "official" alternative binding must be supported by a reference implementation that translates from/to

    that binding into the MTI binding?

 

 

 



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