Resumen

  • draft-ietf-netmod-yang-schema-comparison-09 compara tanto las sentencias analizadas como el árbol de datos compilado y clasifica cada cambio como editorial, compatible o no compatible hacia atrás.
  • El resultado puede orientar la revisión, la versión semántica y una conversión de datos. No prueba que el contexto de entrada sea idéntico, que no haya pérdidas, que dos implementaciones interoperen o que NACM y el estado operativo permanezcan estables.

La brevedad de un diff invita a exagerar su alcance. Una línea que dice “sin cambios incompatibles” pasa del informe técnico a la orden de cambio y termina convertida en “actualización completada”. Entre esas frases han desaparecido el conversor, los clientes, los servidores, las reglas de acceso, la secuencia de despliegue y el sistema real.

La revisión 09 se publicó el 3 de julio de 2026. El Datatracker de la IETF la registra como Internet-Draft activo del grupo NETMOD, no como RFC. El resumen actual de validación muestra cero errores y cero advertencias. Es evidencia sobre el documento y su superficie de validación, no sobre adopción comercial, compatibilidad entre productos ni resultados de producción.

El contexto de compilación forma parte del resultado

El borrador separa el esquema analizado del compilado. El primero conserva el árbol de sentencias cargadas antes de resolver por completo referencias y transformaciones. El segundo produce el modelo efectivo: incorpora imports y submódulos, resuelve uses y typedef, aplica augment, deviation y refine, y evalúa las expresiones if-feature habilitadas.

Ambas vistas son necesarias. Un cambio pequeño en un typedef puede propagarse a muchas hojas. Un augment definido fuera del módulo puede insertar nodos en su árbol. Una deviation del fabricante puede retirar una restricción sin tocar el archivo objetivo. Mirar solo el texto pierde el efecto compilado; mirar solo el árbol efectivo pierde cambios de sentencias que importan a autores e importadores.

Por eso la revisión 09 informa primero los nodos de datos compilados y después las demás sentencias analizadas, evitando duplicados. La identidad compilada conserva nombre y revisión de los módulos anterior y nuevo, submódulos incluidos, features habilitadas e imports recursivos.

Un resultado vacío solo vale para ese conjunto exacto. Otra feature, otra revisión importada, una deviation distinta o un submódulo diferente definen otro experimento. El recibo inicial debe fijar hashes de fuentes e identidad de compilación antes de que alguien reutilice el veredicto.

Tres clases, varias fuentes de juicio

Cada cambio recibe ED, BC o NBC. Una edición no altera el espacio de datos válidos ni rompe módulos importadores. Un cambio compatible puede ampliar ese espacio sin invalidar importadores. Todo lo que lo reduzca o pueda romper un importador es no compatible.

La clasificación capta rupturas poco intuitivas. Cambiar uint32 por uint64 amplía el rango, pero RFC 7951 cambia su representación JSON de número a cadena. Un cliente que esperaba un número puede fallar; la modificación puede ser NBC.

pattern, when y must son NBC por defecto. description, reference y presence son editoriales por defecto; una instancia de extensión es BC. El autor puede sustituir esas clases con marcas persistentes ed-change-at, bc-change-at o nbc-change-at, vinculadas a la versión semántica donde apareció el cambio.

La sustitución hace visible una decisión; no la convierte en observación. Una revisión seria separa reglas fijas, valores por defecto y excepciones humanas, y conserva su motivo y aprobación. La etiqueta semántica será entonces una declaración responsable, no un pronóstico automático.

Compatible no significa comportamiento idéntico

Añadir una hoja opcional puede ser BC y, aun así, cambiar el sistema. El servidor puede empezar a rellenarla; un cliente puede serializarla, una política puede leerla o una interfaz mostrarla. Cambiar un valor por defecto modifica el comportamiento efectivo sin alterar la configuración guardada. when, must, features y deviations cambian caminos de validación y superficies concretas.

El comparador no ejecuta RPC, no reproduce todas las configuraciones, no expande valores por defecto ni observa clientes. RFC 8525 identifica el conjunto de módulos, features y deviations que declara un servidor. Su content-id identifica la biblioteca YANG, no certifica que el código ejecute correctamente cada regla.

La autorización tampoco está dentro del diff. NACM, en RFC 8341, puede cambiar qué ve o modifica cada identidad sin tocar el esquema. Una diferencia NBC puede, al contrario, quedar fuera del alcance de cierto rol. Hay que probar la matriz efectiva de permisos.

Una conversión necesita contabilidad de pérdida

El borrador dice que la salida puede ayudar a transformar datos de instancia antiguos para la nueva revisión. El conversor todavía decide si elimina nodos, mapea enumeraciones, introduce valores por defecto, normaliza representaciones, divide valores o rechaza casos imposibles de conservar.

RFC 9195 ofrece un patrón útil de identidad y procedencia. Un recibo debería unir el hash de la instancia original y su esquema con la versión del conversor y sus reglas. Debe enumerar nodos eliminados, sintetizados, normalizados y rechazados, hashear el resultado, validarlo contra el esquema compilado destino y documentar pruebas de ida y vuelta o invariantes semánticos.

Que el resultado sea válido en el nuevo esquema no demuestra que conserve significado. Si dos estados antiguos convergen en uno nuevo, la pérdida es real aunque la validación sea verde. Solo el propietario de los datos puede aceptar esa pérdida.

Lo que queda debe ejecutarse

Después llegan las pruebas de implementación. Cuando importe la interoperabilidad, hay que usar parsers o servidores independientes, reproducir configuraciones y RPC representativos, comprobar errores, defaults, codificaciones canónicas, negociación de features y todos los roles NACM afectados. Binarios, módulos, opciones y vectores deben quedar fijados.

También hay que ensayar el orden de despliegue. Una actualización gradual mezcla clientes y servidores viejos y nuevos, quizá con conjuntos distintos de features y deviations. El diff no elige quién va primero, no garantiza continuidad de telemetría y no demuestra que una vuelta atrás pueda leer lo escrito por la versión nueva.

Por último, RFC 8342 separa running, intended y operational porque configuración, intención aplicada y estado observado no son equivalentes. La comparación no mide convergencia, alarmas, latencia ni consecuencias externas. Esa evidencia solo aparece en el sistema desplegado.

La revisión 09 ofrece un recibo preciso y reproducible para la revisión del esquema. Su valor aumenta cuando se mantiene como primer eslabón, sin presentarlo como la cadena completa.

Fuentes

Fuentes primarias: YANG Schema Comparison, revisión 09; registro del Datatracker; YANG 1.1, RFC 7950; YANG Library, RFC 8525; NMDA, RFC 8342; NACM, RFC 8341; YANG Instance Data, RFC 9195; YANG Semantic Versioning, revisión 28; YANG Module Versioning, revisión 16. Cronología: historial del Datatracker.