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


Help: OASIS Mailing Lists Help | MarkMail Help

openc2-lang message

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

Subject: Language Use Cases for Tuesday Discussion

I am submitting this email as Duncan of sFractal not as LSC co-chair.

At the F2F we decided the next iteration of the Language Specification would be done by walking a command thru end to end as part of a use case. We are calling this command walkthru a 'thread' (ie there may be multiple threads in a use case). This will tease out all the issues we haven't gotten to yet. Speaking for myself, I find it easier to discuss a particular thread vs the entirety of everything that could be done with OpenC2.

My thoughts are we should start with the easiest threads in the simpler use cases and preferably less controversial use cases. I also favor documented use cases over verbal use cases. I'd also favor 'implemented' use cases over 'desired' use cases (e.g. I'd favor Zepko and AT&T use cases over sFractal use cases because they each have working code with real users using it).

As a reminder to those newer to the group, I have submitted my usecases to the Language Subcommittee OASIS github at https://github.com/oasis-tcs/openc2-lsc-usecases. I have found github to be a very good change control mechanism and it creates what i think are very usable usecases. I'd be happy to help anyone who would like to add their usecases to this repo. Looking at what I have submitted shows I obviously haven't finished but you get a feeling for what's doable.

If we were to use an sFractal usecase, I would recommend https://github.com/oasis-tcs/openc2-lsc-usecases/blob/master/sFractalConsulting/01.another_user.md and the deny command shown at https://github.com/oasis-tcs/openc2-lsc-usecases/blob/master/sFractalConsulting/01.another_user.md#openc2-json-command.

Looking at the usecases AT&T presented, I would recommend the 'contain' thread over the 'query' or 'locate' thread. My recommendation is based on two factors. The first being both query and locate could be considered overlapping - ie I expect we'll argue some about the 'best' way to achieve what AT&T was trying to achieve. Recall that started happening in the meeting and recall AT&T mentioned it wasn't obvious to them which to use. This is an issue we really need to resolve, but I don't think it's what we should start with. The main reason I favor contain over query/locate is that I am sure query/locate will drop us into the STIX arguments. I suspect those with STIX usecases for OpenC2 won't use query/locate in OpenC2 but instead use STIX. Since the straw poll at the F2F seemed about evenly split on those that will use OpenC2 inside STIX COA and those that will use OpenC2 using some other transport, I don't think query or locate would be the place to start.

Duncan Sparrell
sFractal Consulting LLC
iPhone, iTypo, iApologize

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