Summary

  • The 27 September revision of the IETF's SUIT update-management draft says support for its extensions is optional and knowledge of a Recipient's support is deployment-specific, potentially established out of band.
  • Revision 15 had explicitly required Manifest Authors to ensure targeted Recipients advertised support before dependent manifests shipped; revision 16 removes that universal formulation. Neither text is an approved RFC.
  • The change does not establish that unsupported commands can be ignored. It makes the evidence for targeting a particular device cohort a practical responsibility that an operator must locate and retain.

An update distributor may hold a perfectly authentic manifest and still not know whether the device at the end of the queue recognizes the instruction that matters. A signature answers who signed the material and whether it changed. It does not enumerate the optional commands implemented by every model, firmware branch and bootloader revision in the target fleet.

That gap is unusually clear in revision 16 of Update Management Extensions for SUIT Manifests. The Internet-Draft describes extra metadata, parameters and commands for matters such as battery thresholds, update priority, version checks, local authorization and waiting for an event. Its introduction says implementation and inclusion of these extensions are optional. It now says knowledge of Recipient support is specific to a deployment and may be established outside the manifest exchange. The document remains an active draft in IESG AD Followup, not a published Proposed Standard.

The earlier revision used different language. It said a Manifest Author must ensure targeted Recipients advertised support for required extensions before shipping a manifest that relied on them. The September revision removes that universal author-side instruction. It does not introduce a universal substitute handshake or a shared inventory service. Nor does the edit prove why the authors made it. A deployment may use a management interface, a documented profile or another out-of-band agreement, but the revision does not tell readers that any one mechanism is always present.

There is an important safety boundary here. Removing a sentence about author-side confirmation is not a license for a Recipient to treat an unknown command as successfully executed. The companion base SUIT manifest draft lists unsupported commands and parameters among reasons a manifest can be excluded. Revision 16 still describes its new commands as optional to implement. An implementation's actual failure behavior has to be assessed against the applicable base manifest and profile; this article does not infer it from the deletion of one sentence.

The deployment section points to the part that cannot be signed away. Permissions must map to local access controls. Battery data has a source and accuracy. Priority values require local policy. Wait events depend on time, network or other-device information. The draft says management interfaces should expose supported extensions and why an update is waiting or has failed. “Should” is operational guidance, not evidence that a particular fleet's interface does so.

The immediate governance problem is therefore narrower than the broad question of who may authorize firmware. It is whether a distributor can show that this exact cohort can interpret the specific optional behaviour on which this update relies. Without that record, a queued manifest can be mistaken for an executable plan, and a signature for proof of compatibility. Neither inference follows from the draft.

Sources