We need to look at ways of reducing the amount of data transferred by reviewing all levels of the TAXII/STIX/CybOX stack. Everything needs to be investigated and improved:
- Choosing a message format that is as small as possible
- Only sending changes to objects rather than the full objects
- Only sending the bits of the objects the consumer wants
- Compressing
- Reducing the number of client-server negotiation steps before data flows
- Reduce the amount of discovery required
- Reuse connections (multiplexing)
- Make better use of nearer sources of data rather than sources further away (locality/latency)
- and anything else we can think of....
They should all be discussed, investigated and adopted/discounted to make the next versions of TAXII/STIX/CybOX efficient and effective enough to last for an extended duration. This will in turn make it more beneficial for vendors to invest resources in supporting a nice stable protocol, and consumers get a lovely dollop of compatibility and integration.
Cheers
Terry MacDonald | STIX, TAXII, CybOX Consultant
Disclaimer: The opinions expressed within this email do not represent the sentiment of any other party except my own. My views do not necessarily reflect those of my employers.
On 31 July 2015 at 04:28, Dr. Eric Burger <eric.burger@georgetown.edu> wrote:
I think STIX messages are bounded. As in not streaming. Meaning we can use compression at the transport level if the number of bits gets to be too much.
Sent from my mobile device. Thanks be to LEMONADE: http://www.standardstrack.com/ietf/lemonade
S2ERC: http://s2erc.georgetown.edu/
GCSC: http://gcsc.georgetown.edu/
Me: http://www.cs.georgetown.edu/~ eburger