Кратко

  • Шестнадцатая редакция проекта расширений управления обновлениями SUIT датирована 27 сентября. Это действующий Internet-Draft с предполагаемым статусом Proposed Standard, а не опубликованный RFC.
  • Реализация и использование расширений необязательны. Знание о том, поддерживает ли их приёмник, зависит от конкретного развёртывания и может быть получено по внешнему каналу.
  • В пятнадцатой редакции автору манифеста предписывалось заранее убедиться, что целевые устройства объявили поддержку нужных расширений. Удаление этой формулировки не превращает неизвестную команду в успешно исполненную.

Представим парк датчиков, в котором разные поколения устройств объединены одним заданием на обновление. Система рассылки способна подтвердить происхождение манифеста и неизменность его содержимого. Но это не сообщает ей, какие условные операции поддерживает обработчик манифестов в каждом поколении. Если установка зависит, например, от проверки батареи или ожидания события, несовпадение возможностей существенно ещё до отправки.

Проект Update Management Extensions for SUIT Manifests описывает дополнительные поля, параметры и команды для версий, приоритетов, местного разрешения, условий питания и ожидания. Его новая редакция подчёркивает, что расширения можно как не реализовывать, так и не включать в манифест. Следующая фраза относит сведения о поддержке приёмника к конкретному развёртыванию; договориться о них можно и вне самого обмена манифестами. В Datatracker документ остаётся на стадии сопровождения ответственным директором после рассмотрения IESG. Это не означает завершённую стандартизацию или доказанное внедрение у производителей.

Изменение видно при сопоставлении с редакцией 15. Раньше от автора требовалось до рассылки проверить, что намеченные приёмники заявили поддержку расширений, от которых зависит манифест. Теперь это универсальное требование заменено указанием на локальное знание. Профиль развёртывания, интерфейс управления или проверка в лаборатории могут дать нужные сведения, но проект не учреждает единого протокола согласования возможностей. По одной правке также нельзя уверенно судить о мотивах редакторов.

Нельзя делать и обратный вывод — будто устройство вправе не заметить незнакомую команду и сообщить об успехе. Базовый проект манифеста SUIT относит неподдерживаемые команды и параметры к возможным причинам исключения манифеста. Команды расширения при этом остаются необязательными для реализации. Следовательно, точную реакцию конкретного приёмника нужно устанавливать по базовым правилам, применимому профилю и испытаниям реализации, а не по отсутствию прежней фразы об обязанности автора.

Раздел о развёртывании перечисляет действительно местные зависимости: сопоставление идентификаторов с контролем доступа, источник и точность данных о батарее, политику для уровней приоритета, сведения о времени и других устройствах для ожидания. Авторы рекомендуют, чтобы интерфейсы управления показывали поддерживаемые расширения и причины задержки либо неудачи обновления. Формула SHOULD не удостоверяет, что такая функция уже есть у всех аппаратов.

Поэтому предмет этой статьи — не полномочия подписанта на установку прошивки. Предмет — доказательство того, что выбранная группа устройств распознаёт необязательное действие, без которого план не исполнится. Подпись и запись в очереди доставки не содержат этого доказательства.

Источники