Resumen

  • RFC 6020 decía que todos los nombres de módulos y submódulos YANG del registro, así como todos sus espacios de nombres XML, debían ser únicos. IANA, en cambio, mantenía las revisiones sucesivas bajo el mismo nombre y espacio de nombres.
  • RFC 9890, firmado por Andy Bierman, Mohamed Boucadair y Qin Wu, trasladó la unicidad a la versión inicial y ordenó que las revisiones conservaran esa identidad.
  • Compartir nombre no significa compartir contenido. La fecha de revisión, el archivo exacto, la selección de importación, la validación y el resultado en producción son comprobantes distintos.

El 1 de septiembre de 2026, ietf-yang-types aparecía tres veces en el registro YANG de IANA. Las filas llevaban las fechas 2010-09-24, 2013-07-15 y 2025-12-22. Sus referencias documentales cambiaban; su nombre y su espacio de nombres XML no.

Aquello no era un accidente de depuración. Era el historial de un módulo. Sin embargo, la frase original de RFC 6020 ordenaba que todos los nombres presentes en el registro fuesen únicos. Aplicada sin contexto, esa regla convertía cada revisión legítima en una infracción aparente.

RFC 9890, publicada en octubre de 2025, hizo que el texto alcanzara a la realidad administrativa. El documento no presentó una nueva operación. Reconoció que una asignación inicial y una revisión posterior son eventos diferentes y necesitan controles distintos.

Un nombre repetido no explica por qué se repite

La unicidad no puede evaluarse sin conocer el objeto de la prueba. Cuando dos altas iniciales reclaman el mismo identificador, existe una colisión. Cuando una revisión conserva el identificador de su antecedente, existe continuidad. La coincidencia textual es idéntica; la consecuencia es opuesta.

La regla corregida deja cuatro obligaciones. Los nombres de versiones iniciales de módulos y submódulos deben ser únicos. Los espacios de nombres XML de módulos iniciales también. Las revisiones de módulos y submódulos mantienen el nombre inicial. Las revisiones de módulos mantienen además el espacio de nombres XML inicial.

Así se protegen dos bienes: ninguna línea independiente puede apropiarse de una identidad ya asignada, y ninguna línea existente tiene que inventar una identidad nueva para cada cambio editorial.

Por eso un control de «duplicados» necesita al menos tipo de evento, fecha de revisión, documento de origen, nombre y espacio de nombres. Sin ellos, una limpieza automática puede borrar el historial correcto o aceptar una colisión real bajo la etiqueta equivocada.

La identidad estable contiene estados editoriales diferentes

El ajuste podría generar un error simétrico: pensar que dos revisiones homónimas son equivalentes. YANG 1.1 mantiene abierta la diferencia.

RFC 7950 define las sentencias revision como el historial editorial del módulo. Cada argumento es una fecha. Los cambios editoriales publicados deberían añadir una nueva entrada al principio de una secuencia inversa. El nombre de archivo recomendado combina el nombre del módulo con @fecha-de-revisión cuando se necesita distinguirlo.

El nombre dice a qué familia pertenece el archivo. La fecha dice qué estado de esa familia contiene. Conservar la familia no congela la definición.

La importación vuelve ejecutable esa diferencia. Si aparece revision-date, deben utilizarse las definiciones de la revisión indicada y una fecha inexistente es un error. Si no aparece, RFC 7950 considera indefinida la revisión elegida. Incluso admite importar varias revisiones del mismo módulo si se usan prefijos distintos.

Un espacio de nombres compartido no es, por tanto, una garantía de compatibilidad. Tampoco decide qué versión empaquetó un proveedor o cuál desplegó un operador. Solo evita que el objeto público cambie de identidad cada vez que cambia su contenido.

La fecha inicia la prueba; el hash la vuelve exacta

Las filas de ietf-yang-types muestran una práctica legible. La revisión de 2010 remite a RFC 6021; la de 2013, a RFC 6991; la de 2025, a RFC 9911. El registro mantiene la continuidad, pero conserva fechas, archivos y autoridades separados.

Guardar únicamente ietf-yang-types elimina el estado editorial. Rebautizar las filas como v1, v2 y v3 inventa identidades que IANA nunca asignó. El inventario correcto retiene el nombre común y la revisión fechada.

En producción hacen falta más uniones: hash del archivo, URL y RFC de origen, versión del paquete o firmware, versión del parser, resultado de validación, ámbito de despliegue y observación del servicio. La fecha expresa la selección prevista. El hash fija los bytes. El manifiesto identifica lo entregado. La prueba indica lo aceptado. La telemetría muestra lo ejecutado.

Si una misma fecha llega con hashes distintos, el problema puede estar en la cadena de suministro. Si dos parsers interpretan de modo diferente la misma revisión, la diferencia está en la implementación. Si un artefacto validado no llegó a producción, la prueba de laboratorio no autoriza una afirmación operativa.

IANA registra una línea; no certifica todo lo que ocurre debajo

RFC 9890 añadió su propia referencia como autoridad del procedimiento. Al mismo tiempo afirmó que el cambio no introducía nuevas operaciones ni requisitos de gestión y que no añadía riesgos de seguridad.

Ese límite es parte del diseño. IANA puede rechazar una colisión inicial y registrar que una revisión fechada pertenece a una identidad existente. No puede certificar la calidad del modelo, el comportamiento de un parser, la compatibilidad entre estados ni la conveniencia de ponerlos en producción.

La Especificación Inicial Mínima de Heng Lu ayuda a situar la frontera. Solo debe ser común lo que necesita una respuesta común. La identidad inicial y su continuidad pertenecen a ese núcleo. La elección de versión, la integración, la ventana de cambio y la aceptación de riesgo se quedan con quienes controlan el sistema local.

Una revisión registrada es una opción disponible, no una orden global. Publicarla no obliga a todos los productos a incorporarla a la vez. Mantener el nombre permite decisiones futuras localizadas sin romper las referencias compartidas.

El crédito de Qin Wu no desplaza la responsabilidad

RFC 9890 incluye a Qin Wu, de Huawei, entre sus tres autores junto con Andy Bierman y Mohamed Boucadair. IETF Datatracker asocia una lista extensa de RFC a la misma identidad pública. Es un contexto verificable para una trayectoria en gestión de redes y YANG.

No convierte a Qin Wu en propietaria del estándar ni responsable de cada implementación. El proceso de IETF produce el documento; IANA opera el registro; autores y grupos modifican modelos; proveedores crean software; operadores deciden despliegues.

La distinción protege la atribución. Una entrada registral errónea debe investigarse en el proceso registral. Una divergencia de parser, en el producto. Una migración fallida, en su cadena de prueba y aprobación. El nombre de una persona prueba procedencia documental, no control de sistemas ajenos.

El valor de esta aportación es más concreto: ayudar a que una regla escrita describa la continuidad que el registro necesitaba, sin absorber las decisiones posteriores.

La práctica solo merece primacía si conserva la propiedad común

La primacía del código que funciona no significa que toda costumbre desplegada sea correcta. Una práctica extendida puede ser insegura o bloquear la interoperabilidad. Debe evaluarse contra la razón por la que existe la coordinación.

En este caso, mantener nombre y espacio de nombres en las revisiones no reduce la unicidad inicial. Evita fragmentar una línea conocida y permite que importaciones, herramientas y documentación conserven una referencia estable.

RFC 9890 documentó la corrección con una transparencia útil: reprodujo la regla antigua, describió la divergencia, presentó el texto nuevo e identificó el registro afectado. No fingió que la contradicción nunca existió.

Una norma gana autoridad técnica cuando puede corregir su abstracción a partir de una práctica delimitada y auditable. Obligar al registro a cambiar identidades solo para preservar una frase antigua habría protegido el papel a costa del sistema.

El recibo que debe acompañar a cada revisión

La capa inicial contiene nombre, espacio de nombres, documento de asignación, fecha y una marca inequívoca de primera versión. Solo allí se ejecuta la prueba de unicidad frente a otras altas.

La capa de revisión repite la identidad y añade fecha, URL, hash, RFC, antecedente y método de selección. Debe indicar si la importación fijó revision-date o dejó la elección sin determinar.

La capa de software registra parser, versión, grafo de importaciones, features, desviaciones, paquete, validación y bytes entregados. La capa operativa registra aprobación, pruebas, lote de despliegue, incidencias, observación y rollback.

Los verbos impiden la inflación de evidencia. IANA registró. Una RFC especificó. Un paquete incluyó. Un parser aceptó. Un proveedor soportó. Un operador desplegó. El servicio funcionó o falló. Ningún verbo puede hablar por el siguiente.

Fuentes