OASIS Cyber Threat Intelligence (CTI) TC

Some other places content-range units other than bytes are in use: New IETF proposal for bytes-live range unit:   https://tools.ietf.org/html/draft-pratt-httpbis-bytes-live-range-unit-01 Postgresql web client using "items": https://postgrest.readthedocs.io/en/stable/admin.html Angular example using "customers": https://billdelude.com/2014/08/18/paging-with-range-headers-using-angularjs-and-web-api-2-part-1/ etc etc... I can Google up many of these.. - Jason Keirstead STSM, 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 __________________ You are making false assumptions here - You are making the assumption that registering the unit with IANA is required. It is not, registering the unit with IANA is optional, as per the RFC. - You are making the assumption that proxies do not deal with this properly. I can assure you, they already deal with it just fine (as they should, otherwise they would be violating the RFC) Content-Range units other than "bytes" are in use in the wild throughout the web. We use them in our own product ("items"), and it's also a core facet of Dojo and other libraries used everywhere on the web (Dojo is used on at minimum tens of thousandands of public websites**). It is not uncommon at all. **reference: https://trends.builtwith.com/_javascript_/Dojo-Toolkit - Jason Keirstead STSM, 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 From:         Alexandre Dulaunoy <Alexandre.Dulaunoy@circl.lu> To:         Bret Jordan <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> Date:         03/14/2017 05:57 AM Subject:         Re: [cti] On current TAXII discussions Sent by:         <cti@lists.oasis-open.org> On 13/03/17 18:09, Bret Jordan wrote: > Alexandre, > > > How then do you paginate STIX objects if not by objects?  You can not really do it by bytes.  Breaking JSON objects up by bytes is a disaster waiting to happen. Yes, the clean way to do it IMHO is to use a MANIFEST or an INDEX file instead of relying on the transport mechanism's underlying systems to do the parsing JSON objects and alike. I think that this is cleaner and makes the real separation between transport and format clean. Asking for IANA to implement a new unit registry is extremely far fetched, especially is we consider the possible compatibility issues with HTTP proxies. We know that our weight on the overall discussion is low but our objective was always to keep the things as simple as possible. Cheers -- Alexandre Dulaunoy CIRCL - Computer Incident Response Center Luxembourg 41, avenue de la gare L-1611 Luxembourg info@circl.lu - www.circl.lu --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Two weeks ago, I would have told you we were ready to move the TAXII 2.0 draft into a hopefully final RC, and then onto a CSD vote. Today, I am not really sure where we stand.

 
Clearly there is a small and vocal group advocating for JSON API. My personal assessment is that moving to JSON API would require rewriting 50%-75% of the existing specification, and add
another 6-12 months onto our timeline. We should always strive for correctness; if the group’s desire is to undertake a transition to JSON API, then we should and we will. That said, I’ve not seen JSON API support beyond a few vocal people. Is there broader
support that I am missing?
 
The current TAXII 2.0 document represents many calendar months and many more countless hours of effort, conversation, and compromise by the CTI TC. This includes invaluable feedback from
the group that is currently advocating for JSON API (notably, filtering and pagination). For these reasons, I think the current draft must be viewed as the incumbent in any discussion. Specifically, changes must be proposed and justified relative to the current
draft. JSON API is a large change, and therefore has a high bar for justification (in my opinion).
 
I believe Bret is correct to try and distill the JSON API proposal into its constituent points, and systematically look for improvements that can be made to the current TAXII 2.0 draft.
We know we aren’t perfect, and we never will be. JSON API is not perfect either.

 
Summarizing, I believe this to be the current state:
·         
A group is proposing a JSON API-based specification as an alternate to the existing TAXII 2.0 draft
·         
This is the largest change that can possibly be proposed, and therefore needs significant justification and significant support from the community
·         
I personally have not seen enough to sway my opinion that JSON API is better (though I do believe it’s roughly equivalent)
·         
I personally have not seen significant community support, though there is some
·         
I feel that we could get great benefit, and far less cost, by systematically comparing the two proposals and looking for improvements to be made in the TAXII 2.0 draft, as Bret
has been doing.
 
Thank you.
-Mark
 

Disclaimer: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify
the sender and destroy and delete any copies you may have received.

Mark,
 
Wholeheartedly agree and we (EclecticIQ and the community) are most grateful for those that have the time to do so. Actually, I believe we’ve already learned
some things by comparison. Although I sincerely wish our company would have to time to do so, I’m afraid we don’t at this stage – for which our apologies.

 
Let me make one thing super ultra clear though. No matter what, EclecticIQ supports STIX and TAXII. OpenTAXII will support whatever standard ends up being voted
through. Our products will continue to support, our marketing will continue to invest. We’re are huge fans of the standards and those that contribute and nothing will change that. Our suggestions have in no way baring on that.
 
Mark you’re approach makes allot of sense if the constraints of time and resources don’t make JSON-API a viable option. We would much appreciate if people cycles
to analyse some of our team’s comments and compare the two standards to improve RC1.
 
That doesn’t mean our point of view changes. We need to passionately ensure separation of layers and I perceive risk in the unknown and the untested and I would
love to inspire the community – perhaps then for future efforts – to build upon more proven things so our cycles can be spend on the magic we want to do for CTI. Again, we’re most grateful of those that have the operational cycles to ensure and act accordingly.
 
Best regards,
Joep
 
 
 
 

 

From:
<cti@lists.oasis-open.org> on behalf of Mark Davidson <Mark.Davidson@nc4.com>
Date: Tuesday, 14 March 2017 at 13:52
To: Jason Keirstead <Jason.Keirstead@ca.ibm.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Alexandre Dulaunoy <Alexandre.Dulaunoy@circl.lu>
Cc: Bret Jordan <Bret_Jordan@symantec.com>
Subject: Re: [cti] On current TAXII discussions


 

Two weeks ago, I would have told you we were ready to move the TAXII 2.0 draft into a hopefully final RC, and then onto a CSD vote. Today, I am not really sure where we stand.

 
Clearly there is a small and vocal group advocating for JSON API. My personal assessment is that moving to JSON API would require rewriting 50%-75% of the existing specification, and add
another 6-12 months onto our timeline. We should always strive for correctness; if the group’s desire is to undertake a transition to JSON API, then we should and we will. That said, I’ve not seen JSON API support beyond a few vocal people. Is there broader
support that I am missing?
 
The current TAXII 2.0 document represents many calendar months and many more countless hours of effort, conversation, and compromise by the CTI TC. This includes invaluable feedback from
the group that is currently advocating for JSON API (notably, filtering and pagination). For these reasons, I think the current draft must be viewed as the incumbent in any discussion. Specifically, changes must be proposed and justified relative to the current
draft. JSON API is a large change, and therefore has a high bar for justification (in my opinion).
 
I believe Bret is correct to try and distill the JSON API proposal into its constituent points, and systematically look for improvements that can be made to the current TAXII 2.0 draft.
We know we aren’t perfect, and we never will be. JSON API is not perfect either.

 
Summarizing, I believe this to be the current state:
·         
A group is proposing a JSON API-based specification as an alternate to the existing TAXII 2.0 draft
·         
This is the largest change that can possibly be proposed, and therefore needs significant justification and significant support from the community
·         
I personally have not seen enough to sway my opinion that JSON API is better (though I do believe it’s roughly equivalent)
·         
I personally have not seen significant community support, though there is some
·         
I feel that we could get great benefit, and far less cost, by systematically comparing the two proposals and looking for improvements to be made in the TAXII 2.0 draft, as Bret
has been doing.
 
Thank you.
-Mark
 
Disclaimer: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you
are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in
error, please notify the sender and destroy and delete any copies you may have received.