I am fine with that (since this is what I am doing behind the scenes anyways), but this would need to be taken to a ballot just like we did for STIX. It would need to be binding, not just a casual agreement.
What I am doing right now is making sure every feature that gets added to TAXII is actually implemented in my libraries and test server (at some level). I am doing this to help prevent the problems we had with TAXII
2.0, where 20 minutes in to coding we realized that, that design does not work in code. Some of the issues we have resolved in TAXII 2.1 have come about because of this code work that I and others have done and the plugfests we have held. I am a firm believer
in "working code" and easy to implement in code. I think those are two of the pillars to adoption.
One of the differences we have in TAXII versus STIX though is, TAXII does not have features that are just conceptual models. STIX on the other hand can just be "modeled" and not implemented. This is why it was so important
to have the "written in code" clause for STIX.
Bret
From: <> on behalf of Allan Thomson <>
Sent: Tuesday, November 27, 2018 2:26:44 PM
To: Wunder, John A.; Jason Keirstead; Kelley, Sarah E.
Cc:
Subject: [EXT] Re: [cti] TAXII definition of "Done"
+1 to TAXII features starting to require the same level of doneness as STIX changes.
Allan
From:
"" <> on behalf of "Wunder, John" <>
Date: Tuesday, November 27, 2018 at 1:21 PM
To: Jason Keirstead <>, "Kelley, Sarah E." <>
Cc: "" <>
Subject: Re: [cti] TAXII definition of "Done"
Agreed, the same motivation for wanting to do this for STIX applies to TAXII. I’d also keep in mind that requiring sponsors and interop text makes it so that you’re not just evaluating technical feasibility (the implementation piece),
you’re also ensuring that there’s defined use cases and a real scenario where it can be used (a concern discussed on the call). It’s way easier to say yes to something new than to say no, so it’s important to have these checks in place to make sure we don’t
end up with something overly broad again.
John
From:
<> on behalf of Jason Keirstead <>
Date: Tuesday, November 27, 2018 at 4:15 PM
To: "Kelley, Sarah E." <>
Cc: "" <>
Subject: Re: [cti] TAXII definition of "Done"
I would also agree that TAXII features should also meet the STIX definition of "done" in order to be included in the spec.
-
Jason Keirstead
Lead Architect - IBM Security Connect
www.ibm.com/security
"Things may come to those who wait, but only the things left by those who hustle." - Unknown
From: "Kelley, Sarah E." <>
To: "" <>
Date: 11/27/2018 04:56 PM
Subject: [cti] TAXII definition of "Done"
Sent by: <>
All,
As I mentioned on the working call today, we have imposed a very strict definition of “Done” for new features/objects in STIX, however, we have never agreed as a TC to impose the same rigorous standards to TAXII. Given the fact
that some of the issues that prompted us to implement this definition came about when people attempted to implement TAXII, it seems only logical to me that we would impose the same standards to both specifications.
As a reminder, the definition of “Done” for STIX includes:
Written specification text
Proof of concept code from at least two different developers/companies
Corresponding Interop tests
For some of the newer features in TAXII, namely TAXII query, it seems to make sense to me that it should be proved in code before we finalize it in the specification.
I wanted to bring this topic to the list and see what other people thought about this.
Thanks,
Sarah Kelley
Lead Cybersecurity Engineer, T8B2
Defensive Operations
The MITRE Corporation
703-983-6242
[attachment "image003.jpg" deleted by Jason Keirstead/CanEast/IBM]
