[Suit] Murray Kucherawy's Discuss on draft-ietf-suit-manifest-25: (with DISCUSS and COMMENT)
Murray Kucherawy via Datatracker <noreply@ietf.org> Thu, 29 February 2024 15:04 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: suit@ietf.org
Delivered-To: suit@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5DCC14F700; Thu, 29 Feb 2024 07:04:29 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Murray Kucherawy via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-suit-manifest@ietf.org, suit-chairs@ietf.org, suit@ietf.org, David Waltermire <david.waltermire@nist.gov>, housley@vigilsec.com
X-Test-IDTracker: no
X-IETF-IDTracker: 12.6.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Murray Kucherawy <superuser@gmail.com>
Message-ID: <170921906963.21487.18048828972516651200@ietfa.amsl.com>
Date: Thu, 29 Feb 2024 07:04:29 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/GEQs15OJCscGiQ-ZqWV2giwO064>
Subject: [Suit] Murray Kucherawy's Discuss on draft-ietf-suit-manifest-25: (with DISCUSS and COMMENT)
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 29 Feb 2024 15:04:29 -0000
Murray Kucherawy has entered the following ballot position for draft-ietf-suit-manifest-25: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-suit-manifest/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Holding a DISCUSS position on behalf of IANA to ensure the issue they raised (currently shown in the tracker) is resolved. I'm a little puzzled by the use of "nint" as a placeholder in some of the registries. I don't understand what's going on there, and 8.4.8 (where it's apparently defined) didn't make it any clearer to me. Can I get a little clarification? === >From Orie Steele, incoming ART Area Director: I have concerns with how i18n and unicode may interact with suite text strings and suite URIs. Particularly in the case of fetching remote content. I am also concerned about the potential IDNA issues with how UUIDs are constructed per Section 8.4.8.2. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The shepherd writeup doesn't include the reason that PS is the right status here. === >From Orie Steele, incoming ART Area Director: In the abstract: This would be clearer if the first use of "IoT" were expanded. (https://www.rfc-editor.org/materials/abbrev.expansion.txt does not mark either as "well-known".) Side note, is "Internet of Things Software Update (IoTSU)" a relevant / useful acronym here? In Section 4.2 consider defining "pull parser", prior to using the term. "The bootloader may add its own authentication, e.g. a Message Authentication Code (MAC), to the manifest in order to prevent further verifications." Why? In Section 5.3.4 "see {#ovr-integrated}," seems to be an escaped reference. Section 5.4 Comment: "Severable Elements", seems similar to selective disclosure and elision, you might want to relate your definitions to other industry terminology. Section 6.2 """ If a Recipient supports groups of interdependent components (a Component Set), then it SHOULD verify that all Components in the Component Set are specified by one update, """ Under what circumstances can a recipient benefit from not verifying all components in the component set are specified by one update? (Why not MUST) Noting Section 8.4.3 and Section 8.4.4 have internationalization considerations. Section 8.4.8.10 '"" A URI Reference RFC3986 from which to fetch a resource, encoded as a text string. """ I believe this precludes URI's that contain unicode, you might consider borrowing some language from https://datatracker.ietf.org/doc/html/rfc9525#name-identifying-application-ser """ The information used to create the class-id condition (see {{uuid-identifiers) """ Reference typo. Section "8.4.5.1. SUIT_Component_Identifier" I'd prefer to see unicode considerations in this section. in Section 11.8 Are expired Internet drafts considered acceptable "stable references" for "standards track range of point assignment"... If not, please give concrete guidance to the experts regarding managing registrations of references that expire. """ When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for. """ Sounds like you are asking for registries that are "Expert Review" not "Specification Required", please confirm after reading: https://datatracker.ietf.org/doc/html/rfc8126#section-4.6 Extra text in each registry section, would make all this a lot clearer, as I noted in the beginning of my comments. In Section 11.9 Why not "application/suit-envelope+cose", under what circumstances can a suite envelope be transmitted as application/cose ? If there will never be other expressions that are not COSE, "application/suit-envelope" seems fine.
- [Suit] Murray Kucherawy's Discuss on draft-ietf-s… Murray Kucherawy via Datatracker
- Re: [Suit] Murray Kucherawy's Discuss on draft-ie… Orie Steele