Re: [Cacao] Call for CACAO Charter Consensus

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 24 May 2019 03:16 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 D4F1B120088 for <cacao@ietfa.amsl.com>; Thu, 23 May 2019 20:16:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 aPoQHuajTL-E for <cacao@ietfa.amsl.com>; Thu, 23 May 2019 20:16:17 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7BC11200FD for <cacao@ietf.org>; Thu, 23 May 2019 20:16:17 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 0049F380BE for <cacao@ietf.org>; Thu, 23 May 2019 23:15:17 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 4A43BC09; Thu, 23 May 2019 23:16:13 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 47B43AA4 for <cacao@ietf.org>; Thu, 23 May 2019 23:16:13 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: cacao <cacao@ietf.org>
In-Reply-To: <16ae05d913e.c75683dd278058.2765926039818296187@nerd.ninja>
References: <CAOgPGoAkj_QqPUzZe+O1W3f=P=EqARE5GCu6kMeO76kBWUK27A@mail.gmail.com> <727F25EC-DD08-4A81-957C-072AC94FF6B9@gmail.com> <16ae05d913e.c75683dd278058.2765926039818296187@nerd.ninja>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Thu, 23 May 2019 23:16:13 -0400
Message-ID: <23404.1558667773@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cacao/lTTDX60iWQ77YDW52FI2BjgzAq0>
Subject: Re: [Cacao] Call for CACAO Charter Consensus
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: Fri, 24 May 2019 03:16:20 -0000

In general, I think that the charter is probably okay, but I feel that my
concerns below should be addressed early in the WG process.

I have some difficulties understanding the "protocol" part of the charter,
which I have clipped below the questions.

    > 1.  Do you support this charter text (full text also provided at the
    > end of email or at [1])?  Please submit objections or blocking concerns
    > to the list.

I feel very uncertain about what shape some of the products of the WG will take.

    > 2.  Are you willing to author or participate in the development of the
    > drafts of this WG?

Not sure, I am concerned that there will be many references to other SDOs whose
documents are not freely available, and this will significantly reduce
understanding.  I.e. I may be simply unable to author or participate.

    > 3.  Are you willing to help review the drafts of this WG?

See above.

    > 4.  Are you interested in implementing drafts of this WG?

Yes.


    > 3. the sharing and distribution of COAs across organizational
    > boundaries and technology stacks that may include PROTOCOLS, apis,
    > interfaces and other related technology to support sharing.

...

    > This solution will contain (at a minimum) a standard JSON based data
    > model, a defined set of functional capabilities and associated
    > interfaces, and a PROTOCOL. This solution will also provide a data
    > model for systems to confirm the status of the COA execution, however,
    > it will be agnostic of how the COA is implemented by the system.

====

What I understand from the below is that I2NSF will provide the underlying
functions for the playbooks to invoke.  We won't have to invent an
abstraction of a router and firewall, because I2NSF already has done that.

    > Where possible the working group will consider existing efforts, like
    > OASIS OpenC2 and IETF I2NSF that define the atomic actions to be
    > included in a process or sequence. The working group will not consider
    > how shared actions are used/enforced, except where a response is
    > expected for a specific action or step.


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