Resumen

  • Un borrador activo de NETCONF permite fijar una revisión exacta o pedir la versión semántica compatible más reciente de un módulo YANG-Push, y añade versión e identificador de contenido de la biblioteca YANG a los avisos del ciclo de vida.
  • Esas señales pueden impedir o descubrir parte de la deriva de esquema. No prueban que los módulos importados sean compatibles, que el receptor ejecute el decodificador correcto, que una política conserve su sentido ni que una acción de red haya producido el resultado esperado.

Una caída total es sencilla de clasificar. Hay ausencia de mensajes, una alarma objetiva y una hora de inicio. La deriva semántica es más peligrosa porque conserva la apariencia de servicio. El sistema sigue produciendo números; lo que cambia es la relación entre esos números y la decisión que alguien programó meses atrás.

YANG-Push separa dos objetos que las consolas suelen mezclar. La suscripción describe qué actualizaciones deben publicarse y con qué política. La biblioteca YANG del dispositivo describe el conjunto de módulos, revisiones, imports y desviaciones que dan forma a esas actualizaciones. Una suscripción configurada puede sobrevivir a una actualización del publicador. La biblioteca que encuentra al volver puede no ser la que existía cuando se creó.

draft-ietf-netconf-yang-notifications-versioning-16, fechado el 17 de septiembre de 2026, intenta hacer visible esa separación. El Datatracker lo registra como trabajo activo del grupo NETCONF, remitido al IESG para Proposed Standard y en Last Call hasta el 29 de septiembre. Sigue siendo un Internet-Draft. No debe presentarse como RFC final ni como certificación de productos.

Su propuesta es concreta: incorporar una condición de versión al contrato de la suscripción y comunicar el estado del esquema cuando la suscripción empieza o cambia. En lugar de esperar a que un consumidor falle, el sistema puede rechazar una combinación imposible o emitir una señal atribuible de que el suelo cambió.

Fijar una fecha o aceptar una familia compatible

La restricción revision selecciona una fecha exacta del módulo. Es útil cuando la reproducción importa más que la evolución automática. Si el publicador no dispone de esa revisión, devuelve revision-unsupported. No debería elegir silenciosamente una alternativa parecida.

La restricción version pide la versión semántica compatible más reciente. Permite recibir mejoras declaradas retrocompatibles sin cambiar la solicitud en cada revisión. Cuando no hay una versión admisible, el error es version-unsupported. Si revisión y versión se proporcionan juntas pero se contradicen, el error incompatible-revision-and-version registra el conflicto. Los tres casos se expresan como errores RPC de aplicación invalid-value.

La diferencia tiene consecuencias de gobierno. La fecha exacta reduce ambigüedad y aumenta la probabilidad de una parada controlada al actualizar. La versión compatible mejora continuidad y traslada parte de la confianza a la disciplina con la que se declaran los cambios. Ninguna política es correcta para todos los consumidores. Una automatización que modifica rutas puede exigir más inmovilidad que un panel exploratorio.

En una suscripción configurada, el momento crítico aparece después de reiniciar el nodo. El publicador compara la condición persistente con la biblioteca YANG activa. Si ya no coincide, el borrador exige subscription-terminated. La configuración guardada no obliga al sistema a representar compatibilidad inexistente.

Cuando sí puede continuar, subscription-started y subscription-modified incluyen nombre del módulo, revisión, versión opcional y yang-library-content-id. Un cambio de revisión o versión durante la vida de la suscripción se considera cambio de política y debe emitir subscription-modified. La continuidad deja de ser un supuesto invisible.

La etiqueta correcta puede acompañar al binario equivocado

Imaginemos que el publicador declara exactamente la revisión pedida. El receptor almacena el dato y una auditoría lo encuentra. Aun así, un worker puede estar ejecutando enlaces generados con una revisión anterior. Otro puede haber cargado el nuevo módulo pero mantener un mapeo antiguo en memoria. La base de datos puede truncar una nueva enumeración. La alerta puede seguir leyendo un campo que ya cambió de función.

El recibo de revisión sólo cubre el punto donde el publicador describe su contrato. No instala artefactos en el receptor ni demuestra interpretación. Por eso el registro operativo debe añadir el build de ambos extremos, el identificador de suscripción, la condición solicitada, la biblioteca efectiva, el hash del módulo cargado, la versión del decodificador, la transformación aplicada y el resultado de un corpus de repetición.

La prioridad del código en ejecución exige responder qué artefacto trabajó realmente con cada dato. La validación del módulo ietf-yang-push-revision publicada por el Datatracker el 28 de septiembre mostró cero errores y cero advertencias. Es una señal sólida sobre la sintaxis y las herramientas del modelo incluido. No observa ningún router, colector o pipeline desplegado.

Ese matiz evita dos excesos. El primero rechaza el estándar porque no resuelve toda la cadena; sería injusto, pues resuelve una ausencia real de señal. El segundo convierte la señal en prueba total; sería peligroso, porque concede al metadato autoridad sobre código que nunca observó. La arquitectura responsable conserva el logro y su límite.

La compatibilidad semántica no conoce todas las dependencias locales

Los borradores de versionado de módulos YANG y YANG SemVer crean un vocabulario para declarar evolución compatible y no compatible. Ese vocabulario permite que una solicitud exprese un rango sensato. Sin embargo, la compatibilidad declarada no ejecuta la aplicación consumidora.

Un nodo nuevo y opcional puede activar un bug en un generador. Una identidad añadida puede convertirse en un caso por defecto que una regla trata como normal. Un cambio declarado compatible puede alterar el volumen o la cardinalidad y desbordar una etapa. También puede existir una dependencia accidental en el orden, en una ausencia o en una conducta nunca prometida.

Por tanto, “última versión compatible” debe abrir una verificación, no cerrarla. El receptor compara dependencias, carga los artefactos candidatos y repite valores representativos y límites. Si el uso real sigue siendo correcto, acepta. Si no puede demostrarlo, aísla los datos o suspende las acciones de mayor impacto. La etiqueta define el perímetro esperado; la ejecución demuestra si este consumidor cabe dentro.

No todos los cambios requieren el mismo nivel de intervención. Una consola humana puede mostrar datos con una advertencia mientras se completa la prueba. Una automatización irreversible debería detenerse. El protocolo comparte una mínima especificación de versión; cada dominio conserva una decisión local explícita y auditable.

El import puede moverse sin tocar el módulo visible

Una selección YANG depende con frecuencia de tipos, identidades y agrupaciones importadas. El módulo nombrado por la suscripción puede conservar su revisión mientras una dependencia cambia. Mirar sólo el módulo directo deja un agujero precisamente donde la reutilización del modelo es más útil.

El content-id de RFC 8525 sirve como detector amplio. Identifica, de manera propia de la implementación, el contenido actual de la biblioteca YANG. Si cambia, indica que el inventario del dispositivo cambió y justifica comparar el estado anterior con el nuevo.

No dice qué módulo cambió ni si el cambio afecta la ruta seleccionada. Puede variar por una función sin relación con la suscripción. Tampoco debe usarse como hash universal entre fabricantes. Su igualdad ayuda a establecer continuidad dentro del comportamiento del publicador; su diferencia abre una investigación.

El proceso correcto tiene cuatro pasos: detectar la variación, obtener la biblioteca, calcular un diff consciente de los imports y probar el subconjunto afectado. Saltar del primer paso a una terminación global crea falsas interrupciones. Saltar del primer paso a “no importa” permite que una dependencia cambie sin control.

El valor de este diseño es que no intenta codificar toda la política del consumidor en el protocolo. Ofrece una señal directa para el módulo y una señal general para la biblioteca. El receptor mantiene la libertad —y la responsabilidad— de decidir qué evidencia necesita antes de seguir actuando.

El evento de modificación necesita una posición en el flujo

Una notificación subscription-modified no hace atómica la migración completa. Puede haber datos antiguos en tránsito. Los consumidores paralelos pueden recibir el evento en momentos distintos. Un proceso puede actualizar el registro del esquema mientras otro aún decodifica con la versión anterior.

Hace falta un límite reproducible. El sistema debería registrar la última unidad tratada con el esquema anterior, la posición del aviso y la primera aceptada con el nuevo. Los mensajes en la zona ambigua se retienen para repetirlos después de cargar el artefacto correcto. Cada salida relevante conserva la huella del esquema y del decodificador que la produjo.

La terminación por incompatibilidad también requiere propagación. subscription-terminated demuestra una decisión del publicador. No demuestra que una cola derivada se haya detenido, que una caché haya caducado o que una orden pendiente se haya cancelado. Esas acciones forman parte del control local de daños.

La capacidad yang-push-module-revision-supported sólo anuncia que el publicador soporta los metadatos de revisión o versión en sus avisos. El descubrimiento de capacidad permite elegir el procedimiento. Las pruebas de actualización, reinicio, pérdida y reordenamiento demuestran el comportamiento real.

Del dato entregado al efecto observado hay varias autoridades

Un sistema puede registrar una cadena de evidencias sin fingir que son una sola. Primero aparece el conjunto de módulos del publicador. Después, la aceptación de la condición de la suscripción. Luego, el aviso de versión y la entrega ordenada. El receptor carga el esquema, decodifica, transforma y presenta una afirmación a una política. La política decide si esa afirmación es suficiente; una identidad autorizada intenta actuar; el efecto se observa por una vía independiente.

El flujo vivo pertenece al principio de la cadena. No puede demostrar los pasos posteriores. Un valor correctamente decodificado puede estar fuera de fecha para la decisión. Una decisión correcta puede carecer de autorización. Una operación autorizada puede fallar. Un cambio observado puede proceder de otra causa.

Las capas de realidad ayudan a no prestar poder simbólico a un indicador verde. Cuando se mantiene la separación, el diagnóstico mejora: el equipo de transporte no recibe la culpa por una transformación; el equipo de modelos no recibe la culpa por una autorización; operaciones no atribuye a YANG un efecto que nadie midió.

La trazabilidad se consigue con identificadores comunes y tiempos, no con una conclusión común. Cada capa firma su propia afirmación y conserva su incertidumbre. Ésa es la diferencia entre un historial de ejecución y una narrativa construida después del incidente.

Quien cambia la versión cambia una política

Permitir a un cliente modificar la condición de revisión o versión es otorgarle influencia sobre la semántica aceptada. Puede anclar el sistema en un artefacto obsoleto, provocar una terminación o ampliar la compatibilidad más allá de lo probado. El campo merece controles similares a otras configuraciones de automatización.

NETCONF y RESTCONF siguen necesitando transporte seguro y autenticación mutua. NACM mantiene su papel para autorizar lectura y modificación. El registro de auditoría debería incluir principal, método, valor anterior, valor nuevo, suscripción, biblioteca del publicador y motivo aprobado. El proceso que intenta recuperar disponibilidad no debe poder relajar su propia condición sin una autoridad externa.

Además, la autorización para crear una suscripción no autoriza una acción basada en sus datos. La segunda decisión debe ocurrir donde el dato adquiere consecuencia, con política, identidad y contexto propios.

Las implementaciones declaradas son una lista de pruebas pendientes

El borrador recoge estados comunicados por sus autores para Huawei VRP, 6WIND VSR y Cisco IOS XR, con coberturas parciales diferentes. Esa información apoya la discusión de viabilidad. No equivale a verificación independiente ni a interoperabilidad entre productos.

Una evaluación comprueba errores de revisión y versión, conflicto de condiciones, selección compatible, terminación tras reinicio, modificación en servicio y preservación del content-id. Incluye cambios sólo en imports y cambios irrelevantes de biblioteca. Después introduce pérdida, duplicación, reordenamiento y rollback.

El resultado debe asociarse al build probado, al tráfico capturado y al estado durable del receptor. Una declaración de implementación no puede sustituir esa matriz. La interoperabilidad es un hecho entre ejecuciones concretas.

Diseñar la actualización antes de necesitarla

Antes de desplegar, archivar la biblioteca actual, los módulos, bindings, contenedores de decodificación y casos de prueba. Comparar el candidato con dependencias transitivas. Ensayar tanto la aceptación como el rechazo y reservar capacidad para repetir datos.

Durante la intervención, capturar el aviso de ciclo de vida y su posición. Recuperar la biblioteca cuando cambia el content-id. Mantener en pausa las acciones irreversibles hasta concluir la prueba local. Si la condición no se cumple, fallar de manera visible y conservar la causa.

Después, comparar no sólo mensajes sino objetos decodificados, transformaciones, decisiones y efectos. Verificar que el rollback restaura publicador y consumidor de forma coordinada. El objetivo no es que la suscripción sobreviva a cualquier precio. Es que ninguna continuidad aparente oculte un contrato distinto.

El versionado de notificaciones YANG no convierte el esquema en verdad operacional. Hace algo más preciso: permite que el cambio deje rastro. El liderazgo técnico debe aprovechar ese rastro para exigir código, política y resultado observables en cada frontera siguiente.

Fuentes