Re: [Suit] SUIT rechartering: proposed text

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 16 February 2021 22:39 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824893A1221 for <suit@ietfa.amsl.com>; Tue, 16 Feb 2021 14:39:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 rhf1JNz0etnd for <suit@ietfa.amsl.com>; Tue, 16 Feb 2021 14:39:57 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040FE3A11D6 for <suit@ietf.org>; Tue, 16 Feb 2021 14:39:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 4FA70389C1; Tue, 16 Feb 2021 17:43:37 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hOmSK4kQcnHl; Tue, 16 Feb 2021 17:43:36 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 454FF389C0; Tue, 16 Feb 2021 17:43:36 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 213391F9; Tue, 16 Feb 2021 17:39:54 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Brendan Moran <Brendan.Moran@arm.com>, suit <suit@ietf.org>
In-Reply-To: <3E7D5E5B-03EE-4EDD-A951-FB119F72DDE8@arm.com>
References: <66D84CE5-22E6-44F0-8239-8A5832326219@arm.com> <3E7D5E5B-03EE-4EDD-A951-FB119F72DDE8@arm.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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-sha512; protocol="application/pgp-signature"
Date: Tue, 16 Feb 2021 17:39:54 -0500
Message-ID: <16339.1613515194@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/ySFt2UvskgcFB_UvrgiPNJkf870>
Subject: Re: [Suit] SUIT rechartering: proposed text
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Feb 2021 22:40:00 -0000

Brendan Moran <Brendan.Moran@arm.com> wrote:
    bm> As a part of proposing several new drafts, I was asked to propose some new charter text that would enable the working group to address the new drafts.

    bm> The drafts in question are:

    bm> * draft-moran-suit-mud
    bm> * draft-moran-suit-report
    bm> * draft-birkholz-rats-suit-claims (TBD, maybe SUIT, maybe RATS)

As a RATS architecture editor, I prefer to do this document in SUIT.
Sure, RATS should be consulted, but the expertise in getting the claim
written right exists in SUIT, not RATS.

    bm> draft-moran-suit-mud proposes a method to anchor MUDs with the same
    bm> trust and fetch mechanisms as SUIT.

    bm> draft-moran-suit-report proposes a document format for reporting the
    bm> results of applying a SUIT update or secure execution using a SUIT
    bm> manifest.

    bm> draft-birkholz-rats-suit-claims proposes number assignments for EAT
    bm> claims that contain evidence generated during execution of a SUIT
    bm> manifest.

    bm> I would like to add a single paragraph to the charter:

    >> To support the manifest format(s) defined by this group, it will also define
    >> formats that enable precursor or successor operations around the use of
    >> the manifests. Additional specifications of names or numbers will enable
    >> the use of manifests, their precursors, and their successors within
    >> existing or future protocols.

That seems like fine text.
I am not sure that an external reviewer will understand how it implies that
three documents are in scope.  It may be just too abstract for some IESG
members.  The trend seems to be that charters are very specific.
I think that the "precusor or successor operations" is the part that might be
too abstract.  Maybe that part should spell out what you want.

} To support the manifest format(s) defined by this group, it will also
} define formats and protocols that enable a Status Tracker to determine if a
} particular manifest could be successfully deployed to a device, and
} determine if an operation was successful.
} Additional specifications of names or numbers will enable the use of
} manifests, their precursors, and their successors within existing or future protocols.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide