[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-taxii] TAXII Architecture
One key difference between OASIS specs and other specs (e.g., IETF) is that we can have multiple conformance clauses. In one document we could have a conformance clause for a “TAXII Repo” and another conformance clause for a “TAXII Broker”.
There is a lot of flexibility in how we define these things relate to each other (different conformance clauses, different work products, etc). Personally, and I suspect this is an underlying factor in the discussion, I think that Broker and Repository
in all likelihood would be implemented as entirely different software systems that may or may not be packaged into the same product.
I view the attempt to say “MUST implement both” as a test. I think it would be better for interoperability and make writing TAXII Clients easier if there was only one type of software that could be a “TAXII Server”. The test is whether this forces untenable
requirements onto server implementers (i.e., you must get great gas mileage AND be able to tow 10,000 lbs).
So far I’m hearing plenty of arguments for optionality (an OR instead of an AND). I can be on board with “OR" as long as there is a reasonable solution for interoperability. Assuming we went with an “OR”, how would a TAXII Client detect what type of server
it was interacting with, and how would users of TAXII Clients determine which pieces fit together? We should avoid the scenario where an end-user attempts to plug a TAXII Broker Client into a TAXII Repo Server and doesn’t understand why they don’t work together
Thank you.
-Mark
From: <cti-taxii@lists.oasis-open.org>, Eric Burger <ewb25@georgetown.edu> on behalf of Eric Burger <Eric.Burger@georgetown.edu>
Date: Wednesday, December 16, 2015 at 10:58 AM To: "cti-taxii@lists.oasis-open.org" <cti-taxii@lists.oasis-open.org> Subject: Re: [cti-taxii] TAXII Architecture
I think we are in violent agreement. This is why I posited we do not say “MUST be a repository.” However, we do need to have a minimal set of useful features, of which the repository set is a reasonable place to be.
I also think there should not be that much beyond what a repository would want to be a broker. If there is, then we are most likely talking two different protocols.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]