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

Bret Jordan <jordan.ietf@gmail.com> Wed, 19 June 2019 10:36 UTC

Return-Path: <jordan.ietf@gmail.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 62AA41200C1 for <cacao@ietfa.amsl.com>; Wed, 19 Jun 2019 03:36:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 T1RNFKkPF1IT for <cacao@ietfa.amsl.com>; Wed, 19 Jun 2019 03:36:19 -0700 (PDT)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2440D120130 for <cacao@ietf.org>; Wed, 19 Jun 2019 03:36:17 -0700 (PDT)
Received: by mail-wm1-x330.google.com with SMTP id a15so1167645wmj.5 for <cacao@ietf.org>; Wed, 19 Jun 2019 03:36:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6sL1af0mlQba2RNQSuEAd/Abk6Pn0vIKKd5TzGnNZ6Y=; b=AxkkJoicgBHH5FWmesAonW0dfdz+EnC4IRXb6DUYvsNdgyTdXWLQNj+f2gcCVmgwQM +TNNlAXtttZmOOcy524Tzlan+Mr1H0JhRAHPPuUL4N8rf9N3BygKUVmImrZzp0d2U0yp Yi3BQQEQ+TL8O2CQiJuYPAUrnUYQ0NHKI9SMLfkZRzhgPBwyd9dNONbC/SJtwnWhaPIf sjZyLX46CvpE3A9mxevS1mGQj0XlRYMGINbSParhAGcCiTJSGNFSRgJDzYmjqKQEFo57 jr4wgBRuEDrhlbT1rItSKP0A/T32MPLdAIqnjXI4drHbvZsQy6WY/SopETdrtPOdAifr U3eg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=6sL1af0mlQba2RNQSuEAd/Abk6Pn0vIKKd5TzGnNZ6Y=; b=FUAsXzhRacyz2D1QHQu1NhPtvCffUtnDjUQz2RJhgNwvFhErmbXDGpmT9kf9Y/D+5k 8lplP0UO6gWo6l/moGlMHO4q9t4b/+eGYbVoGT9EWuAct0Spfb+nuXIFPA1RGoi19v1B fgA9hFAtWaHP3n9HOGpSvz9ceokpnG66EOVpGGQkCPJg/3ufhMgCUq5eR8vzZKLEYk3B vUpYifezEj2qSAKhsxHhVF7kmXUewR+p87aWtxHJMMgpvQvtaO0s8aH7jPKUYk3NxnSN I8Y8Pqm0urv1/4+n6zBgPrMDVhZTGdIUZsdWlCMyGX9EtAhXMn96zuiblw2saEL4Jd+z svFg==
X-Gm-Message-State: APjAAAXXbLFqEsjm7To4PK5EMY/AlKHYYEqKbqWqzJjCKmeFCyoIdd+j kXK7ceyGRfNPWp5RgQea9OvZPxnB
X-Google-Smtp-Source: APXvYqyvGB6IN1TeRFicJDWPKDBqUzY+PZh9PoHRehDbrSnWTso85tiwfYha0md7Lm9JCVltPy0UCg==
X-Received: by 2002:a7b:cae9:: with SMTP id t9mr7670759wml.126.1560940575435; Wed, 19 Jun 2019 03:36:15 -0700 (PDT)
Received: from [10.0.2.44] (26.34.71.37.rev.sfr.net. [37.71.34.26]) by smtp.gmail.com with ESMTPSA id v18sm11520613wrs.80.2019.06.19.03.36.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Jun 2019 03:36:14 -0700 (PDT)
From: Bret Jordan <jordan.ietf@gmail.com>
Message-Id: <BA34A9CC-9069-427F-A42A-67FE760FEF7F@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_710798A0-E778-4206-BDEA-98E67BAC2983"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 19 Jun 2019 12:35:59 +0200
In-Reply-To: <05E3F9C3-20C6-47E4-9B68-DE9D81D9C358@lookingglasscyber.com>
Cc: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "cacao@ietf.org" <cacao@ietf.org>
To: Allan Thomson <athomson@lookingglasscyber.com>
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>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cacao/YqAX3GxQ8WVGahqii7drD0bYmP4>
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 10:36:25 -0000

Agreed.

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




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 12:02 PM, Allan Thomson <athomson@lookingglasscyber.com> 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 <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 <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 <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 <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 <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 <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 <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 <https://clicktime.symantec.com/36NaSMAoRn4patyVkcWPUUX7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcacao>