Resumen

  • RFC 9890 actualiza el texto de RFC 6020 sobre el registro de nombres de módulos y submódulos YANG.
  • Los nombres y espacios de nombres XML de las versiones iniciales siguen siendo únicos; las revisiones posteriores reutilizan el nombre y el espacio de nombres iniciales.
  • El procedimiento del registro de nombres de módulos YANG de IANA es la autoridad para asignar nombres; la identidad del registro no equivale a un inventario de despliegue consciente de la revisión.

RFC 6020 decía que todos los nombres de módulos y submódulos, y todos los espacios de nombres XML del registro, debían ser únicos. RFC 9890 registra que esa redacción no coincidía con la práctica de IANA para las revisiones. Con la regla actualizada, la unicidad se aplica a la versión inicial: el nombre inicial de un módulo o submódulo sigue siendo único y el espacio de nombres XML inicial de un módulo sigue siendo único. Cada revisión posterior conserva el nombre inicial y el mismo espacio de nombres XML.

La continuidad es deliberada. Un consumidor puede reconocer la familia del módulo sin tratar cada revisión como una identidad registrada nueva. El límite operativo, sin embargo, es importante. Una consulta por nombre o espacio de nombres responde qué identidad está registrada; sin metadatos de revisión y el artefacto correspondiente, no responde qué revisión está instalada, validada o es segura para restaurar. Tampoco demuestra que revisiones sucesivas sean semánticamente compatibles.

IANA incluye RFC 9890 como referencia adicional porque su procedimiento es la autoridad para asignar nombres en el registro de nombres de módulos YANG. La instantánea congelada de IANA es evidencia del estado del registro observado el 2026-09-05, no de la calidad de una implementación, la adopción operativa, la compatibilidad de herramientas ni la corrección de una revisión concreta.

Análisis de Theo March — no requisito de RFC 9890: tratar un nombre estable como clave completa de despliegue crea ambigüedad de identidad. En la automatización, esa ambigüedad puede convertirse en deriva del inventario: el registro apunta a la familia correcta, pero la validación y el despliegue usaron revisiones distintas. El control práctico es conservar, junto al nombre y espacio de nombres estables, el identificador de revisión, el artefacto de origen o su resumen criptográfico, el resultado de validación y el objetivo de reversión.

Fixtures de verificación

Una fixture mínima debe contener: el nombre example-module, el espacio de nombres XML urn:example:module, la revisión inicial 2024-01-01, la revisión posterior 2025-06-01, el resultado de la consulta del registro, el artefacto exacto validado y el artefacto conservado para la reversión. Comprobar que ambas revisiones mantienen el mismo nombre y espacio de nombres; después, comprobar que el inventario distingue sus fechas o metadatos de revisión equivalentes. Una segunda fixture debe omitir deliberadamente los metadatos de revisión. El resultado esperado es un fallo del control, no una inferencia de equivalencia. Son pruebas operativas propuestas en este briefing, no requisitos creados por RFC 9890.

Ruta de decisión del operador

  1. Resolver el nombre y el espacio de nombres registrados mediante el procedimiento autoritativo.
  2. Recuperar y registrar los metadatos exactos de revisión y el artefacto usado para validar.
  3. Comparar la revisión desplegada con la revisión validada antes de activar.
  4. Guardar un objetivo de reversión específico de la revisión y la prueba de que se conservó.
  5. Si falta la identidad de revisión, detener la promoción o la reversión; no inferir compatibilidad a partir de la identidad estable del registro.

El conjunto de evidencias no mide cuántas herramientas supusieron nombres globalmente únicos para todas las revisiones. No establece ningún incidente de operador, fallo de interoperabilidad ni coste de migración. RFC 9890 no valida la compatibilidad semántica de revisiones sucesivas. La instantánea congelada de IANA puede cambiar después de la observación. El soporte de proveedores y la prevalencia del despliegue están fuera del conjunto de fuentes.

Fuentes

RFC 9890 afirma que el cambio alinea la política con la práctica existente del registro y no introduce nuevas operaciones ni requisitos de gestión. También afirma que no introduce riesgos de seguridad nuevos o incrementados que requieran discusión.