And as I said in my last email...
âWhile I fundamentally do not disagree, I have yet to see the TC push for this. By this philosophy we should have adopted the whole content process that I sent to the TC as a fully developed working
draft several months ago.
So unless there is a ground swell of the TC that is pushing for this, I would object simply out of principle. This is the same reason why tons of new things are not just added to TAXII, there is
no demand for them and it is not up to me to just add them.â
So I object on principle. You have 4 people out of over 200 which is less than 2%. The TC has made it really clear as of late that talking about process is not something people want to do. And if we are going to try and talk about process then once
again I want to bring up the fully fleshed out Draft I submitted to the TC, which basically codifies what we have been doing behind the scenes.
Sent from my Commodore 128D
Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
As of last week, the people in support of having TAXII meet some definition of âdoneâ was:
â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. â
Since no one objected to the idea, and at least five people supported it, the goal was to move the ball further down the court and see if there was an appetite for taking this to a ballot and making it more official, and if so, to figure
out when we might want to do that.
In all things consensus based, there is the âdoes anyone objectâ and two, âwho supports and is driving thisâ.
It is generally not good form to do things by âobjectionâ but rather first by demand and then by objection.
While I fundamentally do not disagree, I have yet to see the TC push for this. By this philosophy we should have adopted the whole content process that I sent to the TC as a fully developed working draft several months ago.
So unless there is a ground swell of the TC that is pushing for this, I would object simply out of principle. This is the same reason why tons of new things are not just added to TAXII, there is no demand for them and it is not up to me
to just add them.
Sent from my Commodore 128D
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
Having seen no objections to the idea of instituting a mandate of âdoneâ for TAXII (in addition to STIX), I believe the next step would be to decide when we want to institute that policy. As with STIX, the best way to institute that new
policy would be to have a ballot on it, so we would need to decide when to open that ballot.
In my understanding of the changes in the current WD that is open for ballot, the only new âthingâ is the client user-agent. From my perspective, this seems like a relatively small change to hold up with the addition of this new process,
however something like TAXII query would make sense to have proven out in code and to pre-build interop tests for.
What do the TC members think about when we should start the ball rolling on implementing this policy?
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.
+1 to TAXII features starting to require the same level of doneness as STIX changes.
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.
I would also agree that TAXII features should also meet the STIX definition of "done" in order to be included in the spec.
Lead Architect - IBM Security Connect
"Things may come to those who wait, but only the things left by those who hustle." - Unknown
From: "Kelley, Sarah E." <email@example.com>
To: "firstname.lastname@example.org" <email@example.com>
Date: 11/27/2018 04:56 PM
Subject: [cti] TAXII definition of "Done"
Sent by: <firstname.lastname@example.org>
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.
Lead Cybersecurity Engineer, T8B2
The MITRE Corporation
[attachment "image003.jpg" deleted by Jason Keirstead/CanEast/IBM]