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.
VOTING CLOSED: Friday, 17 January 2020 @ 11:59 pm UTC
|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|
|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%|
|Options with highest number of votes are bold|
|Option||# Votes||% of Total|
|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|
|Gurney, John-Mark||New Context Services, Inc.||--|
|Kakumaru, Takahiro||NEC Corporation||--|
|Kostrosky, Curtis||Symantec Corp.||--|
|Pandya, Shyamal||FireEye, Inc.||--|
|van Belkum, Aukjan||EclecticIQ||--|
|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.
|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.
|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.
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 220.127.116.11?)
• 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.
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.
|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.