OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti] CTI Charter


Language in a charter as Duncan says, is important to get right. You need to be pedantic. But Scope != Deliverables. Yes, deliverables can be called out in a charter, but it is usually bad form to do so. Some times TCs, WGs, SGs, etc will do this to help grease the gears per say. Meaning, to help people understand what is going on and at least was is the first thing the TC will be working on. With that said it is possible to have a TC designed to deliver a fixed number of deliverables and then close. 

With all of that said, rechartering can be a very healthy process. Even if at the end of the process the group decides that no modification to the charter is needed. This process helps ensure that the TC is actually meeting the needs of the group. Sometimes a work gets started with a certain charter. But after a while members want to do more. Having these discussions are healthy and sometimes the answer is to go off and create a new group, like what we did with CACAO.  Another benefit is it helps clear out the deadwood of TCs that really should have been closed because no work is really happening anymore. 

I believe interoperability is and has always been part of the TC Charter. It deals with making sure this stuff works. You do not need to call that out as an explicit line item. 

What might help some is to ask why do WGs, TCs, SGs, etc have a charter? I am sure Duncan can add some additional color here, but in general:

1) Make sure one group does not try to do the work of another group. Keep all groups in their defined lanes. Though OASIS is notoriously bad at this and the IETF is on the other extreme end.  

2) Make sure that the organizations participating understand the IPR aspects of working in that group, if there was no defined charter and people could propose anything, than very few organizations would be allowed to join

3) Make sure the members of the TC stay focused on actually getting something done. Distractions in groups like this can kill the work off. Remember that TCs have a finite number of volunteer hours per week to spend. If there is no focus you will loose interest. This is why having clearly defined and scoped deliverables is critical. But remember defined deliverables != charter. The deliverables and their scope/priority should be proposed by the members. The chairs are just there to help ensure things are moving along and the rules are being followed. 



Bret



On Apr 26, 2022, at 11:55 AM, aa tt <atcyber1000@gmail.com> wrote:

Duncan - thank you for raising this important document and support your message that Interop is part of CTI TC.

Having been the CTI Interop Co-Chair, helped lead/define the Interop test documents and the STIXPreferred program as a whole - I think it Is bizarre to hear a statement that the CTI TC charter doesnât cover Interop.

My response -> Of course it covers Interop. Its been an active area for multiple years and the fact that the TC held multiple plugfests, spent significant time on working on Interop specification, tests and a whole self-certification program shows that its an important work product.

I donât have the time to attend the CTI meetings most of the time nowadays but if thereâs a need for support or justification on *all* the work that has already taken place in this area and should continue then let me know when you need supportive voices.

For anyone to seriously suggest that STIX/TAXII specifications alone are sufficient to create a sharing ecosystem without the necessary interop to support working implementations in the real-world is deft of logic.

Allan

On Apr 26, 2022, at 9:42 AM, duncan sfractal.com <duncan@sfractal.com> wrote:

I believe we should be semantically pedantic when discussing the charter and I may not have made my position clear. I am fine with rechartering if we feel it is necessary. What I want us to be very careful on is when we are discussing the scope of the CTI TC Charter. The minutes have the following statements:
  • âBased on the original TC charter, weâve largely accomplished our goals!â
  • âThese (interop and accessibility) are not in our current charter.â
  • âRecharter is necessary because Interop is not in our original charterâ
I have issues with the above statements. Reminding everyone, here is the scope copied verbatim from our current charter at https://www.oasis-open.org/committees/cti/charter.php :
âScope of Work 
The OASIS CTI TC work is the continuing development of the STIX and TAXII standards, based on the needs identified by the CTI TC Members. The Standards Track Work Product efforts will be related to improving existing information representations for codifying, analyzing, or sharing of cyber threat intelligence as well as defining new information representations for covering additional Cyber Threat Intelligence use cases identified by the CTI TC.
In addition to Standards Track Work Products, the OASIS CTI TC work products may include supporting documentation, open source tooling, and any other materials deemed necessary to encourage the adoption of the TC's specifications.â
I donât think we have met all the goals in the charter eg âto improving existing information representations for codifying, analyzing, or sharing of cyber threat intelligence as well as defining new information representations for covering additional Cyber Threat Intelligence use cases identified by the CTI TC.â Although I agree that we may have delivered the deliverables in the charter section 4, I alsoI think âto continue evolving capabilities based on requirements and capabilities identified by OASIS TC membersâ gives us plenty of room to continue working.
I strongly disagree that interop is outside the scope of the existing charter. It clearly is within the scope above. I have no issue with rechartering. I donât even have an issue with increasing the scope of the existing charter â if it is necessary. Note OASIS makes a big distinction between increasing the scope of a TC charter (essentially equivalent to making a new TC) and modifying your charter but keeping or downsizing your scope. I donât want us to go through a lot of unnecessary bureaucracy that we donât need to. And I would like us to be able to continue working in the meantime. Recall we are not allowed to work on items outside our scope. That is why the scope exists. And why Iâm so anal on being semantically pedantic. 
So letâs be careful on our wording. Adding interop to the charter deliverables section is fine, but I have not heard anything yet that indicates we need to expand the scope of the TC charter. Be precise if something is missing from the deliverables section of the charter as there is a huge difference between
  • âRecharter is necessary because Interop is not in our original charterâ (what is said in meeting minutes) and
  • âRecharter would be beneficial because Interop is not in the deliverables section of our current charterâ (what I think was meant).
The former means it can not be worked on until the TC is rechartered with an increased scope though an onerous process. The later means it is within the current charter but we would like to highlight it, and itâs a fairly lightweight process to update the charter to contain it.
 
-- 
Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize
I welcome VSRE emails. Learn more at http://vsre.info/




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]