Resumen

  • draft-ietf-netconf-yang-notifications-versioning-16 permite exigir una revisión exacta o una versión semántica compatible para un módulo nombrado y registrar esa coordenada en los cambios de estado de la suscripción.
  • El content-id de YANG Library observa un ámbito mayor: detecta que cambió el conjunto del servidor cuando una dependencia importada se mueve, pero no identifica la causa ni demuestra incompatibilidad.
  • La continuidad segura requiere renovar el inventario, comparar el cierre de dependencias y validar el decodificador antes de liberar datos; una señal de cambio no equivale a una decisión de negocio.

Hay una forma discreta de perder control sobre la telemetría: seguir recibiendo todos los mensajes y dejar de saber con precisión qué significan. No hace falta una interrupción de red. Basta con que el dispositivo cambie una pieza del modelo que el receptor da por supuesta.

La revisión 16 de YANG-Push Notification Versioning intenta cerrar ese hueco. El mecanismo anterior de YANG-Push establece suscripciones, pero no transporta en ellas la revisión del módulo suscrito. Después de actualizar un nodo, el Publisher puede producir datos bajo otro esquema sin que el Receiver reciba una coordenada suficiente para advertirlo.

El nuevo módulo ietf-yang-push-revision permite que la solicitud nombre una revisión YANG exacta o la versión más reciente compatible con una versión semántica. Si el servidor no puede cumplir, responde con invalid-value y una identidad concreta: revision-unsupported, version-unsupported o incompatible-revision-and-version. Así, la política de aceptación queda expuesta en el protocolo.

El estado de la suscripción incorpora la primera prueba. subscription-started y subscription-modified incluyen el módulo relevante para la ruta, su revisión, una versión opcional y el yang-library-content-id. Cambiar la revisión o versión de un módulo seguido durante la vida de la suscripción cuenta como cambio de política y obliga a enviar subscription-modified. Si, tras reiniciarse, la YANG Library ya no satisface la condición de una suscripción configurada, el Publisher debe remitir subscription-terminated.

Sin embargo, una coordenada directa no describe todo lo que el módulo utiliza. El ejemplo decisivo del borrador se suscribe a /ietf-interfaces:interfaces. La notificación enumera ietf-interfaces. Cuando ese módulo cambia, su coordenada y el content ID pueden hacerlo a la vez. Si solo cambia el ietf-yang-types que importa, la revisión de ietf-interfaces puede permanecer intacta. El Receiver descubre que el estado del esquema es distinto únicamente por el content ID.

Esa señal más amplia procede de YANG Library. Es un identificador definido por la implementación para la información actual de la biblioteca de un servidor concreto. No es un hash universal ni un informe de diferencias. Que cambie no revela el módulo responsable, no demuestra que la ruta suscrita esté afectada y no predice si el decodificador es incompatible.

También puede moverse por una ampliación sin relación alguna con la suscripción. Tratar cada cambio como avería añade paradas evitables; ignorarlo porque la revisión directa sigue igual permite que una dependencia nueva entre en una interpretación antigua. La elección correcta no está en preferir una señal, sino en respetar sus ámbitos.

La coordenada del módulo acredita el linaje seleccionado que el Publisher declara para la ruta. El content ID acredita si el estado más amplio de la biblioteca coincide con el recibido antes. Ninguno certifica las consultas almacenadas, el esquema de persistencia, los cuadros de mando o la automatización que consumen después los valores.

Por eso la evidencia operativa debe formar una cadena. Se registra la identidad del Publisher, su capacidad anunciada, el identificador local de suscripción, el filtro o ruta, las restricciones aceptadas, las coordenadas iniciales y el content ID. Cuando llega un cambio de estado, el Receiver compara ambos ámbitos. Si se mueve el content ID, obtiene una YANG Library nueva, calcula los imports e includes relevantes, valida o selecciona el decodificador y después decide si continúa.

Los mensajes ya almacenados temporalmente siguen perteneciendo al recibo con el que se produjeron. No deben reinterpretarse en silencio con la instantánea más reciente. La prueba del decodificador, la compatibilidad de almacenamiento, el acuse del consumidor y la autorización de automatización son recibos posteriores e independientes.

La escritura de restricciones también es un punto de control. El borrador permite crearlas, cambiarlas y borrarlas, y exige que solo accedan actores autorizados. RFC 8341 define NACM para este tipo de control. Quien rebaja una condición de versión decide qué contrato de interpretación acepta la organización.

La revisión 16 está fechada el 17 de septiembre de 2026. Su historial en Datatracker la sitúa en IETF Last Call hasta el 29 de septiembre, sin fecha de telechat en el registro congelado. La validación YANG del día 27 informó de cero errores y avisos, lo que confirma la comprobación del módulo presentado con esas herramientas, no su corrección operativa. El texto de la revisión sigue siendo un borrador modificable.

RFC 8639 establece las notificaciones por suscripción; RFC 8641, YANG-Push; y RFC 7950, las revisiones e importaciones de YANG. Los borradores de versionado de módulos y versionado semántico siguen en desarrollo. RFC 9196 aporta otro marco para seleccionar versiones. Ninguna etiqueta de compatibilidad sustituye la prueba de un consumidor real.

Fuentes