[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [Non-DoD Source] [openc2-lang] Language Use Cases for Tuesday Discussion
|
I am submitting this as Joe B from NSA, not co-chair:
The LSC utilized an agile approach to the language specification.
Here are a couple of numbers associated with working draft one:
~64% of the eligible voters voted YES on wd 1 ~81% of the votes cast were YES on wd 1.
Though I would prefer to see 100% across the board, those are not bad numbers, in fact one could conclude that the data indicates that the agile approach appears
to be a promising approach. I am OK with the idea of using ‘threads’ to illustrate the need for a target specifier(s) and /or target option(s) but I think it is a mistake to abandon a strategy
that worked quite nicely for wd 1. To ‘require’ a use case and require that we work it completely is a mechanism to slow our progress to a crawl, and in the extreme, we will end up playing ‘bring me a rock’. I appreciate and sympathize with the notion that the target types have not been completely specfified and that the use of threads can help tease out specifiers
and options, but we need to keep in mind the scope of the language spec (versus the profiles). I can see using the threads as a tool, and can even see putting a couple of examples in an appendix., but we have 32 actions and 24 target types. I assume nobody
is proposing that we need to exercise (and document) 768 use cases. VR Joe B From: openc2-lang@lists.oasis-open.org [mailto:openc2-lang@lists.oasis-open.org]
On Behalf Of duncan@sfractal.com 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 --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]