# Andy Newton, ART AD, comments for draft-ietf-suit-update-management-13
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-suit-update-management-13.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Thanks to the Reviewers

Thanks to Russ Housley for the ARTART review.

## Comments

### UTF-8 printable characters

268        documentation provides the necessary context.  Values in this field
269        MUST be encoded as UTF-8 text limited to printable characters, and

Should this also refer to the categories as is done on line 234?

And again here?

551        Unless otherwise stated, all string values in this structure MUST be
552        encoded as UTF-8 without control characters (Unicode general
553        categories Cc or Cf) and SHOULD be limited to human-readable
554        identifiers such as names or POSIX-style paths.  Binary values

Would it be worth referring to Unicode Assignables in Section 4.3 of RFC 9839?

# Éric Vyncke INT AD comments for draft-ietf-suit-update-management-13
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Other thanks to Hannes Tschofenig, the IoT directorate reviewer (at my request), please consider this iot-dir review:
https://datatracker.ietf.org/doc/review-ietf-suit-update-management-12-iotdir-telechat-tschofenig-2026-06-24/ (and I have read Brendan's reply)

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.


## COMMENTS (non-blocking)

### Abstract

s/This specification describes extensions/This *document specifies* extensions/ as it is a PS.

### Sections 3.3 and 3.4

There are several BCP14 "SHOULD" in this section that have not the IESG required guidance per https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/, i.e., explaining what are the consequence of not following the "SHOULD". BCP14 are mainly for interoperation and this is the case here.

In short, why not a "MUST" rather than a "SHOULD" ?

### Section 4.4.1

Why not a "MUST" in `Manifest Authors SHOULD keep their encoding aligned with semantic versioning so that Recipients can compare versions deterministically` consider using the "... MUST ... unless another numbering scheme...". Else, the manifest author could read the paragraph as "I do not need to use any structure".

### Section 4.4

Add the referene to RFC8949 when first using CBOR.

### Section 6

Please add an informational reference for each table, e.g., https://www.iana.org/assignments/suit/suit.xhtml#suit-envelope-elements or at least one informational reference to the SUIT group.

Hi Authors, WG,

# Gunter Van de Velde, RTG AD, comments for draft-ietf-suit-update-management-12

# Thank you for the work on this document. The SUIT technology is outside my traditional technology area of expertise. I hope my observations are helpful to consider with this document:

* RFC9019 is currently informative, but Section 2 says the draft “makes use of terminology defined in [RFC9019]”. If the terminology is required to understand or implement the specification, this should be normative. Note that RFC 9019 is Informational, so making it normative from a Standards Track document would create a downward normative reference that needs to be called out and processed. RFC 9019 is explicitly Informational.

* [I-D.ietf-suit-information-model] should be replaced with RFC 9124. The information model has been published as RFC 9124, and the current draft still references the old Internet-Draft version from 2021. RFC 9124 contains the requirements and terminology for the manifest information model.

* One IANA nit: Section 6 says IANA is requested to allocate “commands, parameters, and metadata values.” Since the document also requests an Envelope Element, Manifest Elements, and Component Text Values, it may be clearer to say “the following SUIT registry values” rather than “commands, parameters, and metadata values.”

Kind Regards,
Gunter Van de Velde
Routing Area Director

Thanks to the authors and the WG for their work on this document.

I echo the comments made by Gunter.

Section 1, second paragraph, and Section 5, first paragraph:

110 >    Extensions in this specification are OPTIONAL to implement and
111 >    OPTIONAL to include in manifests.  A Recipient that encounters a
112 >    command or parameter it does not implement MUST reject the manifest
113 >    as defined in [I-D.ietf-suit-manifest] Section 8.4.2, ensuring that
114 >    update behaviour is never ambiguous.

715 >    All commands defined in this specification are OPTIONAL to implement.
716 >    A Recipient that encounters a command it does not implement MUST
717 >    reject the manifest as defined in [I-D.ietf-suit-manifest]
718 >    Section 8.4.2, ensuring that update behaviour is never ambiguous.

I checked Section 8.4.2 of draft-ietf-suit-manifest-37, and it is titled
"suit-manifest-sequence-number" — it defines the anti-rollback counter, not the rule
about rejecting a manifest that contains an unsupported command or parameter. As far as
I can tell that the rejection rule is actually stated in Section 6.1 ("Manifest Processor
Setup") of the manifest draft, in the list of reasons a manifest can be excluded
("Unsupported command encountered", "Unsupported parameter encountered"). I would ask
the authors to correct both citations, since, as written, they point a reader to an
unrelated requirement.

---

Section 3.1, suit-set-version, and Appendix A:

170 >    The composition of suit-set-version is the same as suit-parameter-
171 >    version (Section 4.4).

Section 4.4 defines suit-parameter-version as a comparison operator paired with a
version value:

357 >    SUIT_Parameter_Version_Match = [
358 >        suit-condition-version-comparison-type:
359 >            SUIT_Condition_Version_Comparison_Types,
360 >        suit-condition-version-comparison-value:
361 >            SUIT_Condition_Version_Comparison_Value
362 >    ]

but the Appendix A CDDL for suit-set-version omits the comparison-type element
entirely and encodes it as a bare version value:

1054 >    $$unseverable-manifest-member-extensions //= (
1055 >        suit-set-version =>
1056 >            bstr .cbor SUIT_Condition_Version_Comparison_Value
1057 >    )

It seems to me that the CDDL, not the prose, reflects the intended encoding — a plain
version has no comparison operator to carry — but as written, Section 3.1 would lead an
implementer to expect a two-element comparison structure. I would suggest fixing the
Section 3.1 text (e.g., "suit-set-version encodes a version using the same
SUIT_Condition_Version_Comparison_Value structure used within suit-parameter-version")
rather than saying the composition is "the same."

---

Section 4.6.5, File Type, and Section 7, Security Considerations:

652 >    *  To create a symbolic link
653 >
654 >       -  Set the Component Index to the Component Identifier of the link
655 >          to be created
656 >
657 >       -  Set the Component metadata, including the file type for
658 >          symbolic link
659 >
660 >       -  Set suit-parameter-content to the link target
661 >
662 >       -  Invoke suit-directive-write

994 >    Component metadata (Section 4.6) can expose operator identifiers,
995 >    file paths, or other locally meaningful strings.  Deployments SHOULD
996 >    validate these values against local policy before applying them, and
997 >    MUST handle missing or malformed metadata defensively so that the
998 >    update agent does not escalate privileges or disclose sensitive
999 >    information inadvertently.

This is a new primitive relative to the base manifest: nothing in I-D.ietf-suit-manifest
let's manifest direct the Recipient to create a symbolic link with an author-chosen
target. I am not sure the Security Considerations text above fully covers the risk this
introduces — a symlink planted by one command sequence (for example, from a dependency
component under a different authorship than the root manifest) whose target is later
followed by an unrelated write in the same or a subsequent manifest is a classic
TOCTOU/privilege-escalation pattern on POSIX-like filesystems. I would appreciate the
authors either explaining why this is already covered by existing manifest processing
constraints (e.g., component isolation between dependency manifests) or adding text
recommending that implementations resolve/canonicalize write targets and not blindly
follow Recipient-created symlinks across component or trust boundaries.

---

This document introduces several new configuration/inspection points 
(component permissions and ownership, minimum-battery, and update-priority 
thresholds, wait-event conditions). This is a suggestion rather than 
something I'd insist on, given rfc5706bis is itself still a work
in progress.

----------------------------------------------------------------------
NIT
----------------------------------------------------------------------

All comments below are about very minor potential issues that you may
choose to address in some way - or ignore - as you see fit. Some were
flagged by automated tools (via
https://github.com/larseggert/ietf-reviewtool), so there will likely
be some false positives. There is no need to let me know what you did
with these suggestions.

Section 7, Security Considerations, first paragraph after the introductory text:

975 >    The free-text fields introduced in Sections Section 3.3 and
976 >    Section 3.4 are intended solely for human consumption.

s/Sections Section 3.3/Section 3.3/

Hi Brendan and Ken,

The change made in -14 [1] address all the comments in my previous ballot [2].

Thank you.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-suit-update-management-13&url2=draft-ietf-suit-update-management-14&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/suit/608sSjOuAltu-lIvTJcZRoVGxH8/

Thank you to Roni Even for the GENART review.

Thank you for addressing my DISCUSS feedback.