Résumé

  • Datée du 27 septembre, la révision 16 du projet IETF sur la gestion des mises à jour SUIT reste un Internet-Draft actif, non une RFC approuvée.
  • Les extensions sont facultatives. Le texte précise désormais que la connaissance de leur prise en charge par le destinataire dépend du déploiement et peut être établie hors bande.
  • Cette reformulation retire une obligation explicite de la révision 15 imposée à l’auteur du manifeste avant l’envoi, sans démontrer qu’une commande inconnue pourrait être ignorée sans conséquence.

Dans un parc d’objets connectés, le même fichier peut atteindre des générations de matériel très différentes. Vérifier sa signature ne révèle ni la version de leur processeur de manifeste ni la liste des commandes qu’ils savent exécuter. Si l’installation dépend d’une condition de batterie ou d’une attente d’événement, cette différence devient décisive avant même que l’on examine le succès de l’installation.

La révision 16 des Update Management Extensions for SUIT Manifests rend cette frontière explicite. Elle propose notamment des paramètres de version et de priorité, des conditions d’autorisation ou de batterie et une directive d’attente. Ces fonctions sont facultatives à implémenter et à placer dans un manifeste. Le projet indique désormais que la connaissance des extensions reconnues par le destinataire relève du déploiement et peut être obtenue par des moyens extérieurs au protocole. Son statut reste celui d’un projet en suivi par le directeur de zone après évaluation IESG ; il ne faut pas le présenter comme une norme déjà publiée.

Le changement mérite une lecture précise. La révision 15 demandait à l’auteur du manifeste de s’assurer que les destinataires ciblés annonçaient les extensions nécessaires avant l’expédition. Cette prescription générale disparaît dans la révision 16. Un accord de déploiement, un profil, une campagne d’essais ou une interface de gestion peuvent désormais fournir la connaissance utile, mais le nouveau texte n’institue ni négociation universelle ni registre de capacités commun. Il ne dit pas non plus pourquoi les auteurs ont choisi cette formulation.

Il serait tout aussi erroné d’en déduire qu’un appareil est libre d’acquitter une instruction qu’il ne connaît pas. Le projet de manifeste SUIT de base cite les commandes et paramètres non pris en charge parmi les motifs possibles d’exclusion d’un manifeste. Quant aux nouvelles commandes de gestion, elles restent explicitement facultatives. La conséquence exacte dépend des règles du manifeste de base, du profil applicable et du comportement vérifié de l’appareil ; la suppression d’une phrase ne constitue pas une preuve d’exécution.

Le chapitre consacré au déploiement montre où se trouvent les données indispensables : correspondance locale des permissions, fiabilité de la télémétrie de batterie, politique attachée aux priorités, sources des événements et identifiants des autres appareils. Il recommande que les interfaces de gestion exposent les extensions reconnues et la raison d’une attente ou d’un échec. Une recommandation de type SHOULD ne certifie pas que toutes les interfaces existantes le font.

Le sujet n’est donc pas de rediscuter l’autorité du signataire sur l’installation. Il s’agit d’identifier celui qui possède, avant distribution, une preuve valable pour un groupe précis d’appareils. Sans elle, une mise à jour mise en file peut être décrite comme réalisable alors qu’on ne connaît pas encore la capacité de ses destinataires.

Sources