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


@Cory,
Thank you much for engaging.  We appreciate your efforts to introduce us to MDA (Model Driven Architecture) and real world application of same to "our thing".

@All,
Hopefully it is clear that at the end of the day we all have identical objectives.  I hope that we can all be open minded to consideration and evaluation to new approaches to achieving same.

Sent from Outlook




On Wed, Sep 2, 2015 at 8:11 AM -0700, "Bush, Jonathan" <jbush@dtcc.com> wrote:

This is a very good comparison to the telcom industry.  Couldn’t agree more.

 

From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Jason Keirstead
Sent: Wednesday, September 02, 2015 10:50 AM
To: Michael Hammer
Cc: bret.jordan@bluecoat.com; cory-c@modeldriven.com; cti@lists.oasis-open.org
Subject: RE: [cti] Thoughts on STIX and some of the other threads on this list

 

Totally agree with this - and it's what I was trying to say, in a different form, I suppose.

Stage 3 (the protocol and format) is vital and is the end game. I do not see the UML being the source of truth (Stage 2), the source of truth is Stage 3.

For the record - I am not saying this decision needs to be made right now - in fact I kind of view this thread as a distraction from many much more important issues that lie at the core of STIX (the broken TLP mechanism, the inherent ties to CybOX, the much discussed use of references and IDs vs. raw data). Like Michael says we have to make decisions at Stage 1 and Stage 2 first and move to Stage 3 later. But I think it is important that the goal of Stage 3 is not just a model, it is a data format.

In reply to Cory - / That JSON can and should be “tuned” to the style and constraints that the JSON experts specify. / - If we make a model, but then have to manually manipulate that model to create a protocol, and that protocol format is the only one we support as a standard - then I am not sure what the purpose was of making the model - because the model is certainly not the source of truth if it requires manual massaging to logically fit into the final standard format. " Technologies will change, plan for it." - Of course they do, but robust data formats don't. We can't just swap out the implementation of a standard in 2-3 years because UML makes it technically simple to do and whatever format was chosen today is not en-vogue anymore - that wont be an option. This is exactly why the decision of a data format is important, because this data format decision has to hold true for 10, 15, 20 years or hopefully longer.


-
Jason Keirstead
Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


Inactive hide details for Michael Hammer ---2015/09/02 11:28:50 AM---All,Michael Hammer ---2015/09/02 11:28:50 AM---All,

From: Michael Hammer <michael.hammer@yaanatech.com>
To: "cory-c@modeldriven.com" <cory-c@modeldriven.com>, Jason Keirstead/CanEast/IBM@IBMCA, "bret.jordan@bluecoat.com" <bret.jordan@bluecoat.com>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Date: 2015/09/02 11:28 AM
Subject: RE: [cti] Thoughts on STIX and some of the other threads on this list





All,

Let me throw a thought in from left field.
Warning:  this is coming from the telecom versus computer space, so may seem foreign.

I think the gist of the previous comments were along the lines of:

- Get the semantics right first
- Then get the syntax sorted out.


In traditional telecom standards, there is a thing called the 3 Stage process.
Stage 1 treats the system as a black box and asks:  what do you want the system to do for the end user?
Stage 2 looks at message flows *independent of protocol choice or syntax*.
Stage 3 translates the message flows into a specific protocol, be it ASN.1, XML, JSON, or whatever.
(In some cases, they provide 2 representations)

Typically, during Stage 2, the list of elements are defined in terms of a name, meaning, and other characteristics, such as mandatory, conditional, or optional.  Nowhere in those discussions do they address syntax.

What I was hearing indirectly was get Stage 2 (semantics) defined first, and then address Stage 3 (syntax) as a follow-on.
That does not mean that both can’t be done in parallel, just that any change in Stage 2 must flow to Stage 3.

That has worked well for many years, so don’t know why it couldn’t work here as well.
Ultimately, you do want to communicate something from point A to B.

________________________________
Michael Hammer
Principal Engineer
michael.hammer@yaanatech.com
Mobile: +1 408 202 9291
542 Gibraltar Drive
Milpitas, CA 95035 USA
www.yaanatech.com

From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Cory Casanave
Sent:
Wednesday, September 02, 2015 10:03 AM
To:
Jason Keirstead <Jason.Keirstead@ca.ibm.com>; Jordan, Bret <bret.jordan@bluecoat.com>
Cc:
cti@lists.oasis-open.org
Subject:
RE: [cti] Thoughts on STIX and some of the other threads on this list


Jason and Brett,

I absolutely agree that we must achieve a standard that is understandable and as easy as possible to implement and that data formats are very important. Nothing I suggested is in conflict with these goals.

If JSON is your chosen format then the schema is all you need look at and is normative. That JSON can and should be “tuned” to the style and constraints that the JSON experts specify. One way we achieve this is to take the a subset representative model. We then ask an JSON expert to hand code a small piece of schema that shows the style and form desired. We then ask the “MDA Expert” to develop the production rules that match that form and generate the entire model. The JSON experts inspects it and after 2-3 iterations we have matched the experts style – it looks just like what would have been produced by hand.

Do the same thing for an API and we have a full and consistent API for the information. I used the Python API late last year and found it much easier – but it was a bit hard to trace the relationship between the API and the XML, and the API did not seem complete. A generated API could provide the same level of interfaces, fully consistent and complete and able to interface with any of the normative data formats. This makes it easier, not harder. This is not “ivory tower”, it is based on well-established and standards based technologies and approach.

The model can be the “single source of the truth” while keeping the data format(s) the normative way(s) to exchange data. Technologies will change, plan for it.

<trimmed>


DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses.  The company accepts no liability for any damage caused by any virus transmitted by this email.


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