Resumen

  • Cuando el servidor acepta <commit><confirmed/>, el candidato ya pasa a running. El temporizador no pospone el cambio: conserva una autoridad de restauración hasta que llegue una confirmación válida.
  • La sesión que inicia el procedimiento decide el destino en la modalidad normal. Con persist, el procedimiento sobrevive a esa sesión y otro actor que presente el persist-id correcto puede heredarlo.
  • El cierre del temporizador no demuestra persistencia en startup, aplicación en operational, continuidad de paquetes ni atomicidad entre equipos. Cada afirmación necesita un dueño y una evidencia distinta.

Un éxito que todavía contenía su propia revocación

El operador cambia la dirección de gestión de un dispositivo remoto. Primero trabaja sobre candidate. Después envía un commit confirmado. La respuesta es <ok> y la interfaz adopta la dirección nueva. Durante unos instantes, todo parece correcto; luego desaparece la sesión.

El protocolo no necesita que el operador vuelva a entrar para ordenar el regreso. En la modalidad ligada a la sesión, su desaparición es una condición suficiente: el servidor debe restaurar la configuración que estaba activa antes del commit. Si lo que desaparece no es la sesión sino la energía y el equipo reinicia antes de la confirmación, también debe restaurarla. Si el reloj llega a cero, ocurre lo mismo.

Hay una idea decisiva en esa secuencia. El cambio no era una simulación. Había cruzado a running y podía modificar el comportamiento del equipo. Lo provisional era su derecho a permanecer. Por eso <ok> puede ser absolutamente verdadero y, sin embargo, insuficiente para afirmar que la organización tomó una decisión final.

El confirmed commit resuelve una amenaza acotada: la modificación que corta el camino usado para verificarla o revertirla. No certifica la intención, no coordina toda la red y no observa el plano de datos. Su precisión es una ventaja siempre que el operador no le atribuya poderes que no tiene.

La gramática del cambio no cabe en «aplicado»

El RFC 6241 separa los datastores y las operaciones. :candidate ofrece un lugar para preparar una configuración completa sin alterar la que está en uso. <commit> copia candidate a running. La capacidad :confirmed-commit:1.1, que depende de candidate, añade el periodo durante el cual el servidor conserva la obligación de volver atrás.

Si el cliente no envía confirm-timeout, el plazo predeterminado es de 600 segundos. Puede completar el procedimiento con un commit posterior. Puede renovarlo con otro commit confirmado y un plazo aplicable. Puede cancelarlo explícitamente con <cancel-commit>. Si no hace nada, el timeout restaura la base anterior.

Es importante nombrar cada verbo:

  • validar pregunta si el candidato satisface el contrato modelado;
  • comprometer copia el candidato a running;
  • confirmar extingue la obligación temporal de restauración;
  • cancelar o expirar recupera la base preexistente;
  • persistir en startup decide qué se cargará tras un arranque;
  • observar comprueba qué ha aplicado realmente el sistema.

Decir «se aplicó» para los seis verbos convierte una cronología comprobable en una opinión.

El RFC 6470 permite emitir notificaciones con los eventos start, extend, complete, cancel y timeout. Son piezas valiosas para reconstruir la vida del procedimiento. No reemplazan la lectura del estado: un colector puede perder el evento, y complete no dice que una ASIC haya programado la entrada ni que el servicio funcione.

El propietario invisible del reloj

Todo temporizador crea una autoridad. Alguien elige su duración, alguien puede prolongarlo y alguien decide que la evidencia acumulada basta para cerrarlo. El valor de diez minutos que aparece por defecto en el estándar facilita la interoperabilidad; no conoce el riesgo de una política BGP, la lentitud de un chasis ni el tiempo necesario para probar un servicio de voz.

Una ventana corta limita cuánto puede vivir una configuración dañina, pero puede vencer antes de que los síntomas aparezcan. Una ventana larga permite observación profunda, pero expone durante más tiempo el estado provisional y facilita que otros trabajos se mezclen con él. Extender automáticamente cada vez que un canario tarda transforma el límite en una formalidad.

La supervisión debe usar el reloj del servidor como referencia y registrar cuándo aceptó el commit, no sólo cuándo el controlador recibió la respuesta. En una operación sobre muchos equipos, las llamadas se escalonan y cada dispositivo tiene su propia expiración. Una interfaz que muestra un solo contador puede ocultar el primero que ya está cerca de revertir.

La pregunta profesional no es «¿cuánto queda?», sino «¿qué prueba falta y quién tiene autoridad para ganar más tiempo o para hacer definitivo el estado actual?».

Persistencia: continuidad sin identidad

La modalidad normal une la suerte del cambio a la sesión iniciadora. Es una protección sencilla: si el operador pierde el canal antes de confirmar, el equipo vuelve. Pero existen cambios cuyo validador no debe vivir dentro de la misma conexión. La forma persistente permite desacoplarlos.

El iniciador entrega un valor opaco persist. Desde entonces, el procedimiento puede sobrevivir al cierre de su sesión. Otra sesión presenta el valor coincidente como persist-id para confirmar, ampliar o cancelar cuando corresponda. El mecanismo transmite capacidad de decisión sin exigir continuidad de transporte.

Eso no lo convierte en aprobación humana. El servidor compara valores; no comprueba que la segunda sesión pertenezca a otra persona, que tenga independencia orgánica o que haya leído el cambio. Es posible que un mismo orquestador genere el token, ejecute el candidato y lo confirme con otra conexión. Técnicamente son dos sesiones; institucionalmente sigue siendo un solo decisor.

La custodia importa. Si el token queda únicamente en memoria y el servicio cae, nadie puede completar un estado persistente. Si aparece en logs, tickets y trazas, muchas personas pueden adquirir una capacidad que quizá no debían tener. El registro puede conservar una huella segura para correlación mientras el valor utilizable permanece en un almacén restringido. La autorización NACM de la sesión que usa el token sigue siendo otra barrera, no una propiedad absorbida por persist-id.

La restauración no sabe qué cambio era «ajeno»

Una reversión por confirmed commit restaura el estado previo. No está definida como la resta algebraica de las líneas que el iniciador recuerda haber tocado. Si otro escritor modifica running durante la ventana, la vuelta a la imagen anterior puede alterar o borrar ese trabajo. El RFC 6241 advierte de este riesgo y recomienda disciplina de bloqueo.

Supongamos que A modifica una lista de acceso bajo confirmed commit. B, desde otra automatización, cambia telemetría después. A pierde su sesión. El dispositivo no dispone de la historia política que dice que B era independiente; dispone de una base para restaurar. Sin una garantía más precisa, B puede desaparecer con A.

El bloqueo global de NETCONF excluye escritores sobre un datastore. El RFC 5717 permite bloqueos parciales, pero obliga a negar uno nuevo sobre running mientras exista un confirmed commit: el servidor podría necesitar recuperar una zona más amplia que la solicitada por el bloqueo.

La seguridad del rollback depende entonces de cinco pruebas: la huella exacta de la base; la cobertura real del bloqueo; los caminos de escritura que respetan esa cobertura; la ausencia o atribución de cambios concurrentes; y el estado obtenido tras la restauración. Si falta una, «podemos volver» es una esperanza, no una capacidad demostrada.

Cuando RESTCONF se convierte en confirmador

La separación organizativa entre una API y otra puede no existir en el dispositivo. En el modelo del RFC 8040, RESTCONF trabaja sobre datastores conceptuales compartidos con un servidor NETCONF. Si se usa candidate, cada edición RESTCONF válida genera su commit.

Durante un confirmed commit NETCONF no persistente, ese commit adicional actúa como confirmación. Un cliente RESTCONF puede cerrar la ventana que otro abrió con NETCONF. No necesita enviar una operación llamada «confirmar»; la semántica surge de compartir el mismo estado.

Si el procedimiento es persistente y exige persist-id, RESTCONF no tiene dónde transportarlo. Debe rechazar la edición con HTTP 409 in-use. Un bloqueo NETCONF también puede provocar 409. Contar esos errores y correlacionarlos con el procedimiento pendiente revela una disputa de autoridad, no sólo una aplicación ruidosa.

El tratamiento de startup también depende del camino. RFC 8040 indica que, si el servidor colocalizado soporta startup, una edición RESTCONF correcta lo actualiza automáticamente. En NETCONF, el commit a running no demuestra por sí solo la copia a startup. La misma intención escrita por dos API puede dejar evidencias de persistencia distintas.

El usuario autenticado todavía puede carecer de permiso

El transporte NETCONF sobre SSH, especificado en el RFC 6242, protege los mensajes y autentica el extremo según la política desplegada. No asigna por sí mismo derecho sobre <commit> ni sobre cada nodo del árbol.

El NACM del RFC 8341 evalúa operaciones, datos y notificaciones. Una sesión autenticada puede no poder comprometer. Una operación permitida puede dirigirse a un nodo prohibido. Una cuenta de recuperación puede tener una excepción extraordinaria. El registro debe conservar esas decisiones por separado para que la palabra «autorizado» no se reduzca a «tenía una clave SSH».

Luego llega la validez del modelo. El RFC 7950 define YANG 1.1, con tipos, referencias y restricciones. Un candidato que pasa esas reglas puede seguir apuntando al vecino equivocado o reservar un recurso inexistente. La sintaxis y la coherencia modelada son requisitos, no un sustituto de la intención.

El servidor puede exponer con RFC 8525 los módulos, features, desviaciones y asociaciones de schema que implementa, además de un content-id específico. Esa fotografía debe acompañar la validación. Si cambia entre la preparación y el commit, «el mismo candidato» puede entrar en un contrato distinto.

Running, intended y operational cuentan historias distintas

El NMDA del RFC 8342 permite abandonar la ficción de que la configuración escrita es automáticamente la configuración usada. Running contiene la configuración validada. El sistema puede transformarla para formar intended. Operational muestra la configuración y el estado que está usando en ese momento.

Una configuración para un componente ausente puede permanecer en running e intended y no aparecer aplicada en operational. Un recurso físico puede tardar. Una dependencia puede impedir la aplicación. El hardware puede escoger un valor efectivo diferente dentro de sus limitaciones. Ninguno de esos hechos reabre automáticamente el temporizador ya confirmado.

Por eso la evidencia debe seguir el mecanismo afectado. Si se cambia una interfaz, hay que observar la interfaz y probar paquetes. Si se cambia routing, hay que observar adyacencias, rutas recibidas y elegidas, instalación y forwarding. Si se cambia gestión, hay que probar el nuevo camino y conservar uno de recuperación. La igualdad de configuración puede ser necesaria y seguir siendo operacionalmente muda.

La jerarquía queda clara: ticket aprobado, sesión autenticada, RPC autorizado, candidato válido, running final, intended producido, operational aplicado y red funcional. Cada capa puede ser cierta mientras la siguiente es falsa.

El confirmed commit no se vuelve atómico por repetición

La arquitectura de gestión descrita en el RFC 6244 permite que un controlador coordine muchos servidores. Pero cada dispositivo mantiene su propia base, su propio reloj, sus capacidades y su proceso de aplicación. Enviar la misma secuencia a diez equipos no crea un commit distribuido.

Los tiempos de red escalonan los inicios. Uno puede negar un bloqueo. Otro puede reiniciar. Un tercero puede aceptar running pero no aplicar el recurso. Si el controlador confirma nueve y falla el décimo, ha consolidado una topología parcial. Cancelar los nueve no garantiza que el forwarding anterior reaparezca en todos.

El orquestador debe construir el nivel que falta: identidad de transacción, bases por dispositivo, orden de fases, condiciones de aborto, canarios, compensaciones y reconciliación. Puede preferir un canario gradual a un todo-o-nada imposible. Lo que no puede hacer es llamar «atómico» a un grupo de respuestas <ok>.

La afirmación mínima que merece confianza

Los identificadores de capacidades registrados por IANA permiten que cliente y servidor nombren el mismo mecanismo. La especificación común debe ser estrecha; las decisiones de riesgo siguen siendo locales. Ese diseño funciona cuando la organización conserva la modestia de cada prueba.

Después de <ok>, una afirmación defendible enumera el servidor, la identidad, la política de acceso, el schema, el candidato, la base, el bloqueo, el plazo, la sesión o token y el evento final. Después añade startup, intended, operational y canarios. Para una red, añade cada equipo y la reconciliación.

La autoridad práctica no pertenece al diagrama que dice quién debería controlar el cambio, sino al actor que puede enviar el RPC, poseer el token, cerrar el plazo, escribir startup y decidir que las mediciones bastan. Hacer visibles esas manos es la diferencia entre gobernanza y ceremonia.

Sources