Resumen

  • draft-ietf-netmod-yang-packages-09 convierte includes, excludes, dependencias, módulos, features, deviations y mounts en un resolved package schema mediante reglas recursivas y ordenadas.
  • Que el archivo valide, el grafo no tenga ciclos y complete sea verdadero demuestra propiedades de una composición declarada; no demuestra procedencia de bytes, carga real, igualdad cliente-servidor, compatibilidad de instancias ni éxito operativo.

El error más caro puede empezar con una comprobación correcta. El paquete supera el esquema JSON. Su nombre y versión no se repiten. Las inclusiones no forman un ciclo. El resolved schema contiene un solo módulo implementado por nombre. El resultado es limpio. El controlador, sin embargo, usó un caché anterior y el servidor anunció una copia distinta bajo la misma identidad.

La revisión 09 fue publicada el 6 de julio de 2026. Datatracker la presenta como Internet-Draft activo del grupo NETMOD, con intención Standards Track y caducidad el 7 de enero de 2027. No es prueba de adopción. Sí ofrece una disciplina importante para describir conjuntos de modelos que antes podían viajar como carpetas, etiquetas o acuerdos tácitos.

El resultado nace de operaciones, no de una lista plana

includes puede incorporar paquetes, módulos implementados, módulos usados solo para imports y features obligatorios. excludes elimina elementos heredados. depends-on orienta la resolución externa de un paquete incompleto sin agregar ese contenido a su propio esquema. mount define paquetes y features en puntos montados, con la opción de conservar o desechar la herencia.

El resolved schema se calcula primero resolviendo recursivamente cada paquete incluido y después fusionando sus resultados con las decisiones locales. Los módulos implementados se unen, se resuelven conflictos, las entradas locales sobrescriben y las exclusiones filtran. Los import-only pueden conservar varias versiones. Las features se acumulan y luego se añaden o quitan. Excluir un módulo excluye sus features.

En un mount, inherit-packages=false puede retirar el conjunto heredado y dejar que la entrada local defina el subesquema. La identidad del paquete superior no avisa por sí sola de esa sustitución. Las listas de location también preservan orden: la primera aparición mantiene prioridad y las nuevas URI se anexan. La accesibilidad de esa URI no autentica lo recuperado.

La regla automática selecciona, pero no entiende

Si dos paquetes traen versiones distintas del mismo módulo implementado, la selección automática compara major, minor y patch cuando ambas etiquetas son YANG Semver, ignorando modificadores de compatibilidad, prerelease y build metadata. Una etiqueta Semver vence a otra que no lo sea; si ninguna lo es, gana la revision-date más reciente. Una entrada local puede imponer otra versión.

La decisión es reproducible, pero no conoce el contrato de un cliente. Tampoco sabe cuál rama esperaba el comité de cambio. Por eso el recibo debe conservar candidatos, reglas, ganador, sobrescrituras, exclusiones y avisos. Un código de salida cero es demasiado pequeño para describir la decisión.

La clasificación de diferencias pertenece al trabajo específico de schema comparison y no se repite aquí. Incluso una diferencia bien clasificada necesita entradas identificadas y pruebas de consumo.

La completitud tiene un perímetro exacto

complete significa que todos los imports de los módulos incluidos directa o indirectamente pueden resolverse con versiones definidas dentro del paquete. Los paquetes incompletos pueden nombrar en depends-on el contexto con el que deberían combinarse.

No significa que los bytes estén firmados, que dos mirrors no hayan divergido, que cada submodule se haya descargado o que los datos de una instancia se comporten igual. Los submodules aparecen principalmente para ofrecer locations; la resolución decide por versión del módulo y puede asumir equivalencia cuando hay empate. Esa suposición necesita una verificación de contenido fuera del cálculo.

La unicidad global de name/version es una norma de identidad. No es content addressing. Si el mismo par devuelve dos cuerpos, hace falta registrar editor, URI, fecha de obtención, origen del caché y digest exacto.

Catálogo, binding y carga son tres hechos distintos

La lista /packages/package del servidor enumera paquetes conocidos y puede contener varias versiones. El borrador advierte que una entrada no implica implementación ni actividad en un datastore. El binding relevante se incorpora a YANG Library: uno o más paquetes y additional features describen un schema concreto.

La resolución de ese binding debe ser completa y coincidir exactamente con el module-set de YANG Library. Esa obligación facilita una comparación poderosa. Aun así, el servidor declara ambos lados; el cliente debe verificar y fechar la observación. content-id cambia cuando cambia la biblioteca, pero es generado por el servidor y no funciona como hash universal.

Los .ypkg son archivos JSON de instance data. Pueden venir del servidor, de una location o de un caché del mismo name/version. Validarlos comprueba estructura. No demuestra autoría, actualidad, elección recursiva ni activación de proceso. RFC 9195 separa además esos archivos de los protocolos que manipulan configuración o estado vivo.

La conformidad termina antes del servicio

Un servidor que no implementa fielmente un paquete de industria puede anunciar un server implementation package que lo incluya y refine: otra versión, deviations, módulos o features excluidos. Es mejor una variación explícita que una promesa vaga. Pero una descripción honesta de esquema no ejecuta el software del cliente.

La cadena de prueba debe conservar por separado identidad y autoridad; bytes y digest; validación estructural; recorrido recursivo; conflicto y ganador; cierre de imports y submodules; esquema resuelto; binding por datastore; carga de proceso; conjuntos de cliente y servidor; casos de configuración, estado, RPC, notifications y acceso; orden de despliegue y rollback; estado en vivo; resultado de red y negocio.

Fuentes primarias

Se consultaron la revisión 09 y su registro/historial de Datatracker, RFC 7950, RFC 8525, RFC 9195, RFC 8528, RFC 8342, YANG Module Versioning revisión 17, YANG Semantic Versioning revisión 28 y las actas NETMOD de IETF 122: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages-09; https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-packages/; https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-packages/history/; https://www.rfc-editor.org/rfc/rfc7950.html; https://www.rfc-editor.org/rfc/rfc8525.html; https://www.rfc-editor.org/rfc/rfc9195.html; https://www.rfc-editor.org/rfc/rfc8528.html; https://www.rfc-editor.org/rfc/rfc8342.html; https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-17; https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-28; https://datatracker.ietf.org/doc/minutes-122-netmod-202503190600/00/.