[Iot-directorate] Re: draft-ietf-suit-update-management-12 telechat Iotdir review

[Brendan Moran <[e-mail]>]

Hi Hannes,

Thank you for your review. I have taken all these comments into
consideration and published a new version which I hope will address all
your concerns.

https://datatracker.ietf.org/doc/draft-ietf-suit-update-management/


Best Regards,
Brendan

On Wed, 24 Jun 2026 at 10:37, Hannes Tschofenig via Datatracker <
[e-mail]> wrote:

> Document: draft-ietf-suit-update-management
> Title: Update Management Extensions for Software Updates for Internet of
> Things
> (SUIT) Manifests Reviewer: Hannes Tschofenig Review result: Ready with
> Issues
>
> Thanks to the authors for their work on the document.
>
> I have reviewed the draft and here are a few comments.
>
> The definition of "primary cell" in the terminology section is not
> necessary
> since the term is only used once throughout the document. I would just
> explain
> it in the section where it is used.
>
> I would make [semver] an informative reference and move the text describing
> semantic versioning from page 9 to an earlier part, for example to the
> terminology section. This is particularly relevant since you are not using
> the
> referenced write-up in its entirety.
>
> Semantic versioning, as described in semver.org, allows additional labels
> for
> pre-release and build metadata to be used as extensions to the
> MAJOR.MINOR.PATCH format. Section 3.1, however, says "build numbers MUST
> NOT be
> included". I suggest to clarify this difference to the referenced semantic
> versioning. In Section 4.4.1 you define numerical values (-3, -2 and -1)
> for
> alpha/beta/rc pre-releases. Semantic versioning, however, allows arbitrary
> pre-release identifiers and it might be worth pointing this difference out.
>
> If a suit-parameter-update-priority does not define whether a larger value
> implies a higher priority then it will be difficult to guarantee
> interoperability. I would define an ordering without leaving it to
> applications.
>
> References: I-D.ietf-suit-information-model became RFC 9124.
>
> The heading of Section 3.4 says "text-current-version" but it should say
> "suit-text-current-version" instead.
>
> In Section 4.6.3 you list permissions and one of them is creatdir_append. I
> think this is a typo. Should it be createdir_append?
>
> The suit-wait-event-other-device-version, which defines a wait operation
> for
> other device to match version, is defined in a way that interoperability
> will
> be very difficult to accomplished.
>
> The use of suit-coswid in a manifest will raise the concern that anyone
> with
> access to such a manifest will be able to quickly make assessments about
> the
> security of the device. This is desirable in the hands of the right person
> but
> not necessarily suitable for everyone. This might be something to bring up
> in
> the security consideration section.
>
> The specification states that time-of-day and day-of-week are interpreted
> as
> "Local Time". It may be useful to clarify whether this refers to the
> device-configured local timezone, how daylight-saving time transitions are
> handled, and what behavior is expected when timezone information changes
> during
> device operation.
>
> Unrelated to the review of this draft but important for the publication of
> the
> SUIT manifest, which is a normative dependency: I do not understand why the
> manifest specification has a normative dependency on this document. This
> document defines optional extensions.
>
>
>
>