Resumen

  • YANG 2.0 no sustituye a YANG 1 ni a 1.1. Un modelo completo puede mezclar versiones, aunque las reglas de include e import sean deliberadamente asimétricas.
  • La excepción para un import sin revisión permite conservar el módulo antiguo A junto a B actualizado a 2.0 y evita reescribir todo el grafo. No prueba que los clientes seleccionen la misma revisión ni que compartan esquema efectivo o comportamiento.

El escenario empieza con una pantalla verde. B ya usa YANG 2.0. A sigue en YANG 1.1 y llevaba años importando B sin fijar una revisión. El servidor arranca y anuncia ambos módulos. Esa observación puede ser correcta y, aun así, resultar insuficiente para afirmar que dos herramientas descargaron los mismos bytes, resolvieron el mismo B y construyeron el mismo árbol de esquema.

El borrador revision 00, fechado el 6 de julio de 2026, declara que YANG 2.0 no deja obsoletos RFC 6020 ni RFC 7950 y que un modelo completo puede reunir módulos escritos en varias versiones. El Datatracker del IETF lo registra como Internet-Draft activo del grupo NETMOD. Su cabecera propone Standards Track, pero todavía no es un RFC ni evidencia de implantación.

La asimetría define el camino de migración

La sección 12 exige que un módulo 2.0 incluya solamente submódulos 2.0. Un módulo 1/1.1 no puede incluir un submódulo 2.0 ni importar por revisión un módulo 2.0. En cambio, un módulo o submódulo 2.0 sí puede importar por revisión uno escrito en YANG 1 o 1.1.

No es una promesa simétrica de compatibilidad. El lado nuevo puede apoyarse de forma explícita en el antiguo; el lado antiguo no puede crear una dependencia adelantada y fijada a una revisión del nuevo lenguaje.

La excepción aborda el caso real de A y B. Si A, aún en 1/1.1, importa B sin revisión y B pasa a 2.0, el servidor puede implementar A y B a la vez. Debe anunciar los módulos conforme a las reglas de implementación y debería anunciar A junto con la última revisión de B todavía expresada en YANG 1 o 1.1. El texto explica el motivo: impedir que actualizar B obligue a convertir A y, después, todos los módulos que dependen de A.

Es una regla de contención, no una certificación. Permite que la adopción sea local, en línea con la propuesta de Lu Heng sobre especificación inicial mínima, decisión futura localizada y adopción voluntaria. Precisamente por eso cada participante debe demostrar qué combinación ha validado y ejecutado.

Lo anunciado y lo compilado no son lo mismo

La sección 5.6.4 prohíbe que un servidor implemente más de una revisión del mismo módulo, pero separa módulos implementados de módulos import-only que aportan tipos u otros elementos. RFC 8525 estructura esa declaración mediante module sets, roles de conformidad, features, deviations e identificadores de cambio.

Ese inventario prueba lo que el servidor afirmó en un instante. Permite saber si A estaba presente, qué revisiones de B aparecían y con qué rol. No acredita qué fichero leyó el cliente, cómo resolvió el import sin revisión, qué parser utilizó o si dos clientes obtuvieron el mismo esquema efectivo.

Tampoco conviene trasladar esa carga a piezas vecinas. Module versioning identifica mejor las revisiones; Semver limita rangos; un package describe un conjunto; schema comparison clasifica diferencias; el nombre de fichero ayuda a localizar material. Ninguno sustituye el rastro de resolución, el resultado compilado, la validación y la observación en producción.

La escalera de evidencias

Una afirmación de compatibilidad debe conservar ocho niveles:

  1. bytes exactos, procedencia, namespace, versión de lenguaje, revisión y hash de cada módulo y submódulo;
  2. cierre completo de import/include y decisión explícita para cada import sin revisión;
  3. captura completa de YANG Library con roles, features, deviations, identidad del module set y hora;
  4. identidad del parser o compilador, diagnósticos y huella normalizada del esquema efectivo;
  5. validación de instancias representativas y casos deliberadamente inválidos;
  6. trazas de resolución de clientes independientes;
  7. pruebas de lectura, edición, RPC, action, notification, fallos y rollback;
  8. observación del estado intended y operational, distinción formalizada por RFC 8342, además de la recuperación real.

Ningún nivel toma prestada la autoridad de otro. El anuncio, el artefacto resuelto, el éxito de validación y el comportamiento en servicio pertenecen a capas de realidad relacionadas, no intercambiables.

Así queda la conclusión exacta: el borrador evita conversiones innecesarias del grafo. No elimina el trabajo de demostrar el contrato efectivo de cada cliente.

Fuentes