Alex,
Thank you for sending this out. I found the comments to be particularly helpful. Here is my attempt to boil them down into some key takeaways:
- Schema validation is a requirement for some
- Examples and/or resolution of key issues was a factor in voting
- Some voted in order to move past the MTI discussion
- Some felt the vote was premature
Thank you.
-Mark
Dear CTI,
Congratulations, we have successfully passed another ballot. As a committee we answered
Yes to the question “Do you approve the adoption of a JSON/JSON Schema-based MTI representation for TAXII 2.0, STIX 2.0 and CybOX 3.0 refactoring efforts?” with:
-
69 yes votes
-
8 no votes
-
9 abstentions
IN THE FUTURE: Every ballot from here on out will be configured show detailed results
listing the vote of each member and
will identify commenting voters by name. Please keep this in mind in the future when voting.
Since there was some confusion on this with this ballot, I have included the comments here, identifying the voters where they have indicated to me that they wish to be identified:
|
Submitter
|
Vote
|
Comment
|
|
Gurney, John-Mark
New Context Services, Inc.
|
Yes
|
This is a provisional yes vote. If the standard does not come w/ schema validation, but MTI JSON, I will vote no on the standard.
|
|
Anonymous
|
Yes
|
Schema validation is a requirement, and that any specification that does not include JSON schema validation will receive a no vote.
|
|
MacDonald, Terry
Soltra
|
Yes
|
I am voting yes to the JSON format. I am less sure about the use of JSON Schema as I'm not sure of the benefits of JSON Schema vs JSON-LD, but I do want to move ahead with some concrete progress within this SC.
|
|
Burger, Eric
Georgetown University
|
Yes
|
Kind of silly to change, but even more silly we are spending so many cycles on the argument. Just get it done by saying Yes or No.
|
|
Anonymous
|
No
|
This convinced me that this vote is premature: If JSON wins, we will let this user group know so the vendors and groups that have been waiting can start writing code.
|
|
Barnum, Sean
Mitre Corporation
|
No
|
This NO vote is based on the timing of this ballot and not on whether or not a JSON-based serialization is likely to be an appropriate choice for MTI. As has been stated before, it looks like the community is leaning strongly towards a
JSON-based MTI but there are still numerous open questions on what the requirements for an MTI serialization will be and it is premature to attempt to formalize such a decision until adequate information is available.
|
|
Algeier, Scott
National Council of ISACs (NCI)
|
No
|
I am opposed to the timing of this motion, rather than the use of JSON. I think making this decision now is premature.
|
|
Anonymous
|
No
|
My vote will change to yes when someone answers the following questions: how will JSON be validated? how will extensions be handled? how will field level marking be done? etc. Once these questions are answered, then a Yes is appropriate
(because JSON is the best answer.) But, absent having answers to these questions, a "yes" decision is premature.
|
|
Anonymous
|
Abstain
|
While there has been voices for and against XML and JSON. There haven't been completed examples/implementations of JSON (as compared to XML) that allowed for group discussion and exploration within JSON (regardless of stylistic preferences
such as pure vs LD vs other).
|
Thanks,
Alex
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.
|