Resumen

  • draft-feng-netconf-naim-op-00 permite adjuntar objetos Operation IR de compensación destinados a invertir o mitigar cambios ya ejecutados. El propio texto obliga a pensar en el fallo de esa compensación, los tiempos agotados y la pérdida de conectividad durante el rollback.
  • Compartir un identificador de transacción sirve para correlacionar operaciones; no especifica un commit atómico, aislamiento, bloqueo, orden global ni un punto común al que todos los destinos puedan regresar.
  • Para afirmar que hubo restauración hacen falta recibos del recorrido completo: estado de referencia, autoridad para cada paso, lecturas de precondición, mensajes aplicados, concurrencia, resultados de la compensación, observación posterior y verificación independiente del servicio.

El segundo cambio no borra el primero

Una orden aparentemente sencilla puede mostrar el problema. Un agente propone cambiar la política de enrutamiento de diez interfaces y volver a la referencia anterior si falla la comprobación. El Handler valida el objeto y empieza a ejecutar. Tres equipos aceptan; el cuarto deja de responder; el test de servicio se vuelve rojo.

La compensación ya no ocurre contra el mundo que vio el planificador. Otro controlador ha actualizado una interfaz. Un vecino ha procesado anuncios. Una alarma ha abierto un caso en otro sistema. La credencial usada al principio puede no autorizar una eliminación. La ruta de gestión puede seguir caída. Reaplicar valores antiguos puede recuperar dos destinos, pisar una edición legítima en otro y no llegar al último.

La definición del borrador es precisa: una Compensation Operation está destinada a invertir o mitigar el efecto de una operación previa. No dice que siempre lo consiga. Tampoco restringe el resultado a una restauración exacta; admite la mitigación. Es una distinción pequeña en la gramática y enorme en la gobernanza.

Qué representa Operation IR

La propuesta crea un objeto intermedio independiente del protocolo entre la intención en lenguaje natural y la ejecución mediante NETCONF, RESTCONF u otro backend. Puede expresar escrituras, lecturas, RPC o acciones, filtros, datastore, precondiciones, valores dinámicos, metadatos de transacción y compensaciones. El agente de IA codifica intención; el Handler determinista valida, consulta el estado vivo, compila mensajes y los ejecuta.

No es todavía un estándar adoptado. Datatracker registra la revisión 00, del 18 de julio de 2026, como Internet-Draft individual activo, sin stream RFC y sin Intended RFC status formal. La página advierte que cualquiera puede presentar un I-D, que éste no está respaldado por el IETF y que carece de posición formal. El encabezado enviado incluye “NETCONF Working Group” e “Intended status: Standards Track”; son declaraciones del documento, no prueba de adopción por el grupo de trabajo ni de consenso IETF.

La propuesta tampoco estandariza los algoritmos que derivan automáticamente la compensación, la planificación interna ni la lógica privada del motor. Por eso no basta con registrar que “se activó rollback”. Si el Handler construyó los pasos, debe conservarse cada objeto exacto que produjo y la base factual que utilizó.

Un identificador común sólo responde «qué cosas están relacionadas»

La sección 12 permite asociar varias operaciones por un identificador de transacción compartido. Ese dato ayuda a reunir una historia dispersa. Pero no responde si todos los cambios se confirman juntos, si quedan aislados de otros escritores, si existe un bloqueo, si el orden está garantizado o si hay un registro duradero.

En un grupo heterogéneo, esas ausencias son materiales. Un equipo puede usar un datastore candidato y confirmed commit; otro puede escribir en running; una acción puede llamar a un servicio externo. Una etiqueta compartida no armoniza sus capacidades ni sus tiempos de fallo. Correlación no es atomicidad.

Tampoco existe un inverso universal. Crear una política, asociarla y activar un servicio produce dependencias. La secuencia de compensación debe respetarlas. Si una segunda aplicación ya usa la política, borrarla porque pertenecía al plan original puede crear una interrupción nueva. La recuperación es una decisión bajo estado actualizado, no la reproducción automática de un guion antiguo.

La autoridad debe volver a demostrarse

El borrador dice que las compensaciones deberían someterse a las mismas expectativas de autorización, validación y registro que las operaciones normales. En seguridad, vuelve a citar de forma específica la autorización de compensaciones y la auditoría de ejecución y rollback.

La acción inversa puede tocar otro nodo o requerir otro privilegio. Un rol capaz de crear quizá no pueda borrar. Un permiso puede haber caducado. Una referencia dinámica puede resolverse de otra manera. RFC 8341 permite controlar por separado operaciones y contenido en NETCONF y RESTCONF; no hay una excepción automática porque la etiqueta diga “recuperación”.

Las precondiciones ayudan: si un valor esperado ya no coincide, la operación no debe ejecutarse. Pero una lectura correcta antes del envío sólo prueba esa condición en ese instante. No demuestra aplicación, persistencia ni recuperación de servicio. El recibo debe registrar principal, política de acceso, destino resuelto, valor observado y resultado para cada compensación.

El camino de recuperación también se rompe

La propuesta pide que las implementaciones con transacciones definan su conducta ante fallo de precondición, fallo a mitad de grupo, fallo de compensación, timeout y pérdida de conectividad durante rollback. Esta enumeración impide tratar la recuperación como una zona libre de errores.

Si desaparece la sesión después de enviar una escritura, el Handler puede no saber si el equipo la recibió. Repetir puede duplicar un RPC no idempotente; no repetir puede dejar el cambio activo. Un resultado binario no describe esa incertidumbre. Cada paso debería avanzar por estados observables: planificado, autorizado, comprobado, enviado, reconocido, observado y validado por servicio. Lo desconocido debe seguir siendo desconocido.

NETCONF enseña cuánto importa el alcance

RFC 6241 ofrece una comparación concreta. Con la capacidad correspondiente, rollback-on-error puede detener un edit-config y restaurar la configuración especificada al estado completo que tenía al inicio de esa operación. Es una semántica delimitada por protocolo, capacidad y operación.

Incluso ahí, el RFC advierte que, en configuración compartida, el rollback puede alterar o borrar cambios de otras sesiones si no se usa bloqueo. También define rollback-failed. Confirmed commit depende de su propia capacidad y del datastore candidato.

Una compensación Operation IR puede terminar traducida a ese mecanismo, a una escritura RESTCONF o a una acción distinta. No puede tomar la garantía más fuerte de un backend y extenderla por nombre a todos los demás. Menos aún puede convertir una reversión de configuración en prueba de que se deshicieron efectos externos.

La misma configuración no es el mismo mundo

RFC 8342 distingue configuración pretendida y estado operacional. Aunque un subtree vuelva a los valores anteriores, el estado aplicado puede diferir. Fuera del datastore, la divergencia es inevitable: paquetes ya enviados, notificaciones consumidas, credenciales reveladas, temporizadores vencidos, alarmas de clientes y decisiones humanas permanecen en la historia.

La compensación puede ser correcta y valiosa sin prometer más. “Mitigado” puede ser el resultado honesto. El fallo de control aparece cuando una consola traduce automáticamente “compensación completada” a “sin impacto”.

El dry-run declara un plan, no el futuro

El modo dry-run no debe aplicar cambios y debería mostrar destinos, valores, datastore, comprobaciones, mensajes, resumen de compensación, efectos y limitaciones. El mismo texto admite que el resultado puede ser incompleto si el estado vivo, la autorización o condiciones externas sólo pueden verificarse durante la ejecución.

Una buena vista previa debe destacar qué se resolvió contra una instantánea, qué permiso sigue pendiente y qué efecto no posee inverso. La estructura facilita revisar una decisión; no la vuelve profecía.

Cómo sería un recibo honesto

La evidencia debe enlazar la intención inmutable y su contexto semántico; el modelo canónico del Handler; la autorización y las precondiciones de ida; los mensajes exactos; el orden de confirmaciones y silencios; cada objeto de compensación; sus nuevos controles; los bloqueos y escritores concurrentes; el estado configurado y operacional observado después; los efectos externos residuales; y una prueba de servicio independiente.

El cierre necesita tres campos distintos: compensación intentada, estado modelado restaurado dentro de un alcance declarado y servicio recuperado. Ninguno autoriza a rellenar automáticamente el siguiente. El identificador de transacción une las pruebas; no sustituye ninguna.

Fuentes