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

<mohamed.boucadair@orange.com> Wed, 19 June 2019 11:41 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: cacao@ietfa.amsl.com
Delivered-To: cacao@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FAE120100 for <cacao@ietfa.amsl.com>; Wed, 19 Jun 2019 04:41:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.609
X-Spam-Level:
X-Spam-Status: No, score=-0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvfO1f8zXJQc for <cacao@ietfa.amsl.com>; Wed, 19 Jun 2019 04:41:31 -0700 (PDT)
Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9841B12004A for <cacao@ietf.org>; Wed, 19 Jun 2019 04:41:30 -0700 (PDT)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 45TNMD6cRqzCvMw; Wed, 19 Jun 2019 13:41:28 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 45TNMD5PQ8z1xpk; Wed, 19 Jun 2019 13:41:28 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM8F.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Wed, 19 Jun 2019 13:41:28 +0200
From: mohamed.boucadair@orange.com
To: Bret Jordan <Bret_Jordan@symantec.com>
CC: Allan Thomson <athomson@lookingglasscyber.com>, Bret Jordan <jordan.ietf@gmail.com>, "cacao@ietf.org" <cacao@ietf.org>
Thread-Topic: [Cacao] [EXT] Re: [EXT] RE: Charter
Thread-Index: AQHVJeIG5tXJhvBcAk+LdtRmxEcngqaheQuAgACC9ICAAI2iPYAAB5qggAANPICAAArHgIAAF0qAgAATCoCAAAQV2YAAAWZA
Date: Wed, 19 Jun 2019 11:41:27 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EAA91C9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <BYAPR16MB30133C3DAF3CF2060CE4B565EDEA0@BYAPR16MB3013.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EAA890F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB30137AC9C00633E80C7C8D65EDEA0@BYAPR16MB3013.namprd16.prod.outlook.com> <779CCF55-FABB-4BA1-9D84-1D9761A32944@tzi.org> <BYAPR16MB30139D44233E0256099264DCEDEA0@BYAPR16MB3013.namprd16.prod.outlook.com> <25088b69-1225-3f3c-b0e2-38e25f1f48fb@article19.org> <A7038D6C-C1C3-4B6A-B928-AC87F7A87AFC@gmail.com> <6130.1560896363@dooku.sandelman.ca> <634A811D-3674-42ED-A46F-9CDD8EFD5CEE@symantec.com> <787AE7BB302AE849A7480A190F8B93302EAA8FE0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <B29832F6-8239-498C-A65D-A22B70A4A691@gmail.com> <787AE7BB302AE849A7480A190F8B93302EAA905B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <05E3F9C3-20C6-47E4-9B68-DE9D81D9C358@lookingglasscyber.com>, <787AE7BB302AE849A7480A190F8B93302EAA917C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <92A6388D-ED3D-4B77-BA01-AE97E201681F@symantec.com>
In-Reply-To: <92A6388D-ED3D-4B77-BA01-AE97E201681F@symantec.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302EAA91C9OPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cacao/KwALhQ3rmRbBJ-CgvRy1mCeo-MQ>
Subject: Re: [Cacao] [EXT] Re: [EXT] RE: Charter
X-BeenThere: cacao@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Collaborative Automated Course of Action Operations <cacao.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cacao>, <mailto:cacao-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cacao/>
List-Post: <mailto:cacao@ietf.org>
List-Help: <mailto:cacao-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cacao>, <mailto:cacao-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jun 2019 11:41:35 -0000

Re-,

Please see inline.

Cheers,
Med

De : Bret Jordan [mailto:Bret_Jordan@symantec.com]
Envoyé : mercredi 19 juin 2019 13:26
À : BOUCADAIR Mohamed TGI/OLN
Cc : Allan Thomson; Bret Jordan; cacao@ietf.org
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


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

On Jun 19, 2019, at 1:12 PM, "mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>" <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:
Hi Allan,

Please see inline.

Cheers,
Med

De : Cacao [mailto:cacao-bounces@ietf.org] De la part de Allan Thomson
Envoyé : mercredi 19 juin 2019 12:03
À : BOUCADAIR Mohamed TGI/OLN; Bret Jordan
Cc : cacao@ietf.org<mailto:cacao@ietf.org>
Objet : Re: [Cacao] [EXT] Re: [EXT] RE: Charter


  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.

[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)
LookingGlass Cyber Solutions<https://clicktime.symantec.com/3TPG1wu5tqoSYv5eMV62nnc7Vc?u=http%3A%2F%2Fwww.lookingglasscyber.com%2F>

From: Cacao <cacao-bounces@ietf.org<mailto:cacao-bounces@ietf.org>> on behalf of "mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>" <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>
Date: Wednesday, June 19, 2019 at 1:40 AM
To: Bret Jordan <jordan.ietf@gmail.com<mailto:jordan.ietf@gmail.com>>
Cc: "cacao@ietf.org<mailto:cacao@ietf.org>" <cacao@ietf.org<mailto:cacao@ietf.org>>
Subject: Re: [Cacao] [EXT] Re: [EXT] RE: Charter

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:cacao-bounces@ietf.org] De la part de Bret Jordan
Envoyé : mercredi 19 juin 2019 10:01
À : BOUCADAIR Mohamed TGI/OLN
Cc : cacao@ietf.org<mailto:cacao@ietf.org>
Objet : Re: [Cacao] [EXT] Re: [EXT] RE: Charter

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
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 9:24 AM, <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote:

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:cacao-bounces@ietf.org] De la part de Bret Jordan
Envoyé : mercredi 19 juin 2019 08:46
À : Michael Richardson
Cc : cacao@ietf.org<mailto:cacao@ietf.org>; Bret Jordan
Objet : Re: [Cacao] [EXT] Re: [EXT] RE: Charter

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




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

On Jun 19, 2019, at 12:19 AM, Michael Richardson <mcr+ietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca>> wrote:

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

Bret Jordan <jordan.ietf@gmail.com<mailto:jordan.ietf@gmail.com>> 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




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
<amelia@article19.org<mailto:amelia@article19.org>> wrote:






   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 <cabo@tzi.org<mailto:cabo@tzi.org>> *Sent:* Tuesday, June
18, 2019 7:41:20 AM *To:* Bret Jordan *Cc:*
mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; cacao@ietf.org<mailto:cacao@ietf.org> *Subject:* [EXT] Re:
[Cacao] [EXT] RE: Charter




       On Jun 18, 2019, at 14:24, Bret Jordan
<Bret_Jordan=40symantec.com@dmarc.ietf.org<mailto:Bret_Jordan=40symantec.com@dmarc.ietf.org>> 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.




       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







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




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




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




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







----------------------------------------------------
Alternatives:




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

--
Michael Richardson <mcr+IETF@sandelman.ca<mailto:mcr+IETF@sandelman.ca>>, Sandelman Software Works
-= IPv6 IoT consulting =-



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

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