Ballot Details: Approve requesting a Special Majority Vote for TAXII 2.1 (CLOSED)

Ballot Question Do you approve the CTI/TAXII SC Chair(s) requesting that TC Administration hold a Special Majority Ballot to approve TAXII 2.1 WD10 / CSD04 as a Committee Specification?
Ballot Description This ballot is to approve the motion made by Bret Jordan on 08 January 2020 in https://lists.oasis-open.org/archives/cti/202001/msg00005.html and seconded by Justin Stewart in https://lists.oasis-open.org/archives/cti/202001/msg00006.html. If this motion passes, the chairs will request OASIS TC Administration start a Special Majority Vote for the TC to vote on this question.

Per the OASIS Committee Operations Process (https://www.oasis-open.org/policies-guidelines/oasis-committee-operations-process-2018-05-22#voting), this ballot requires a Simple Majority Vote. Simple Majority Vote is defined in https://www.oasis-open.org/policies-guidelines/oasis-defined-terms-2018-05-22#dSimpleMajority

TC Admin is opening this ballot on behalf of the TC Chairs/Secretary who are currently unavailable.
Ballot Options
VOTING CLOSED: Friday, 17 January 2020 @ 11:59 pm UTC
Yes 35 76.087
No 11 23.913
Abstain 2
Open Date Friday, 10 January 2020 @ 12:00 pm UTC
Close Date Friday, 17 January 2020 @ 11:59 pm UTC
Ballot Type Official, as defined by organization policies and procedures

Voting Statistics

Number of votes cast (excluding abstentions) 46
Eligible members who have voted 48 of 56 85.714%
Eligible members who have not voted 8 of 56 14.286%

Voting Summary by Option

Options with highest number of votes are bold
Option # Votes % of Total
Yes 35 76.087%
No 11 23.913%
Abstain 2

Voting Details

Voter Name Company Vote * Time (UTC) Comments
* Butt, Michael NC4 Yes 2020-01-14 15:36:00
* Caselli, Marco Siemens AG Yes 2020-01-13 15:55:00
* Coderre, Robert Accenture Yes 2020-01-17 02:45:00
* Darley, Trey CCB/CERT.be Yes 2020-01-17 09:45:00
* Davidson, Mark NC4 Yes 2020-01-15 12:25:00
* Ginn, Jane Cyber Threat Intelligence Network, Inc. (C... Yes 2020-01-16 18:19:00
* Girard, David Trend Micro Yes 2020-01-13 16:00:00
* Hunt, Christian New Context Services, Inc. Yes 2020-01-14 18:15:00
* Jordan, Bret Broadcom Yes 2020-01-10 23:00:00
* Keirstead, Jason IBM Yes 2020-01-13 13:11:00
* Keith, Robert Symantec Corp. Yes 2020-01-10 20:41:00
* Lenk, Chris Mitre Corporation Yes 2020-01-16 17:20:00
* MacDonald, Terry Individual Yes 2020-01-17 02:30:00 1
* Masuoka, Ryusuke Fujitsu Limited Yes 2020-01-17 09:22:00 1
* Maxwell, Kyle Accenture Yes 2020-01-16 16:54:00
* Merchant, Aubrey Broadcom Yes 2020-01-15 22:33:00
* Morris, John IBM Yes 2020-01-13 19:39:00
* Noguchi, Kazuo Hitachi, Ltd. Yes 2020-01-16 16:46:00
* Patrick, Paul FireEye, Inc. Yes 2020-01-17 13:58:00
* Piazza, Richard Mitre Corporation Yes 2020-01-15 19:30:00
* Radhakrishnan, Ashwin Anomali Yes 2020-01-17 00:27:00
* Ratliff, Emily IBM Yes 2020-01-13 14:39:00
* Ricard, Chris Financial Services Information Sharing and... Yes 2020-01-16 16:06:00
* Riedel, Daniel New Context Services, Inc. Yes 2020-01-16 16:55:00
* Satomi, Toshitaka Fujitsu Limited Yes 2020-01-17 05:50:00
* Serban, Vlad LookingGlass Yes 2020-01-16 21:55:00
* Stewart, Justin LookingGlass Yes 2020-01-13 16:54:00
* Storms, Andrew New Context Services, Inc. Yes 2020-01-10 23:51:00
* Struse, Richard Mitre Corporation Yes 2020-01-17 00:52:00
* Takami, Yutaka Hitachi, Ltd. Yes 2020-01-17 05:17:00
* Thompson, Dean Australia and New Zealand Banking Group (A... Yes 2020-01-12 23:25:00
* Thomson, Allan LookingGlass Yes 2020-01-10 21:53:00
* Varner, Drew NineFX, Inc. Yes 2020-01-10 23:02:00
* Yamada, Koji Fujitsu Limited Yes 2020-01-17 07:55:00
* Yoshimura, Kunihiko Fujitsu Limited Yes 2020-01-17 07:41:00
* Casey, Tim Intel Corporation No 2020-01-13 22:31:00
* Hohimer, Ryan DarkLight, Inc. No 2020-01-13 18:34:00
* Jones, Elysa Individual No 2020-01-13 23:49:00
* Joyce, Ryan DarkLight, Inc. No 2020-01-14 21:54:00
* Kirillov, Ivan Mitre Corporation No 2020-01-17 14:30:00
* Park, Jackie Eun DHS Office of Cybersecurity and Communicat... No 2020-01-16 16:55:00
* Pumo, Beth Kaiser Permanente No 2020-01-15 14:51:00
* Riley, Shawn DarkLight, Inc. No 2020-01-13 17:38:00
* Roberts, Ian DarkLight, Inc. No 2020-01-13 19:33:00
* Taylor, Marlon DHS Office of Cybersecurity and Communicat... No 2020-01-13 16:34:00 1
* Vargas-Gonzalez, Emmanuelle Mitre Corporation No 2020-01-16 15:46:00 1
* Mates, Jeffrey US Department of Defense (DoD) Abstain 2020-01-16 18:44:00 1
* O'Brien, Christopher EclecticIQ Abstain 2020-01-16 08:20:00 1
* Dye, Daniel NC4 --
* Gurney, John-Mark New Context Services, Inc. --
* Hostetler, Dennis LookingGlass --
* Kakumaru, Takahiro NEC Corporation --
* Kostrosky, Curtis Symantec Corp. --
* Pandya, Shyamal FireEye, Inc. --
* van Belkum, Aukjan EclecticIQ --
* Williams, Ron IBM --

Voter Comments

Submitter Vote Comment
MacDonald, Terry
Individual		 Yes My vote for yes is predicated on a statement by Bret Jordan that he expects we will focus on TAXII Query in TAXII 2.2.
Masuoka, Ryusuke
Fujitsu Limited		 Yes My vote is yes. I understand that we have discussed TAXII 2.1 for a long time including filtering and that it is about time to release it or we lose the market buy-in. However, I would like best ways shown/discussed for those who need filtering capability very soon under TAXII 2.1 without filtering. I would also like to see and help realization of the next TAXII (2.1.1 or 2.2?) with filtering as soon as possible.
Vargas-Gonzalez, Emmanuelle
Mitre Corporation		 No TAXII Filtering/Querying has longstanding GitHub tracked issues going back to 2017 that have remained unattended all this time. As an individual that has taken the time to propose ideas on this matter it is hard to determine if we can call this specification “ready” and the consequences of publishing this document without addressing such important capability for organizations.

While this ballot is only requesting that we should move into a Special Majority Ballot I believe it is important to document and make sure this issue gets addressed in the future. The TC members should at least consider a partial solution that solves some of the longstanding issues if a full and potentially backwards-breaking solution is desired and/or in the plans for a TAXII 2.2 release.

While on prior TC calls ideas like having a separate “TAXII Query” document to fulfill this requirement are not bad. Having the issue be solved directly on the spec can ensure interoperability and better implementation support across organizations. Therefore, my perception is that something should be done on the TAXII 2.1 to at least fulfill some of the concerns brought up by the community.
Taylor, Marlon
DHS Office of Cybersecurity and Communicat...		 No There is a standing proposal submitted to the TC that would only require a small change to the “3.4.1 Supported Fields for Match Table” that will address several issues identified by the community (private sector, government, international).

Some of the additional filtering capabilities achievable from the provided proposals which have been requested by the community include but are not limited to:
• Relationship pivoting (e.g. what are all relationships to a Campaign_X?)
• Filtering upon specific information if an ID is not known (e.g. what is shared about 1.2.3.4?)
• Filtering on TLP Markings (e.g. what TLP:AMBER data is available?)
• Filtering on confidence values (e.g. what CTI has a high confidence value?)
• Identify sighted data (e.g. what are all the sightings for Indicator_Y?)

Releasing TAXII 2.1 without addressing this gap will negatively reflect the priorities and focus of the TC to those whom have requested and anticipated this change for so long but could be addressed within TAXII 2.1 with a small change submitted to the TC for review.
Mates, Jeffrey
US Department of Defense (DoD)		 Abstain While we agree that querying is important no consensus has been reached about what query options should be supported, and some of the proposed query options have serious architectural implications for TAXII server designs. As such we must abstain.
O'Brien, Christopher
EclecticIQ		 Abstain When we discussed the absent filtering/querying capability in the current working draft of TAXII on one of the TC calls last year I was asked my opinion directly and made it clear that I did not have an opinion on the topic one way or the other. The reason is quite simple: The lack of filtering/querying in TAXII has been a long standing issue and, as a result, I and those I collaborate with on projects concerning stix querying have been looking for other ways to service that requirement. On reflection - that's bad for the TAXII standard.

I do not essentially disagree that the spec is 'ready' nor do I believe we have not clearly discussed viable alternatives (such as a supplementary 'TAXII Query' spec to release in parallel). We have discussed that and it makes sense. However, I believe Marlon's point is well made that to move forward with that approach suggests that TAXII Query (to group this functionality in a single phrase) is less of a priority and that that could reflect badly for implementers who believe query functionality to be important.

I am choosing to abstain from this particular vote as I have no strong opinion either way as to whether we should move to Special Majority Ballot - simply that when/if we do move to Special Majority Ballot that I would be very keen to see Marlon's points specifically addressed in the future plan for the spec to ensure that this very important feature set of TAXII Query.