Re: [Cacao] [EXT] Re: [EXT] RE: Charter

["Jyoti Verma (jyoverma)" <[e-mail]>]

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

From: Cacao <[e-mail]> on behalf of "[e-mail]" <[e-mail]>
Date: Thursday, June 20, 2019 at 10:19 PM
To: Bret Jordan <[e-mail]>
Cc: Bret Jordan <[e-mail]>, "[e-mail]" <[e-mail]>, Allan Thomson <[e-mail]>
Subject: Re: [Cacao] [EXT] Re: [EXT] RE: Charter

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

De : Bret Jordan [mailto:[e-mail]]
Envoyé : jeudi 20 juin 2019 14:07
À : BOUCADAIR Mohamed TGI/OLN
Cc : Bret Jordan; Allan Thomson; [e-mail]
Objet : Re: [Cacao] [EXT] Re: [EXT] RE: Charter

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
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 20, 2019, at 10:49 AM, [e-mail]<mailto:[e-mail]> wrote:

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:[e-mail]]
Envoyé : mercredi 19 juin 2019 14:07
À : BOUCADAIR Mohamed TGI/OLN
Cc : Bret Jordan; Allan Thomson; [e-mail]<mailto:[e-mail]>
Objet : Re: [Cacao] [EXT] Re: [EXT] RE: Charter

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
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 19, 2019, at 1:41 PM, [e-mail]<mailto:[e-mail]> wrote:

Re-,

Please see inline.

Cheers,
Med

De : Bret Jordan [mailto:[e-mail]]
Envoyé : mercredi 19 juin 2019 13:26
À : BOUCADAIR Mohamed TGI/OLN
Cc : Allan Thomson; Bret Jordan; [e-mail]<mailto:[e-mail]>
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.

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

Bret
Sent from my Commodore 128D