Re: [Cacao] [EXT] Consensus call for CACAO Charter

[Michael Richardson <[e-mail]>]

{sorry, this draft sat unfinished for a week}

Bret Jordan <[e-mail]> wrote:
    >> [inacio] In this case, do (at least you and Bret) intend that the data
    >> model for CACAO is will use the STIX data model?  Following from that,
    >> there isn’t really a data modeling task and that the real work would
    >> be creating the necessary serializations for playbooks.



    > CACAO will not be using the STIXv2 Data Model since if STIXv2 supported
    > this functionality there would be no need for this group. However, it
    > is vitally important that CACAO be linkable to other STIXv2 data in the
    > graph.  But luckily we know a thing or two about STIXv2.  There is also
    > a lot of concepts that we have learned from designing and implementing
    > cyber threat intelligence based on STIXv2.  So all of that knowledge
    > will flow in to this working group.  Meaning, we know how IDs need to
    > be done to support this, we know how versioning needs to work, we
    > understand what type of data needs to be related in the graph and how
    > to do it. The real challenge will be getting the sequencing of atomic
    > actions and any temporal / conditional logic right.

It would be really useful to the people come to this from the IETF side of
things (whether as digital signature experts, threat modelling, serialization
experts, etc.)  if the STIXv2 expertise/experience could be distilled in some
way.  I'm not asking to take in-person time on this.  My suggestions would
include:
  a) pointing us to videos of existing talks/tutorials
  b) having a side-meeting or virtual-interim on it
  {c) getting Jeopardy to add it as a category}

    > I am somewhat alarmed that we have to give this much detail and be this
    > prescriptive in the charter.  A charter IMHO should focus on the goals
    > that we want to achieve and some general guidance (subject to change)
    > on how we believe we will be able to solve it. With that said, if we
    > need to give super explicit details about how we are going to write
    > that part of the content then here is some text.

I think that you have a pretty clear vision of what you want, but the rest of
us just see some fog downstream.  We think you are saying it conceals a
bridge (rather than, a yacht, barge, waterfall or mountain).  In order to be
convinced, we need to know if it's a cable-stayed suspension bridge, a truss
bridge, or a flood-control dam.   We don't need to know the dimensions of the
cables, or the number of pylons, or if the flood-control dams are operated by
trolls or RPI running the Google IoT platform.

We like to have formats in the charter because it eliminates (or front-end
loads) what is usually a wasteful rat-hole on formats.

    > to be version 7. I know if I was not a sponsor of this work, I would be
    > bored and some what irritated that we were not yet working on real
    > things.

Actually, you are working on real things!
You are developing the trust relationships and the share vision that will be
needed to get through the harder things.

    > Also I would imagine that most people will communicate and provide most
    > of their feedback during the weekly working calls (that we will setup)
    > and in the Google Docs directly. So I would think that overall, list
    > traffic will always be light.  But just like we do with the STIX
    > community, we will try to always send notes to the list about what was
    > talked about and discussed on the working calls.

Weekly is probably fine for a design team meeting.
I suggest that it's too often for others.  Every two weeks can work well.
Some will not have seen the Google Doc discussion.

    > I am thinking that we may need to add the following to the charter as
    > well, just to keep us from having endless debates about how we are
    > going to do work. Something like:

    > “This working group plans on holding weekly working calls from 8:00
    > AM-9:00 AM US-Pacific and the working groups plans on using Google Docs
    > for all specification work. While working group members can always send
    > comments and suggestions via email, it will be encouraged to document
    > all comments and suggestions directly in Google docs to enable a more
    > rapid development and response process."

I think that this is too specific and does not belong in the charter.

I suggest:

"The working group plans on holding monthly virtual interim calls.
One or more design team will be created that will hold calls according to
a higher cadence, to be determined by the participants.  The WG intends
to use Github for issue tracking; the design team(s) may use other mechanism
(Google Docs, etc.) as they see need"

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-