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: 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. 




Joe B


From: openc2-lang@lists.oasis-open.org [mailto:openc2-lang@lists.oasis-open.org] On Behalf Of duncan@sfractal.com
Sent: Monday, January 15, 2018 8:10 AM
To: openc2-lang <openc2-lang@lists.oasis-open.org>
Subject: [Non-DoD Source] [openc2-lang] 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.



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]