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-stix] MTI Binding


I’ll defer to OASIS for the official word, but by my reading of the TC Process, these are not binding decisions.  I am operating under the assumption that we will come to “binding” decisions when we take full votes on Standards Track Work Products (specification draft, candidate standard, etc.)  I would imagine those decisions could be reversed in a future work product if we so decided.

The process to call for a vote and reach a decision is covered by the TC Process: https://www.oasis-open.org/policies-guidelines/tc-process#voting

 

Motions may be suggested by a voting member, and must be seconded.  However, motions from the list must be discussed before they can be voted on.  Motions for the entire committee should be made to the [cti] list.

 

To those of you who feel that this debate is moving too quickly, or we are making decisions too quickly – you are empowered to make an alternate motion according to Robert’s Rules of Order.

 

Given that this is our first “contentious” debate, we may need some additional clarity on the period of discussion.  Robert’s Rules suggest that a motion to Limit or Extend Debate requires a 2/3 vote, but these rules do not provide the best clarity when it comes to discussion lists that have no ending.  I believe this is one of the reasons that votes are required to have a minimum period of 7 days, but perhaps I’m just not finding where in our TC Process we have set the minimum period of debate.

 

Thanks,

 

Alex

 

From: cti@lists.oasis-open.org [mailto:cti@lists.oasis-open.org] On Behalf Of Wunder, John A.
Sent: Tuesday, October 06, 2015 2:11 PM
To: cti@lists.oasis-open.org; cti-stix@lists.oasis-open.org
Subject: [cti] Re: [cti-stix] MTI Binding

 

What do these motions mean, are they binding (in the sense that it’s difficult/impossible to change our mind later)? What’s the process to reach a decision on them? To what extent is that decision binding?

 

I agree with these statements but don’t think we’re ready for binding decisions on either of them (in particular the second). I do think it would be nice to have a non-binding decision (in the sense that we can easily change our minds later) in order to cut off conversation on the topics until we revisit those decisions when formalizing the specifications.

 

(I moved this to the CTI TC list because it seems inappropriate on the users list. If I’m wrong we can move it back)

 

John

 

On Oct 6, 2015, at 12:49 PM, Jordan, Bret <bret.jordan@BLUECOAT.COM> wrote:

 

Sounds good...

 

I would like to formally make a motion that we require a default binding for STIX 2.0 and CybOX 3.0.  

 

 

If this is agreed upon, then:

 

I would like to formally make a motion that the default binding for STIX 2.0 and CybOX 3.0 be JSON.

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

 

On Oct 6, 2015, at 10:40, Aharon Chernin <achernin@soltra.com> wrote:

 

Bret, I think we need to propose that STIX, CybOX, and TAXII have to require a default binding type first. Then the MTI motion could be changed to something like, “I would like to propose that we adopt JSON as the default binding”.

 

Aharon

 

From: <cti-stix@lists.oasis-open.org> on behalf of "Jordan, Bret"
Date: Tuesday, October 6, 2015 at 11:45 AM
To: "cti-users@lists.oasis-open.org", "cti-stix@lists.oasis-open.org"
Subject: [cti-stix] MTI Binding

 

We have had a good discussion here and on the wiki and I have seen a lot of people advocating for JSON to be used as the MTI.  While a few other options have been tossed around and discussed they do not seem to have an advocate pushing for them nor do they seem to have the broad support that JSON does.  

 

Therefore, I would like to formally propose that we adopt JSON as the MTI for STIX 2.0 and CybOX 3.0.

 

 

Thanks,

 

Bret

 

 

 

Bret Jordan CISSP

Director of Security Architecture and Standards | Office of the CTO

Blue Coat Systems

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." 

 

On Oct 6, 2015, at 06:17, Davidson II, Mark S <mdavidson@MITRE.ORG> wrote:

 

I think we’re wrapped around the axle a little bit on this whole topic. I’d like to try and step back and ask some basic questions:

 

1. Is anyone actually proposing JSON-LD as the MTI for STIX? I’ve seen the question asked, and I’ve seen lots of discussion. Is there somebody who would like to come forward and state their opinion that JSON-LD should be the MTI for STIX?

Note: I see this question as a higher bar than asking who thinks we should consider it – IMO the recent discussion makes it clear that we are considering it


2. There was an opinion that the proposed examples (the indicator and incident idioms) wouldn’t be sufficient for comparing size and complexity. What examples would be sufficient?


3. What toolchain is required to develop software that supports using a model without any custom code? Maybe I’m missing something, but if I have a product and I want to add STIX support, won’t developers have to write code? 

I guess at its core – I hear what people are saying about models and not programming to the data syntax, I just don’t understand how that actually works (the more concrete the example the better, at least for me).

 

Thank you.

-Mark

 

 

 

 


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.


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