[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [EXT] Re: [cti] TAXII definition of "Done"
All, 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? Thanks, Sarah Kelley Lead Cybersecurity Engineer, T8B2 Defensive Operations The MITRE Corporation 703-983-6242 From: Bret Jordan <Bret_Jordan@symantec.com> 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:
cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com> +1 to TAXII features starting to require the same level of doneness as STIX changes. Allan From:
"cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Wunder, John" <jwunder@mitre.org> 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:
<cti@lists.oasis-open.org> on behalf of Jason Keirstead <Jason.Keirstead@ca.ibm.com> I would also agree that TAXII features should also meet the STIX definition of "done" in order to be included in the spec.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]