Subject: [Cacao] Charter

From: Bret Jordan <[email-masked]>
Date: Tue, 18 Jun 2019 11:55:13 +0000

Thanks everyone, for your additional comments and suggestions.  I will work with Allan and Jyoti to get them resolved.  Just so you know, it would be a lot easier and faster if you added your comments and suggestions in to the live document here:

https://docs.google.com/document/d/1fTN0uilpBVx6CwaGxj8SBKG4PqG7DceInU9RgLz9pRo/edit#heading=h.wh8etuclav2g

Also, once this working group is formed, we will be using Google Docs for all of our work.  So I hope that works for everyone. Parsing and dealing with bulk inline comments and suggestions in documents via email is so incredibly difficult and painful.

We have been using Google Docs for other standards we work on (300+ individuals and several hundred pages) and it works so much better.  It is also much easier to see everyone's comments and suggestions all at once. You can also add comments to someone else's comments or suggestions which is really nice.

Bret

---

From: <[email-masked]>
Date: Tue, 18 Jun 2019 12:01:41 +0000

Re-,

I can't access the document.

Can you please use github?

Cheers,
Med

De : Cacao [mailto:[email-masked]] De la part de Bret Jordan
Envoyé : mardi 18 juin 2019 13:55
À : [email-masked]
Objet : [Cacao] Charter

Bret

---

From: Bret Jordan <[email-masked]>
Date: Tue, 18 Jun 2019 12:24:57 +0000

Using Github will prevent people from helping, or will limit people to only those that understand how to use Github and have access to Github.  Resolving comments and suggestions via Github is significantly harder than Google Docs.

Bret

________________________________
From: [email-masked] <[email-masked]>
Sent: Tuesday, June 18, 2019 6:01:41 AM
To: Bret Jordan; [email-masked]
Subject: [EXT] RE: [Cacao] Charter

Re-,

I can’t access the document.

Cheers,

Med

https://docs.google.com/document/d/1fTN0uilpBVx6CwaGxj8SBKG4PqG7DceInU9RgLz9pRo/edit#heading=h.wh8etuclav2g<https://clicktime.symantec.com/3UFMsdF2fqqteBVgf3Zrp7G7Vc?u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1fTN0uilpBVx6CwaGxj8SBKG4PqG7DceInU9RgLz9pRo%2Fedit%23heading%3Dh.wh8etuclav2g>

Bret

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 18 Jun 2019 15:41:20 +0200

> Using Github will prevent people from helping, or will limit people to only those that understand how to use Github and have access to Github.  Resolving comments and suggestions via Github is sign…

My comment here is kind of off-topic, but…
The statement you are making here is that one group of contributors (those that can stand collaborating on a document with the limited means Google Docs) is more important than another group of contributors (those that are used to software development workflows).  While that may very well be, I think it is important to make decisions like this explicitly.
(I personally believe that this effort could benefit from strong participation by people who write code.)

Grüße, Carsten

---

From: Bret Jordan <[email-masked]>
Date: Tue, 18 Jun 2019 14:05:18 +0000

Carsten,

I appreciate your comments. However, from our experience, with a large group of people that are in both camps, editing specs in Google docs proves to be the easiest solution for all. So it is not about preferring one group over another.  It is about what proves to be the easiest and fastest to enable as many people as possible to get work done quickly and efficiently.

Bret

________________________________
From: Carsten Bormann <[email-masked]>
Sent: Tuesday, June 18, 2019 7:41:20 AM
To: Bret Jordan
Cc: [email-masked]; [email-masked]
Subject: [EXT] Re: [Cacao] [EXT] RE: Charter

Grüße, Carsten

---

From: Amelia Andersdotter <[email-masked]>
Date: Tue, 18 Jun 2019 16:26:42 +0200

On 2019-06-18 16:05, Bret Jordan wrote:
>
> Carsten,
>
>
> I appreciate your comments. However, from our experience, with a
> large group of people that are in both camps, editing specs in Google
> docs proves to be the easiest solution for all. So it is not about
> preferring one group over another.  It is about what proves to be the
> easiest and fastest to enable as many people as possible to get work
> done quickly and efficiently. 
>
>
How about making it temporarily available on some form of etherpad? They
are normally accessible to everyone and rely only on browser functions.

best regards,

amelia

> Bret
>
>
> ------------------------------------------------------------------------
> *From:* Carsten Bormann <[email-masked]>
> *Sent:* Tuesday, June 18, 2019 7:41:20 AM
> *To:* Bret Jordan
> *Cc:* [email-masked]; [email-masked]
> *Subject:* [EXT] Re: [Cacao] [EXT] RE: Charter
>  
> On Jun 18, 2019, at 14:24, Bret Jordan
> <Bret_Jordan=[email-masked]> wrote:
> >
> > Using Github will prevent people from helping, or will limit people
> to only those that understand how to use Github and have access to
> Github.  Resolving comments and suggestions via Github is
> significantly harder than Google Docs.
>
> The statement you are making here is that one group of contributors
> (those that can stand collaborating on a document with the limited
> means Google Docs) is more important than another group of
> contributors (those that are used to software development workflows). 
> While that may very well be, I think it is important to make decisions
> like this explicitly.

-- 
Amelia Andersdotter
Technical Consultant, Digital Programme
Chair, RCM TIG, IEEE 802.11

ARTICLE19
www.article19.org

PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55

---

From: Bret Jordan <[email-masked]>
Date: Tue, 18 Jun 2019 16:30:41 +0200

Amelia,

That is an option.  Just so you know, Google Docs does not require anything other than a web browser.  If you go this url, just like an ether pad, you will see the document and suggestions and comments. 

https://docs.google.com/document/d/1fTN0uilpBVx6CwaGxj8SBKG4PqG7DceInU9RgLz9pRo/edit#heading=h.wh8etuclav2g <https://docs.google.com/document/d/1fTN0uilpBVx6CwaGxj8SBKG4PqG7DceInU9RgLz9pRo/edit#heading=h.wh8etuclav2g>

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

> On Jun 18, 2019, at 4:26 PM, Amelia Andersdotter <[email-masked]> wrote:
> 
> Cacao mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cacao

---

From: Amelia Andersdotter <[email-masked]>
Date: Tue, 18 Jun 2019 23:28:36 +0200

On 2019-06-18 16:30, Bret Jordan wrote:
> Amelia,
>
> That is an option.  Just so you know, Google Docs does not require
> anything other than a web browser.  If you go this url, just like an
> ether pad, you will see the document and suggestions and comments. 
>

it's true, i can open it. just some people said they couldn't.

best regards,

amelia

>> On Jun 18, 2019, at 4:26 PM, Amelia Andersdotter
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>> *From:* Carsten Bormann <[email-masked] <mailto:[email-masked]>>
>>> *Cc:* [email-masked]
>>> <mailto:[email-masked]>; [email-masked]
>>> <mailto:[email-masked]>
>>> <Bret_Jordan=[email-masked]
>>> <mailto:Bret_Jordan=[email-masked]>> wrote:
>>>>
>> www.article19.org <http://www.article19.org>
>>

ARTICLE19
www.article19.org

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Jun 2019 18:19:23 -0400

(why am I top-quoting?)
Bret, Carsten is not objecting to Google Docs.

Carsten is asking you to be explicit in saying that including people who
can't/won't do github is important.
Google Docs suffers from a lack of attribution for the text after the
"suggestion" is accepted.
Github suffers from way too much attribution.

I don't object to using Google Docs, but please make sure you know how to use
it well.  If you are editing an Internet Draft in Markdown format, then some
stuff will look weird, and people will make suggestion that can not be
implemented.

I don't think having it on etherpad is helpful, btw.

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

    > <[email-masked]> wrote:

    >         I appreciate your comments. However, from our experience, with
    > a large group of people that are in both camps, editing specs in Google

    >     How about making it temporarily available on some form of etherpad?
    > They are normally accessible to everyone and rely only on browser
    > functions.

    >         *From:* Carsten Bormann <[email-masked]> *Sent:* Tuesday, June
    > 18, 2019 7:41:20 AM *To:* Bret Jordan *Cc:*
    > [email-masked]; [email-masked] *Subject:* [EXT] Re:
    > [Cacao] [EXT] RE: Charter

    >         to only those that understand how to use Github and have access
    > to Github. Resolving comments and suggestions via Github is

    >         My comment here is kind of off-topic, but… The statement you
    > are making here is that one group of contributors (those that can stand
    > collaborating on a document with the limited means Google Docs) is more
    > important than another group of contributors (those that are used to
    > software development workflows).  While that may very well be, I think
    > it is important to make decisions like this explicitly.  (I personally
    > believe that this effort could benefit from strong participation by
    > people who write code.)

    >     --
    >     Amelia Andersdotter Technical Consultant, Digital Programme Chair,
    > RCM TIG, IEEE 802.11

    >     ARTICLE19 www.article19.org

    >     --
    >     Cacao mailing list [email-masked]

    > ----------------------------------------------------
    > Alternatives:

    > ----------------------------------------------------
    > --
    > Cacao mailing list [email-masked]

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Bret Jordan <[email-masked]>
Date: Wed, 19 Jun 2019 06:46:18 +0000

Thanks Michael.  Yes, I misunderstood the comments.  We agree that we need this to be inclusive.  There are a large number of security analysts that know and understand how this needs to work.  It is critical that we design it and build it in a way that they and the rest of the market can use.

I am very familiar with editing documents in Google docs for large technical committees.  While there are some things I like about github, I find the automatic always on change tracking in google docs to be sufficient.

We can also take regular snapshots and push to github for longer term archival if people would like that.  I would not be against that.

As you can see there are comments in the charter text right now, and comments on the comments.  Things that can be very difficult or non-intuitive to do in github.

Google docs is not perfect.  But if anyone from google is here and needs some ideas for how you could make it the ideal solution for this kind of work, I have some ideas for you.

Bret

Sent from my Commodore 128D

On Jun 19, 2019, at 12:19 AM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

(why am I top-quoting?)

Bret Jordan <[email-masked]<mailto:[email-masked]>> wrote:
That is an option. Just so you know, Google Docs does not require
anything other than a web browser. If you go this url, just like an
ether pad, you will see the document and suggestions and comments.

https://clicktime.symantec.com/3JAf65ZJwTfeqxVfAPTGXMp7Vc?u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1fTN0uilpBVx6CwaGxj8SBKG4PqG7DceInU9RgLz9pRo%2Fedit%23heading%3Dh.wh8etuclav2g

   On Jun 18, 2019, at 4:26 PM, Amelia Andersdotter
<[email-masked]<mailto:[email-masked]>> wrote:

       Carsten,

   best regards,

   amelia

       Bret

       *From:* Carsten Bormann <[email-masked]<mailto:[email-masked]>> *Sent:* Tuesday, June
18, 2019 7:41:20 AM *To:* Bret Jordan *Cc:*
[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]> *Subject:* [EXT] Re:
[Cacao] [EXT] RE: Charter

       On Jun 18, 2019, at 14:24, Bret Jordan
<Bret_Jordan=[email-masked]<mailto:Bret_Jordan=[email-masked]>> wrote:

           Using Github will prevent people from helping, or will
limit people

       Grüße, Carsten

   ARTICLE19 https://clicktime.symantec.com/33D3oaMYVStXDNQHd3evAL27Vc?u=www.article19.org

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

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

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works
-= IPv6 IoT consulting =-

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

---

From: <[email-masked]>
Date: Wed, 19 Jun 2019 07:24:00 +0000

Bret,

What is really important from where I sit is to be able to track efficiently the issues. This can be done by email or using github. Tooling (and logistic matters in general) is the kind of decision to be taken by the group once (hopefully) formed. It is too early to make a decision at this stage. So, let’s not spend cycles on this right now.

Back to the initial technical discussion, can you please share which comments you have taken into account and which ones are still pending. You can use separate threads for pending issues. Thank you.

Cheers,
Med

De : Cacao [mailto:[email-masked]] De la part de Bret Jordan
Envoyé : mercredi 19 juin 2019 08:46
À : Michael Richardson
Cc : [email-masked]; Bret Jordan
Objet : Re: [Cacao] [EXT] Re: [EXT] RE: Charter

Bret

(why am I top-quoting?)

       Carsten,

   best regards,

   amelia

       Bret

       Grüße, Carsten

---

From: Bret Jordan <[email-masked]>
Date: Wed, 19 Jun 2019 10:00:53 +0200

Mohamed,

All comments and suggestions have been addressed at this point.  Suggested changes to the charter are currently in the charter text in suggestion mode. 

Thanks,
Bret

> On Jun 19, 2019, at 9:24 AM, <[email-masked]> <[email-masked]> wrote:
> 
> Bret,
>  
> De : Cacao [mailto:[email-masked] <mailto:[email-masked]>] De la part de Bret Jordan
> Cc : [email-masked] <mailto:[email-masked]>; Bret Jordan
> On Jun 19, 2019, at 12:19 AM, Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> (why am I top-quoting?)
> Bret Jordan <[email-masked] <mailto:[email-masked]>> wrote:
> 
> https://clicktime.symantec.com/3JAf65ZJwTfeqxVfAPTGXMp7Vc?u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1fTN0uilpBVx6CwaGxj8SBKG4PqG7DceInU9RgLz9pRo%2Fedit%23heading%3Dh.wh8etuclav2g <https://clicktime.symantec.com/3JAf65ZJwTfeqxVfAPTGXMp7Vc?u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1fTN0uilpBVx6CwaGxj8SBKG4PqG7DceInU9RgLz9pRo%2Fedit%23heading%3Dh.wh8etuclav2g>
> 
> 
>        *From:* Carsten Bormann <[email-masked] <mailto:[email-masked]>> *Sent:* Tuesday, June
> [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]> *Subject:* [EXT] Re:
> <Bret_Jordan=[email-masked] <mailto:Bret_Jordan=[email-masked]>> wrote:
> 
> 
> 
>    ARTICLE19 https://clicktime.symantec.com/33D3oaMYVStXDNQHd3evAL27Vc?u=www.article19.org <https://clicktime.symantec.com/33D3oaMYVStXDNQHd3evAL27Vc?u=www.article19.org>
> 
> 
>    Cacao mailing list [email-masked] <mailto:[email-masked]>
> https://clicktime.symantec.com/36NaSMAoRn4patyVkcWPUUX7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcacao <https://clicktime.symantec.com/36NaSMAoRn4patyVkcWPUUX7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcacao>
> 
> 
> 
> 
> 
> Cacao mailing list [email-masked] <mailto:[email-masked]>
> https://clicktime.symantec.com/36NaSMAoRn4patyVkcWPUUX7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcacao <https://clicktime.symantec.com/36NaSMAoRn4patyVkcWPUUX7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcacao>
> 
> --
> Michael Richardson <[email-masked] <mailto:[email-masked]>>, Sandelman Software Works
> [email-masked] <mailto:[email-masked]>
> https://clicktime.symantec.com/36NaSMAoRn4patyVkcWPUUX7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcacao <https://clicktime.symantec.com/36NaSMAoRn4patyVkcWPUUX7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcacao>

---

From: <[email-masked]>
Date: Wed, 19 Jun 2019 08:39:27 +0000

Re-,

Great!

I interpret “addressed” as you made the proposed changes to address the issues.

Do you confirm that you updated the text to address the following items:

(1) Action validation:

[Med] An action may be flawed because the proposed action is not adequate for a threat or it is missing a mandatory clause to be actionable. Such objects need to be detected and discarded somehow/somewhere. Things may be complicated when actions are chained/augmented by an intermediate function. Some (consistency) validation will be needed. The question is whether this is part of the work or not.
(2) Which data model?

===
[Med] This is one is conflicting with the sentence citing reusing YANG. I would cite YANG here especially that converting YANG to JSON and vice versa is well documented (RFC7951).
[BRET] - Then maybe we need to delete YANG for now.  We need to focus on simple things that the eco-system can implement and use very quickly. Most Web2.0 developers are very familiar with JSON.  This is why we picked it for version 1.
[Med] We need to separate data modelling vs. application encoding. It is perfectly fine to use YANG for the modelling, but use JSON encoding for the application.
===

Cheers,
Med

De : Cacao [mailto:[email-masked]] De la part de Bret Jordan
Envoyé : mercredi 19 juin 2019 10:01
À : BOUCADAIR Mohamed TGI/OLN
Cc : [email-masked]
Objet : Re: [Cacao] [EXT] Re: [EXT] RE: Charter

Mohamed,

Thanks,
Bret

On Jun 19, 2019, at 9:24 AM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Bret,

Cheers,
Med

De : Cacao [mailto:[email-masked]] De la part de Bret Jordan
Envoyé : mercredi 19 juin 2019 08:46
À : Michael Richardson
Cc : [email-masked]<mailto:[email-masked]>; Bret Jordan
Objet : Re: [Cacao] [EXT] Re: [EXT] RE: Charter

Bret

(why am I top-quoting?)

       Carsten,

   best regards,

   amelia

       Bret

       Grüße, Carsten

---

From: Allan Thomson <[email-masked]>
Date: Wed, 19 Jun 2019 10:02:49 +0000

1.  Action Validation as a function and part of the process *is* considered part of the architectural functional requirements however given that we are explicitly stating that individual atomic actions that can be referenced by the playbooks are *out* of scope then it by design that the determination of validity of an individual action can also not be in scope.

  1.  Data Model: You seem to be suggesting that this work must use YANG for modelling. We are not excluding that option but we are also not mandating it either. I assume you are encouraging use of YANG. I think that’s a reasonable suggestion but I don’t see why it must be the case. There are many projects that have successfully been achieved without YANG being used for data modelling.

Allan Thomson
CTO (+1-408-331-6646)
LookingGlass Cyber Solutions<http://www.lookingglasscyber.com/>

From: Cacao <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Wednesday, June 19, 2019 at 1:40 AM
To: Bret Jordan <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Cacao] [EXT] Re: [EXT] RE: Charter

Re-,

Great!

(1) Action validation:

===

Cheers,
Med

Mohamed,

Thanks,
Bret

Bret,

Cheers,
Med

Bret

(why am I top-quoting?)

       Carsten,

   best regards,

   amelia

       Bret

       Grüße, Carsten

---

From: Bret Jordan <[email-masked]>
Date: Wed, 19 Jun 2019 12:35:59 +0200

Agreed.

Here are some current screen shots of the proposed changes to the charter text.

Thanks,
Bret

> On Jun 19, 2019, at 12:02 PM, Allan Thomson <[email-masked]> wrote:
> 
> Action Validation as a function and part of the process *is* considered part of the architectural functional requirements however given that we are explicitly stating that individual atomic actions that can be referenced by the playbooks are *out* of scope then it by design that the determination of validity of an individual action can also not be in scope.
>  
> Data Model: You seem to be suggesting that this work must use YANG for modelling. We are not excluding that option but we are also not mandating it either. I assume you are encouraging use of YANG. I think that’s a reasonable suggestion but I don’t see why it must be the case. There are many projects that have successfully been achieved without YANG being used for data modelling.
>  
> Allan Thomson
> CTO (+1-408-331-6646)
> LookingGlass Cyber Solutions <http://www.lookingglasscyber.com/>
>  
> From: Cacao <[email-masked] <mailto:[email-masked]>> on behalf of "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> To: Bret Jordan <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Cc : [email-masked] <mailto:[email-masked]>
> On Jun 19, 2019, at 9:24 AM, <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Bret,
>  
>>>    Cacao mailing list [email-masked] <mailto:[email-masked]>https://clicktime.symantec.com/36NaSMAoRn4patyVkcWPUUX7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcacao <https://clicktime.symantec.com/36NaSMAoRn4patyVkcWPUUX7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcacao>
>> 
>> 
>> 
>> 
>> 
>> 
>>> Cacao mailing list [email-masked] <mailto:[email-masked]>https://clicktime.symantec.com/36NaSMAoRn4patyVkcWPUUX7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcacao <https://clicktime.symantec.com/36NaSMAoRn4patyVkcWPUUX7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcacao>
>> --

---

From: <[email-masked]>
Date: Wed, 19 Jun 2019 11:10:57 +0000

Hi Allan,

Please see inline.

Cheers,
Med

De : Cacao [mailto:[email-masked]] De la part de Allan Thomson
Envoyé : mercredi 19 juin 2019 12:03
À : BOUCADAIR Mohamed TGI/OLN; Bret Jordan
Cc : [email-masked]
Objet : Re: [Cacao] [EXT] Re: [EXT] RE: Charter

[Med] Works for me. We just need to mention this clearly in the charter text.

  1.  Data Model: You seem to be suggesting that this work must use YANG for modelling

[Med] It is the current text which is imposing JSON for data modelling. I’m suggesting to not pick a modeling language and leave it open hence avoid mentioning JSON as the only choice. Likewise, the WG may want to use CBOR instead of JSON for data encoding. All that will be part of the protocol design choices.

. We are not excluding that option but we are also not mandating it either.

[Med] This is not what the current text says. BTW, who is “we”?

I assume you are encouraging use of YANG. I think that’s a reasonable suggestion but I don’t see why it must be the case.
There are many projects that have successfully been achieved without YANG being used for data modelling.

Allan Thomson
CTO (+1-408-331-6646)

Re-,

Great!

(1) Action validation:

===

Cheers,
Med

Mohamed,

Thanks,
Bret

Bret,

Cheers,
Med

Bret

(why am I top-quoting?)

       Carsten,

   best regards,

   amelia

       Bret

       Grüße, Carsten

---

From: Bret Jordan <[email-masked]>
Date: Wed, 19 Jun 2019 11:25:34 +0000

I fundamentally do not support the idea of not using JSON for this work.  Over time we may write a binding document for some other serialization.  But we need something that can be implemented and have guaranteed interoperability.

In order to gain mass adoption, we need a solution that can be used by the existing eco system.

Bret

On Jun 19, 2019, at 1:12 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Allan,

Please see inline.

Cheers,
Med

Cc : [email-masked]<mailto:[email-masked]>

Allan Thomson
CTO (+1-408-331-6646)
LookingGlass Cyber Solutions<https://clicktime.symantec.com/3TPG1wu5tqoSYv5eMV62nnc7Vc?u=http%3A%2F%2Fwww.lookingglasscyber.com%2F>

From: Cacao <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 19, 2019 at 1:40 AM
To: Bret Jordan <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Cacao] [EXT] Re: [EXT] RE: Charter

Re-,

Great!

(1) Action validation:

===

Cheers,
Med

Cc : [email-masked]<mailto:[email-masked]>

Mohamed,

Thanks,
Bret

Bret,

Cheers,
Med

Bret

(why am I top-quoting?)

       Carsten,

   best regards,

   amelia

       Bret

       Grüße, Carsten

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

---

From: <[email-masked]>
Date: Wed, 19 Jun 2019 11:41:27 +0000

Re-,

Please see inline.

Cheers,
Med

De : Bret Jordan [mailto:[email-masked]]
Envoyé : mercredi 19 juin 2019 13:26
À : BOUCADAIR Mohamed TGI/OLN
Cc : Allan Thomson; Bret Jordan; [email-masked]
Objet : Re: [Cacao] [EXT] Re: [EXT] RE: Charter

I fundamentally do not support the idea of not using JSON for this work.
[Med] Are you referring to application encoding or data modelling part?

 Over time we may write a binding document for some other serialization.  But we need something that can be implemented and have guaranteed interoperability.
[Med] Why CBOR wouldn’t be an option here? BTW, there might be other requirements such as compactness (that may be worth when actions are enriched/augmented on-path). As a group, we don’t have yet the full set of requirements to make a design choice.

Bret

Please see inline.

Cheers,
Med

Allan Thomson
CTO (+1-408-331-6646)

Re-,

Great!

(1) Action validation:

===

Cheers,
Med

Mohamed,

Thanks,
Bret

Bret,

Cheers,
Med

Bret

(why am I top-quoting?)

       Carsten,

   best regards,

   amelia

       Bret

       Grüße, Carsten

---

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

The initial version needs to be done in JSON, if we want the market as a whole to adopt this. I have walked the floor at RSA and Blackhat for the past 2 years talking to all of the vendors that would potentially implement this.  They all say the same thing.  If it was JSON, they could easily do it.  If it is something else, well, maybe, maybe not.  We would then be reliant on market pressure and consumers to influence vendors to adopt.  That can take 10 years or more. Usually by then, the standard is failed and the market has moved on.  Let us not be yet another standard on the dusty shelves of of the SDO Library.

Further, anything not JSON would require the Web2.0 world of products and APIs to support something totally different.  CBOR may take off at some point.  YANG my take off at some point.  XML may come back from the dead. But right now, today, JSON is the model that the developers of products use and know. Adding additional hurtles for the solution to be adopted is not a good idea for this first version.  

Overtime, once we get our first versions done and out the door and they get adopted, we can make changes or add functionality based on market demand.  If the market comes back and says, hey, we really need this done in a binary format like Protobuf, then great.  We can write a binding for that.   

Thanks,
Bret

> On Jun 19, 2019, at 1:41 PM, [email-masked] wrote:
> 
> Re-,
>  
> Please see inline.
>  
> Cheers,
> Med
>  
> De : Bret Jordan [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc : Allan Thomson; Bret Jordan; [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Wed, 19 Jun 2019 12:57:28 +0000

+1 If we want this to take off I support to be as close to the current market as possible

From: Cacao <[email-masked]> on behalf of Bret Jordan <[email-masked]>
Date: Wednesday, 19 June 2019 at 14:07
To: "[email-masked]" <[email-masked]>
Cc: Bret Jordan <[email-masked]>, "[email-masked]" <[email-masked]>, Allan Thomson <[email-masked]>
Subject: Re: [Cacao] [EXT] Re: [EXT] RE: Charter

Thanks,
Bret

On Jun 19, 2019, at 1:41 PM, [email-masked]<mailto:[email-masked]> wrote:

Re-,

Please see inline.

Cheers,
Med

Cc : Allan Thomson; Bret Jordan; [email-masked]<mailto:[email-masked]>

Bret

---

From: "Jason Keirstead" <[email-masked]>
Date: Wed, 19 Jun 2019 13:04:25 +0000

I think it is also important to point out here that sharing of cybersecurity playbooks is not a high volume activity. It is not akin to sharing real-time cybersecurity data related to situational awareness, or even data like threat intelligence. Efficiencies gained at the wire protocol or on-disk regarding CBOR vs JSON will not be consequential to anyone in practice for this kind of data. What is more paramount is ease of interoperability between all of the many kinds of solutions looking to produce, revise, curate, and consume these playbooks.

-
Jason Keirstead
Lead Architect - IBM Security Connect
www.ibm.com/security

"Would you like me to give you a formula for success? It's quite simple, really. Double your rate of failure."

- Thomas J. Watson

----- Original message -----
From: <[email-masked]>
Sent by: "Cacao" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: [EXTERNAL] Re: [Cacao] [EXT] Re: [EXT] RE: Charter
Date: Wed, Jun 19, 2019 9:58 AM

Thanks,

Bret

Re-,

Please see inline.

Cheers,

Med

Bret

---

From: Allan Thomson <[email-masked]>
Date: Wed, 19 Jun 2019 15:25:05 +0000

JSON is a must.

Anything else imo is a nice-to-have.

Most products exchanging intel (and playbooks could be considered as aspect of intel) are doing that using JSON.

There are other translations such as protobufs…etc. STIX2 models intel using JSON not anything else.

Allan Thomson
CTO (+1-408-331-6646)

From: Bret Jordan <[email-masked]>
Date: Wednesday, June 19, 2019 at 5:07 AM
To: "[email-masked]" <[email-masked]>
Cc: Bret Jordan <[email-masked]>, Allan Thomson <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Cacao] [EXT] Re: [EXT] RE: Charter

Thanks,
Bret

Re-,

Please see inline.

Cheers,
Med

Bret

---

From: "Jyoti Verma (jyoverma)" <[email-masked]>
Date: Wed, 19 Jun 2019 16:30:15 +0000

+1 on JSON being mandatory here.

Thanks,
Jyoti

From: Cacao <[email-masked]> on behalf of Allan Thomson <[email-masked]>
Date: Wednesday, June 19, 2019 at 8:25 AM
To: Bret Jordan <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Bret Jordan <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Cacao] [EXT] Re: [EXT] RE: Charter

JSON is a must.

Allan Thomson
CTO (+1-408-331-6646)

Thanks,
Bret

Re-,

Please see inline.

Cheers,
Med

Bret

---

From: <[email-masked]>
Date: Thu, 20 Jun 2019 08:49:30 +0000

Hi Bret,

You didn’t answered my question : “Are you referring to application encoding or data modelling part?”.

In your reply, you are suggesting that versions can be considered … which implies that handling versioning will be a requirement. The data model should allow for such feature + easily allow to augment whatever initial version of that module. YANG, used for data modelling, makes a lot of sense here.

You also suggest that future encodings may be defined…which suggests that whatever solution that will be specified will need to handle such capability.

Cheers,
Med

De : Bret Jordan [mailto:[email-masked]]
Envoyé : mercredi 19 juin 2019 14:07
À : BOUCADAIR Mohamed TGI/OLN
Cc : Bret Jordan; Allan Thomson; [email-masked]
Objet : Re: [Cacao] [EXT] Re: [EXT] RE: Charter

Thanks,
Bret

Re-,

Please see inline.

Cheers,
Med

Bret

---

From: Bret Jordan <[email-masked]>
Date: Thu, 20 Jun 2019 14:06:56 +0200

Mohamed,

I am not sure I fully understand your question or what you are trying to get me to say.  As such I do not want to respond in a way that is going to be wrong.  So let me try and explain how I see this working and see if it resolves your question.

The data model will consist of a series of property tables that are defined using JSON data types. 

Example:

Property Name              | Type    | Description 
name (required)            | string  | The name of this action 
created (required)         | string  | The time that this action was created in RFC 3339
sequence_number (optional) | integer | The number ….. 

All examples will also be in JSON

{
  “name” : “deny ip”,
  “created” : “2019-06-20T12:12:12.123”,
  “sequence_number” : 1
}

All interoperability tests will require that tools support JSON.  

If someone want to take the property tables and write a solution for Protobuf, that is their choice.  But they would not be able to claim they are compliant or conformant with the spec if they do not support JSON.  The whole purpose is to get wide scale adoption. 

Thanks,
Bret

> On Jun 20, 2019, at 10:49 AM, [email-masked] wrote:
> 
> Hi Bret,
>  
> De : Bret Jordan [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc : Bret Jordan; Allan Thomson; [email-masked] <mailto:[email-masked]>
> On Jun 19, 2019, at 1:41 PM, [email-masked] <mailto:[email-masked]> wrote:
>  
> Re-,
>  
> Please see inline.
>  
> Cheers,
> Med
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 20 Jun 2019 14:44:29 +0200

> The data model will consist of a series of property tables that are defined using JSON data types. 

JSON does not define that many data types (copied exactly from RFC 8259:
   3.  Values  . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Objects . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Arrays  . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Strings . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
“Values” includes the “three literal names” false, null, and true beyond the other four).

> sequence_number (optional) | integer | The number ….. 

There is no such thing as an integer in JSON, so that is your own extension (JSON only has numbers).  If you think integers in JSON are a thing, you’ll be unpleasantly surprised at some point (the large number of surprises in this space led to RFC 7493).

Also, you seem to feel a need to qualify the second string as “RFC 3339”, which pollutes the “description” column with type information.
(And what you wrote is very inexact, compare with “format described by the `date-time` production in {{RFC3339}}, as refined by Section 3.3 of {{RFC4287}}”, which is what turned out we needed to write in a similar context.)

If you want to stick with tables instead of machine-readable form, I’m not going to argue against that right now(*).
I would still propose that you at least define the types used in these tables in a more well-defined way.  (RFC 8610 would work just about right for me here, but my point is more general: you want to have more structured information about the types employed, and you don’t want to mix it in, in an uncontrolled way, into the description.)

Grüße, Carsten

(*) In the long run, you will generate these tables from machine readable form.  
But this discussion isn’t at that level of detail right now…

---

From: Bret Jordan <[email-masked]>
Date: Thu, 20 Jun 2019 15:17:41 +0200

Thanks Carsten for pointing this out.. Please replace the following terms based on:

~=s/string/strings/g
~=s/integer/number/g

Also, we may define an “integers” property in the spec that uses the JSON numbers type. But that the spec itself limits the value to be an integer. 

Thanks,
Bret

> On Jun 20, 2019, at 2:44 PM, Carsten Bormann <[email-masked]> wrote:
>

---

From: Bret Jordan <[email-masked]>
Date: Thu, 20 Jun 2019 15:21:38 +0200

In regards to the timestamp, please understand I was just giving an example, not _actual_ spec text. I could see us defining a “timestamp” type and then saying that the “timestamp” type is an ISO 8601 / RFC 3339 timestamp that follows some very specific rules.  Just as an example.  Then in the property tables we should use “timestamp” instead of “strings”.  

I am not against also building a CDDL definition for this in an appendix or separate document.  But as of yet CDDL is not used en mass and there are not very many tools (other than your really cool ruby tools).  So for now it would be best to use property tables since that is what people understand today.

Thanks,
Bret

---

From: Joseph Salowey <[email-masked]>
Date: Thu, 20 Jun 2019 19:57:54 -0700

I think the intent is that the playbook is communicated is in JSON format
because format is this common to many of the tools and protocols in this
domain.  When we get to the point of specifying actions it seems that
action types in another native format such as yang could be represented in
the other native format and encapsulated within the JSON playbook.

On Thu, Jun 20, 2019 at 6:21 AM Bret Jordan <[email-masked]> wrote:

> In regards to the timestamp, please understand I was just giving an
> example, not _actual_ spec text. I could see us defining a “timestamp” type
> and then saying that the “timestamp” type is an ISO 8601 / RFC 3339
> timestamp that follows some very specific rules.  Just as an example.  Then
> in the property tables we should use “timestamp” instead of “strings”.
>
> I am not against also building a CDDL definition for this in an appendix
> or separate document.  But as of yet CDDL is not used en mass and there are
> not very many tools (other than your really cool ruby tools).  So for now
> it would be best to use property tables since that is what people
> understand today.
>
>
> Thanks,
> Bret
>   4.  Objects . . . . . . . .. . . . . . . . . . . . . . . . . . . .   6
>   5.  Arrays  . . . . . . . . . . . . . . . . . . . .. . . . . . . .   7
>   7.  Strings . . . . . . . .. . . . . . . . . . . . . . . . . . . .   8
> There is no such thing as an integer in JSON, so that is your own
> extension (JSON only has numbers).  If you think integers in JSON are a
> thing, you’ll be unpleasantly surprised at some point (the large number of
> surprises in this space led to RFC 7493).
>
> Also, you seem to feel a need to qualify the second string as “RFC 3339”,
> which pollutes the “description” column with type information.
> (And what you wrote is very inexact, compare with “format described by the
> `date-time` production in {{RFC3339}}, as refined by Section 3.3 of
> {{RFC4287}}”, which is what turned out we needed to write in a similar
> context.)
>
> If you want to stick with tables instead of machine-readable form, I’m not
> going to argue against that right now(*).
> I would still propose that you at least define the types used in these
> tables in a more well-defined way.  (RFC 8610 would work just about right
> for me here, but my point is more general: you want to have more structured
> information about the types employed, and you don’t want to mix it in, in
> an uncontrolled way, into the description.)
>
> Grüße, Carsten
>

---

From: <[email-masked]>
Date: Fri, 21 Jun 2019 05:19:34 +0000

Bret,

Please don’t get paranoid :-)

I raised that question because I suspect a disconnect between two of us. For example, when you say “YANG my take off at some point”, I don’t parse that especially in reference to my proposal to use YANG for data modeling * not * for application data encoding. The use of YANG will allow to easily map to JSON object, CBOR, etc.

I won’t reiterate the comments made by Carsten.

Cheers,
Med

Envoyé : jeudi 20 juin 2019 14:07

Mohamed,

Example:

{
  “name” : “deny ip”,

Thanks,
Bret

On Jun 20, 2019, at 10:49 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Bret,

Cheers,
Med

Cc : Bret Jordan; Allan Thomson; [email-masked]<mailto:[email-masked]>

Thanks,
Bret

Re-,

Please see inline.

Cheers,
Med

Bret

---

From: Bret Jordan <[email-masked]>
Date: Fri, 21 Jun 2019 10:20:54 +0200

Are you talking about writing a definition in YANG, similar to writing a definition in property tables or in CDDL / JSON Schema? 

Bret 

> On Jun 21, 2019, at 7:19 AM, <[email-masked]> <[email-masked]> wrote:
> 
> Bret,
>

---

From: "Jyoti Verma (jyoverma)" <[email-masked]>
Date: Fri, 21 Jun 2019 08:36:23 +0000

Hi Med,

I don’t see why YANG or any other modeling language couldn’t be used to model playbooks but defining the modeling spec such as any YANG models for CACAO should not be in scope for the working group IMO. The core of the work should be to define the data model for the playbooks in JSON along with the protocol for sharing them.

Thanks,
Jyoti

Date: Thursday, June 20, 2019 at 10:19 PM

Bret,

Cheers,
Med

Mohamed,

Example:

{
  “name” : “deny ip”,

Thanks,
Bret

Hi Bret,

Cheers,
Med

Thanks,
Bret

Re-,

Please see inline.

Cheers,
Med

Bret

---

From: <[email-masked]>
Date: Mon, 24 Jun 2019 13:04:00 +0000

Hi Jyoti,

I’m suggesting to use YANG for data modelling because it provides features that are useful for maintaining the model such as augmenting the module let alone reusing types that are defined in other existing modules. Furthermore, if in the future other data encoding schemes such as CBOR are to be supported, it will be easy to specify the appropriate mapping from YANG.

Cheers,
Med

De : Jyoti Verma (jyoverma) [mailto:[email-masked]]
Envoyé : vendredi 21 juin 2019 10:36
À : BOUCADAIR Mohamed TGI/OLN; Bret Jordan
Cc : Bret Jordan; [email-masked]; Allan Thomson
Objet : Re: [Cacao] [EXT] Re: [EXT] RE: Charter

Hi Med,

Thanks,
Jyoti

Bret,

Cheers,
Med

Mohamed,

Example:

{
  “name” : “deny ip”,

Thanks,
Bret

Hi Bret,

Cheers,
Med

Thanks,
Bret

Re-,

Please see inline.

Cheers,
Med

Bret