Re: [Suit] Manifest-07 review

Brendan Moran <Brendan.Moran@arm.com> Tue, 30 June 2020 10:35 UTC

Return-Path: <Brendan.Moran@arm.com>
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 2F8003A1185 for <suit@ietfa.amsl.com>; Tue, 30 Jun 2020 03:35:58 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=J7JxXoS4; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=J7JxXoS4
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 pc4hkJwQv5oQ for <suit@ietfa.amsl.com>; Tue, 30 Jun 2020 03:35:55 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70074.outbound.protection.outlook.com [40.107.7.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A81763A1181 for <suit@ietf.org>; Tue, 30 Jun 2020 03:35:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V0hC5D4B+UqQXTFsSfCfyxhrYbd0iekSmnypjFO0JNM=; b=J7JxXoS4DRTNr84EOAbO1V1D+UeYDKbJufJRvNc25lRdMUNump2kNMkZD7z0wq3sqxEKBP+tTvjp8jdu7x8JoKNNSCRouRQlDGjU8dy4bqA7pZZ7OVRvi8vtKUPadKuHHTJl8iXcs8qB26SA2Z63ItbYB433PDN376q12Rc70Ec=
Received: from AM6P192CA0028.EURP192.PROD.OUTLOOK.COM (2603:10a6:209:83::41) by AM0PR08MB3922.eurprd08.prod.outlook.com (2603:10a6:208:128::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21; Tue, 30 Jun 2020 10:35:51 +0000
Received: from VE1EUR03FT062.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:83:cafe::fb) by AM6P192CA0028.outlook.office365.com (2603:10a6:209:83::41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Tue, 30 Jun 2020 10:35:51 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT062.mail.protection.outlook.com (10.152.18.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Tue, 30 Jun 2020 10:35:50 +0000
Received: ("Tessian outbound 1e00bf306733:v60"); Tue, 30 Jun 2020 10:35:50 +0000
X-CheckRecipientChecked: true
X-CR-MTA-CID: 11157992d7877a90
X-CR-MTA-TID: 64aa7808
Received: from 4edace0bb6eb.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id CB09D7E1-49D4-4A34-AB6F-2326B0BF809F.1; Tue, 30 Jun 2020 10:35:45 +0000
Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 4edace0bb6eb.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 30 Jun 2020 10:35:45 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A3bDG4YUTDoSrijtwBxTNT/THNWeMDeQ7axsUnEzAJSH8cw387dmc/gvDa8ztQ/lgq5L22ARwbIykxmtL3Zi5cw+lQjYblmFBCKBtqLCX2dy7DgtTUDKSNaIPKvIPKGItog6xfbzN6fh+l9i/aj/xBUAskQqkNv4/OfGV1ERZGHrAWrI+DzeXlwe5LMHClpYXOebMwfmKbDslnc0xfhunwhW464fRh32XJFLQOBYKuHkGBOwwstnQklLDwBTYtK3IFHKAj4uxifLW6LoIxdO+kloPwjWVIkRHTEQN4WfFAI+cnRfzWNIp/ngHJ5TxxLPDQQ8dJJuaxvWhv24uPLTfA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V0hC5D4B+UqQXTFsSfCfyxhrYbd0iekSmnypjFO0JNM=; b=kh7T7RmBQrMk5quzoUT/QtbNy/MlRivGrPXJc+7++pOoGDUwR72FzApQ/vywxQHIoUUBAX0giFWnY+KqTHhbCKtrERVxlVMqkAgCfbwHNowZJMBToyZW+oXHZp7rjBBXKLtCmu6R2o42tPQr+Dofu4wpjARkxSt4MmXOXXijSsSV2c9s3p9+RudhxEgDV4UfVp/+5xBIXFiTfggEXXCHIrwwjkKfHzQie4mjYiW//FxWiamHtfW3LP8T+m/kxPejUQoCOk+LbL4aaeh+/ubvls6cpcppH9jtvPc+dU5c+xihwF8HEWvVGFOVXvAf8orAB3DhVZMLsq73owxWwlSAuw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=V0hC5D4B+UqQXTFsSfCfyxhrYbd0iekSmnypjFO0JNM=; b=J7JxXoS4DRTNr84EOAbO1V1D+UeYDKbJufJRvNc25lRdMUNump2kNMkZD7z0wq3sqxEKBP+tTvjp8jdu7x8JoKNNSCRouRQlDGjU8dy4bqA7pZZ7OVRvi8vtKUPadKuHHTJl8iXcs8qB26SA2Z63ItbYB433PDN376q12Rc70Ec=
Received: from AM6PR08MB4738.eurprd08.prod.outlook.com (2603:10a6:20b:cf::10) by AM6PR08MB4359.eurprd08.prod.outlook.com (2603:10a6:20b:b9::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.23; Tue, 30 Jun 2020 10:35:44 +0000
Received: from AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::208a:431d:b171:9615]) by AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::208a:431d:b171:9615%3]) with mapi id 15.20.3131.028; Tue, 30 Jun 2020 10:35:44 +0000
From: Brendan Moran <Brendan.Moran@arm.com>
To: =?utf-8?B?w5h5dmluZCBSw7hubmluZ3N0YWQ=?= <Oyvind.Ronningstad@nordicsemi.no>
CC: suit <suit@ietf.org>
Thread-Topic: [Suit] Manifest-07 review
Thread-Index: AdZJ/dxWDAt2IAgGSk6bbwUyoDHNSgEzFhyA
Date: Tue, 30 Jun 2020 10:35:44 +0000
Message-ID: <DAD072A3-0088-486F-8C86-DBA7C3467C2F@arm.com>
References: <AM0PR05MB4339D51F857444D08ECAC41888950@AM0PR05MB4339.eurprd05.prod.outlook.com>
In-Reply-To: <AM0PR05MB4339D51F857444D08ECAC41888950@AM0PR05MB4339.eurprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.80.23.2.2)
Authentication-Results-Original: nordicsemi.no; dkim=none (message not signed) header.d=none; nordicsemi.no; dmarc=none action=none header.from=arm.com;
x-originating-ip: [82.20.19.206]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 54246d86-4d23-4850-624d-08d81ce15c03
x-ms-traffictypediagnostic: AM6PR08MB4359:|AM0PR08MB3922:
X-Microsoft-Antispam-PRVS: <AM0PR08MB392205DDD7362B01A3AEFD83EA6F0@AM0PR08MB3922.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000;
x-forefront-prvs: 0450A714CB
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: ER6lM93whml5Eu8novIY+59qf5YyhiOpj9SaXt7vdOJlgNc/3xw+pdjQE4zPyTXQvQzPT32GGbdf5194JCayAAR6q+HAFxMktNnghoRXCRcWMgEHLC9D/BUcNzx/oXXu3vxKW4bTpVV6HBwJPKr4wt3MUGlgdgNgRCTSEaShgtSVKXN/tYtvgozWuE5ZjdFmKns7I6RaNSfFtSRykunMeXfJ4EVdf09NWTnRur+mp7+CY52x2NIGSbZMLNWBMU8GfmLCGt5yR8bMsg6s0aZbFcGs42gjik2rHsKvMD+Y1SmHaYFEMTwvoX/cox+/zAgsw8loVa7rvH1cuw2ZIXmMJsbyK3x5vGWSVg9lUsRiLXCUEf0wLFJP7Vg6op2lPA3iOACtreKz47TL5yf3ywq05Q==
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4738.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(376002)(39860400002)(346002)(366004)(186003)(36756003)(66556008)(64756008)(66446008)(66476007)(83380400001)(91956017)(66946007)(5660300002)(76116006)(166002)(66574015)(316002)(86362001)(6512007)(6486002)(33656002)(4326008)(8676002)(966005)(26005)(53546011)(6506007)(2616005)(2906002)(8936002)(71200400001)(6916009)(478600001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: TXQE+byMt/+b+LcIByndc3zQDfR0vxUBTZN8DjEyfPwL0zM5VNiHLQsbiuILd8XUwRfD76QD+UcbrRqb/ckd+G2ePH7v6boUpXnLScvEu+e+z9pvSKBo7jkwnInhrdV7vn3e9VAAnlQ1gdd5iS+o0xDtJ2hdzdG3XYnuNKBZhRYrd04k4qYlnWqVIDu3B/lfd03RiVhA3wPedINe8zA7pF/HN0i4E+qdFNFqxtqAgEpvq//G6yDqp/D+5JQKsv6l3u8spkMbAXOdQckrfTyJfxtTTTx+8qy4IiYMO5So4brmmi2RkNy6ffHGNeLB32BBHUOORVXcj2/OIFDB+JY7LtdwGK9aJo94gOy9PtRMJ+fThRPJcfvf9nTYO9WRyC9VxSYWDax1enljt4TkQ3swNEwW5hAGw9vIfQW7W/SmH+svVOP3wsn+6APlxefi71spbiZJuIcXwqmizULLKPi8JCs3yX9/9kdgGqdQt5dEBL8=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DAD072A30088486F8C86DBA7C3467C2Farmcom_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4359
Original-Authentication-Results: nordicsemi.no; dkim=none (message not signed) header.d=none; nordicsemi.no; dmarc=none action=none header.from=arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT062.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(346002)(376002)(39860400002)(46966005)(8676002)(966005)(4326008)(166002)(316002)(5660300002)(70586007)(70206006)(36906005)(82310400002)(356005)(82740400003)(478600001)(47076004)(81166007)(6486002)(8936002)(336012)(26005)(2906002)(33656002)(6862004)(36756003)(86362001)(6512007)(2616005)(186003)(66574015)(45080400002)(83380400001)(30864003)(33964004)(53546011)(6506007); DIR:OUT; SFP:1101;
X-MS-Office365-Filtering-Correlation-Id-Prvs: 3f961f92-1368-499c-05cc-08d81ce15803
X-Forefront-PRVS: 0450A714CB
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: /FU2acdt9wLPKTFgCFYf33N8ngDeOdCUP6EjHv4xkXd586n66YI/kXBkE0bI5fUiOUTSlFYQHm7X00hyI1QEsWKfeL/xaTTJhfTdDVXpSiM/uYQ6psTxSBtKcYbT0qVxUrr6P3v5OjlLDt8s/Y+6McOjk7p5K2zRVH31Op+f/9G2jW/B5yIq3hcMxRhoM8QaOlft1cEfE3zzmwuHyz4dmRK5cax33jud4Z+cNusGIkC23Uqs2HS2Jgg57If0Oeljw0Ebwc4kFAUlplBfBc49FBDXcS46C1TgQu2S7J0kVvWZ1b/FhydVvGa6fXOFS2FSEBgGf979ystveAZYQ13CPOfwj6+taIlTp+R7wewLKZ2Z7gDrl8fFhV+6rKkmY4c8T9crTN+0Ips90wyJoltinWUTUo1OpRXVgECoU/YCno9rTQzz4N9xd+wgI3loHYxe6QxXoF3cS6H1r13FQE39zqqxCz0U72NK5WRYgNiSKgQ=
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jun 2020 10:35:50.8280 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 54246d86-4d23-4850-624d-08d81ce15c03
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT062.eop-EUR03.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3922
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/krFfRaXhFhRu3l1_c8N-70wWqtk>
Subject: Re: [Suit] Manifest-07 review
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, 30 Jun 2020 10:35:58 -0000

Hi Øyvind,

Thank you for the thorough review!

Here is the pull request for your comments: https://github.com/suit-wg/manifest-spec/pull/26

Best Regards,
Brendan

On 24 Jun 2020, at 11:03, Rønningstad, Øyvind <Oyvind.Ronningstad@nordicsemi.no<mailto:Oyvind.Ronningstad@nordicsemi.no>> wrote:

Hi guys, here is a review of manifest-07. Mostly small stuff.

Questions:
.. Section 6.4: What are the guidelines for extracting the vendor-id, class-id, device-id, or version of a component?

I’m not sure I understand the context of the question. Who is performing the extraction? And from what? I’m going to assume that you are looking for guidelines for what the parser should do to find the local values that it matches against. If that is not correct, then please disregard the paragraph below!

The extraction of vendor-id, class-id, device-id, and component-id are application specific. They may be coded into the device’s firmware image. They may be coded into some metadata about the component. They may be stored within or alongside a security policy such, as an ACL, that the parser uses to validate the manifest actions. They may also be stored in a database that the device uses for generic configuration. Of these options, I have seen both the hard-coded option and the config-database option deployed. I could add some guidance to the text; would that be helpful?


.. Suit-condition-component-offset is used in an example, but marked as TBD in its section. I see that it is described in 6.4 as "assert(offsetof(component) == arg)". What are the semantics of "offsetof"?

There is a clarification open in a PR on GitHub here: https://github.com/suit-wg/manifest-spec/pull/25/files#diff-4af21d7ed1750009d053675328dd1b85R869
Is it clear enough, or should I provide more precise semantics?

.. Can suit-directive-process-dependency be done on a component, or just on a dependency? Generally, there seems to be some mismatch between the description in 6.4 (which implies that most directives and conditions only apply to a component index) and textual descriptions e.g. in 9.8.4.1 and 9.8.4.2 (which imply that directives and conditions apply to whichever is available of component index and dependency index).

Directives and conditions apply to either a component OR a dependency. I will clarify that.


.. (It would be very beneficial to make 6.4 "Abstract Machine Description" more prominent, e.g. by linking from the individual section for commands, since 6.4 contains very useful info about how the commands work, and it's hard to discover otherwise.)

Good idea.

.. What (if any) are the rules regarding when to perform dependency-resolution, payload-fetch, and install, and when to perform only validate, load, and run?

Section 4.2: Update Workflow Model, covers this. Is there a way that I could make this clearer?

.. suit-manifest-sequence-number: "Each Recipient MUST reject any manifest that has a sequence number lower than its current sequence number." Are there several "current sequence number"s or just one for each SUIT processor. Exactly when is the "current sequence number" updated?

The most important sequence number is the one in the root manifest because it is used by the bootloader/updater to decide whether or not to process any manifests in a tree.

Beyond that, it seems to me that rollback protection should extend to individual components. This is to make sure that the signer of the root manifest cannot force the rollback of a leaf component. Maybe sequence number should be a component parameter? I don’t think so, but I’m open to suggestions!

.. What should the processor do when waiting on a suit-directive-wait? Can it be interpreted as "try again later", or "busy wait"?

I don’t think this needs to be mandated in the specification. Any of these options would be acceptable. The intent was reactive: the manifest processing should resume or restart when the specified event occurs.

.. There are important limitations to what sort of commands can be in suit-common. Could the limitations be reflected in the CDDL? It seems like a natural thing to do, to make the limitations more prominent.

I think this is reasonable. I’ll make a more restrictive CDDL for Common.

.. When processing dependencies, how do we know when to a) expect a signature and b) check the signature on a dependency manifest?

This comes down to an ACL. The root manifest MUST be signed. Other signatures are only necessary where the authority of the root manifest signer is inadequate to confer the rights required to satisfy the device’s ACL.

.. Did we mean for short payloads to be embeddable in the manifest (I can't find this)? This would be very useful for setting configuration options via SUIT manifests.

Yes, this is absolutely intended. There is a discussion of size tradeoffs present in the Information Model. I’ve added a block of text to the manifest template section to explain how to handle this.

.. Is the device-identifier unique for each individual device, or for a collection of devices?

Device identifiers were intended to be unique per device, but we found little use for them in firmware update in general. Because of this, they are not well-defined in the specification. If there is a desire for tighter refinement of Device IDs, then please let me know.

.. Why are suit-directive-set-component-index and suit-directive-set-dependency-index not implemented through set-parameters? Are they subject to the same override mechanics? If not, it might be confusing with suit-parameter-source-component, which seems to be analogous to set-component-index, but might have subtly different behavior because of override mechanics.

Set Component Index and Set Dependency Index effectively define which set of parameters to use. Because of this, they cannot be parameters, which is why they are separate. I do wonder if we could reduce this complexity slightly by changing the name to “set current” and making dependencies to negative numbers. It might also make “set source component” clearer, since it is only used to define the origin of a suit-directive-copy operation.


Nits:
.. Suit-directive-fetch: "manifest-index" is not referred to elsewhere in the document.

Fixed

.. Section 7: Suggested edit in bold: "A digest should always be set using Override Parameters, since this prevents a less-privileged dependent OR dependency from replacing the digest."

Fixed

.. suit-condition-update-authorized seems like it could use some metadata to help determine what is being authorized, e.g. A human readable prompt if user interaction is required, or an identifier if multiple instances of the condition are used in a manifest.

The original intent of suit-condition-update-authorized was to use a priority identifier (suit-parameter-update-priority) to provide an arbitrating applicaiton to determine whether to allow the update to proceed. The rough idea was that reliability and security fixes might be worth halting a device, while new features might be declined until later.

It sounds like you are discussing a new use-case that requires additional information. We could change suit-parameter-update-priority from uint to:

{
? identifier => int,
? priority => uint,
? description => tstr,
}

Or similar. This is one case where it might be appropriate to include text outside the text section if it’s to be used for on-device user interaction.




Thanks for the good work,

Øyvind

_______________________________________________
Suit mailing list
Suit@ietf.org<mailto:Suit@ietf.org>
https://www.ietf.org/mailman/listinfo/suit

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.