Resumen

  • La versión 16, fechada el 27 de septiembre, continúa siendo un Internet-Draft activo con objetivo de Proposed Standard; no es una RFC publicada.
  • Tanto la implementación como el uso de las extensiones de gestión son opcionales. El texto ahora sitúa el conocimiento de la capacidad del receptor en cada despliegue y admite que se obtenga fuera de banda.
  • La eliminación de una obligación explícita de la versión 15 para el autor del manifiesto no convierte una orden desconocida en una operación ejecutada con éxito.

Una campaña de actualización suele agrupar dispositivos bajo un mismo nombre comercial aunque no tengan el mismo cargador de arranque ni la misma versión del intérprete. El manifiesto puede estar intacto y ser auténtico; aun así, uno de esos receptores podría no implementar la condición opcional de la que depende el plan. La diferencia no es semántica: determina si la distribución tenía una base comprobable antes de empezar.

La nueva versión de Update Management Extensions for SUIT Manifests ofrece comandos y parámetros para prioridades, comprobaciones de batería y versión, autorización local y espera de acontecimientos, entre otros fines. Su introducción recalca que esas extensiones no son obligatorias. A continuación dice que saber si un receptor las admite depende del despliegue y puede establecerse por otros medios. La ficha del IETF sigue mostrando el documento en seguimiento del director de área tras la evaluación del IESG. No hay aprobación definitiva ni datos sobre cuántos equipos aplican estas funciones.

El contraste con la versión 15 es el hecho nuevo. Allí se exigía al autor asegurar, antes del envío, que los receptores previstos anunciaban compatibilidad con las extensiones indispensables. La versión 16 sustituye esa frase por la referencia al acuerdo específico de despliegue. No prescribe una conversación automática entre todos los equipos ni un catálogo universal. Tampoco permite atribuir el cambio a una causa concreta sin pruebas del proceso editorial.

Conviene separar este punto de la respuesta ante un comando desconocido. El borrador base del manifiesto SUIT incluye comandos y parámetros no admitidos entre las razones posibles para excluir un manifiesto. Las instrucciones nuevas siguen siendo opcionales de implementar. Por tanto, la supresión de la frase dirigida al autor no autoriza a un receptor a fingir que ejecutó una instrucción que no entiende. Para conocer el resultado real harán falta las reglas aplicables y una prueba del dispositivo.

La sección operativa enumera decisiones que ninguna firma suministra: cómo se traducen las identidades y permisos al control local, de dónde procede la medición de batería, qué política corresponde a una prioridad y qué fuentes alimentan los eventos de espera. Recomienda que las interfaces de gestión indiquen las extensiones admitidas y el motivo de una espera o fallo. Esa recomendación no demuestra que ya exista tal interfaz para cada modelo.

La cuestión de gobierno es quién conserva la evidencia de compatibilidad para el lote preciso al que apunta una actualización. No es una reedición del debate sobre quién autoriza instalar firmware. Si una cola de distribución se confunde con una prueba de capacidad, el operador pierde el punto en el que podía corregir el destino antes de que la operación fallara.

Fuentes