Subject: [Cacao] Consensus call for CACAO Charter

From: Chris Inacio <[email-masked]>
Date: Mon, 24 Jun 2019 14:20:44 +0000

We have a new charter revision posted to the list [1] and available as an internet-draft [2].  The charter addresses the comments made during the previous call and tightens the scope of the work.   Please send any comments on the charter to the list by June 28, 2019.

At this point the chairs (and the AD’s) are concerned with the number of people willing to volunteer to edit documents.  There have been a number of people willing to review documents.  This lack of volunteering to edit documents is the biggest factor slowing the chartering of this effort as a working group currently.  If there are possible editors who have not participated in the IETF, please let them know to send an email to the list and volunteer.

Lastly,  with respect to the “JSON Data Model” concerns that have been voiced on the list from Med and Carsten, we propose the following from:

—

o  CACAO JSON Data Model

      *  Create a JSON data model that can capture and enable
         collaborative courses of action

to

o CACAO Data Model
* Create a data model that can capture and enable collaborative courses of action in
  an appropriate format which can be realized in JSON and/or other wire formats as appropriate

—

Thanks,

Joe and Chris

[1] https://mailarchive.ietf.org/arch/msg/cacao/k7XkqboXMJYkAmCBT99SJzQLTq8

[2] https://tools.ietf.org/html/draft-jordan-cacao-charter-06

---

From: Bret Jordan <[email-masked]>
Date: Tue, 25 Jun 2019 05:59:19 +0000

I do not agree with that proposed change.

Bret

Sent from my Commodore 128D

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

On Jun 24, 2019, at 4:21 PM, Chris Inacio <[email-masked]<mailto:[email-masked]>> wrote:

—

o  CACAO JSON Data Model

to

o CACAO Data Model

—

Thanks,

Joe and Chris

[1] https://mailarchive.ietf.org/arch/msg/cacao/k7XkqboXMJYkAmCBT99SJzQLTq8<https://clicktime.symantec.com/3HShpPU1Z7PqSe6ACHVydrA7Vc?u=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fcacao%2Fk7XkqboXMJYkAmCBT99SJzQLTq8>

[2] https://tools.ietf.org/html/draft-jordan-cacao-charter-06<https://clicktime.symantec.com/3WSU8Nwv8DNmfbGSd7LkRFP7Vc?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-jordan-cacao-charter-06>

--
Cacao mailing list
[email-masked]<mailto:[email-masked]>
https://clicktime.symantec.com/3XykSkxSzK393g6kotqED3o7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcacao

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 25 Jun 2019 08:07:30 +0200

Well, you will need to make a change that is indicative of understanding the difference between a data serialization format (intended here: JSON) and a data modeling language (not decided, might be YANG, or tables written in English, or both).

How do you propose to fix this?

Grüße, Carsten

> On Jun 25, 2019, at 07:59, Bret Jordan <Bret_Jordan=[email-masked]> wrote:
> 
> On Jun 24, 2019, at 4:21 PM, Chris Inacio <[email-masked]> wrote:
> 
>> [email-masked]
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cacao

---

From: Chris Inacio <[email-masked]>
Date: Tue, 25 Jun 2019 15:20:06 +0000

I tried and clearly failed to state that a data model would be separate from the serialization and that JSON serializations (or others) would still be possible even if some other language were used for the data model.  Also - I agree that JSON (having serialization in its name) is generally not a data modeling language.  (I’m sure JSON as a data modeling language can be fixed with a sufficient amount of prose around the JSON text.)

Any language you would like to propose?

* CACAO data model
A data model will be developed in an appropriate language that will allow serialization into data serialization formats including at a minimum JSON and possibly others.

Any better?

On June 25, 2019 at 2:07:39 AM, Carsten Bormann ([email-masked]<mailto:[email-masked]>) wrote:

Grüße, Carsten

---

From: Chris Inacio <[email-masked]>
Date: Tue, 25 Jun 2019 15:20:39 +0000

Can you provide more than “do not agree” so that we can possibly find a middle grown.

On June 25, 2019 at 1:59:24 AM, Bret Jordan ([email-masked]<mailto:[email-masked]>) wrote:

Bret

—

o  CACAO JSON Data Model

to

o CACAO Data Model

—

Thanks,

Joe and Chris

---

From: Chris Inacio <[email-masked]>
Date: Tue, 25 Jun 2019 15:53:47 +0000

On June 25, 2019 at 11:20:39 AM, [email-masked] ([email-masked]<mailto:[email-masked]>) wrote:

Inacio: Can you provide more than “do not agree” so that we can possibly find a middle grown.

Inacio: Okay that’s embarrassing and awful - "middle ground" that should be.  (I should stop doing 3 things at once.)

Bret

—

o  CACAO JSON Data Model

to

o CACAO Data Model

—

Thanks,

Joe and Chris

---

From: Allan Thomson <[email-masked]>
Date: Tue, 25 Jun 2019 18:25:05 +0000

I think we are talking past each other. We (Bret/I) are not suggesting JSON is the data model definition language.

STIXv2 defines the data model in the specification as a table of named properties, types and parameter descriptions. There are also sections of the specification that define mandatory/optional behavior.

Example below.

While this is not immediately machine-readable it *is* extremely useful to describe intended use, define parameter constraints….etc.

While other data modelling languages may achieve this, they may have other drawbacks for editing/collaboration and creation of the data model.
Allan

From: Cacao <[email-masked]> on behalf of Chris Inacio <[email-masked]>
Date: Tuesday, June 25, 2019 at 8:20 AM
To: Carsten Bormann <[email-masked]>, Bret Jordan <bret_jordan=[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Cacao] [EXT] Consensus call for CACAO Charter

* CACAO data model

Any better?

Grüße, Carsten

---

From: Chris Inacio <[email-masked]>
Date: Tue, 25 Jun 2019 20:27:13 +0000

On June 25, 2019 at 2:25:17 PM, Allan Thomson ([email-masked]<mailto:[email-masked]>) wrote:
I think we are talking past each other. We (Bret/I) are not suggesting JSON is the data model definition language.

Example below.

* CACAO data model

Any better?

Allan,

[inacio] Thank you for the response, this is REALLY helpful.

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

---

From: Bret Jordan <[email-masked]>
Date: Wed, 26 Jun 2019 07:35:41 +0200

Chris,

Thanks for your questions.  Let me try and respond and add to what Allan has said.

> [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 re…

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.

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. 

Old Text:
 - CACAO JSON Data Model
   - Create a JSON data model that can capture and enable collaborative courses of action

New Text
 - Design a data model for CACAO
   - This working group will define a normative data model for CACAO using property tables similar to how the OASIS STIXv2 data model was defined. This data model will be designed to explicitly work with I-JSON and all examples will be done in JSON. The working group will also define JSON as the mandatory to implement serialization for this version of CACAO. The working group may decide to also document the data model in other non-normative forms that would be located in an an appendix. 

Do we need to give that kind of details for all aspects of the Charter?

Some of said there is not much discussion on the list.  Well there is not much to discuss when nearly all of the supporters of this work agreed to version 1 or 2 of the charter.  We are now on version 6 soon 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.

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.  

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."
 
All in all I am really coming around to this idea that we need an IETFv2.  We should be able to spin up working groups in terms of days or weeks rather than months or years.  You could then define actual measurable targets that a working group has to achieve every year, otherwise it gets automatically closed.  We have spent / wasted so much time trying to find the perfect text for the charter.  

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

>> text.)

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Jun 2019 16:07:38 -0400

Chris Inacio <[email-masked]> wrote:
    > We have a new charter revision posted to the list [1] and available as
    > an internet-draft [2].  The charter addresses the comments made during
    > the previous call and tightens the scope of the work.  Please send any
    > comments on the charter to the list by June 28, 2019.

I have read the charter.

I understand all the words and the sentences, and I find them well formed and
clear at the level of english.

I have very little understanding of some of the details of the form of we are
going to specify.   If I make an analogy, it is as if you have announced in
1810 in New York City, that we will travel by "coveyance" to LA, and then
inserted some new words.

While I have heard of something called "trains" (I've never been on one),
other words like "interstate", "air-traffic control", "737MAX" and
"Tesla" are not helping me understand how many pairs of underwear to pack.
(But, gosh, I'm excited!)

What I know: It's gonna be JSON, and it's gonna be signed.
Beyond that, I have very little understanding of what will be contained/specified.

I'm afraid of the Functional Specification work, but maybe it can be done well.

I can't help with the writing, sorry.

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

---

From: <[email-masked]>
Date: Wed, 26 Jun 2019 06:32:21 +0000

Hi Inacio,

The proposed text is much more better. Thanks.

Cheers,
Med

De : Cacao [mailto:[email-masked]] De la part de Chris Inacio
Envoyé : mardi 25 juin 2019 17:20
À : Carsten Bormann; Bret Jordan
Cc : [email-masked]
Objet : Re: [Cacao] [EXT] Consensus call for CACAO Charter

* CACAO data model

Any better?

Grüße, Carsten