Resumen

  • El borrador SAMP, revisión 04, incorpora record_revision a los resultados CONFIG y EXEC. Cada cambio relevante del resultado aumenta el número y preserva las versiones previas en un historial de solo adición. La revisión 03 carecía de ese campo.
  • Una resolución tardía necesita prueba del efecto atribuible a la operación original. Reenviar idéntica solicitud recupera el resultado más reciente sin repetir la ejecución. Si el extremo no puede determinar cuál es la última revisión confirmada, responde back_pressure sin declarar un resultado.

El registro de ayer también cuenta

Una orden CONFIG puede recibir una respuesta indeterminada justo cuando un operador termina su turno. El siguiente ve el ajuste deseado en pantalla y marca «éxito». ¿Lo produjo esa orden o la intervención de otra persona? Esa pregunta decide si el libro de operaciones sirve como prueba o como decoración.

La nueva versión del texto ata cada resultado a la referencia de operación, la solicitud autenticada y el contexto de admisión originales. El primer resultado autoritativo lleva revisión 1. Una prueba posterior, validada para esa misma operación, puede llevar el estado a revisión 2. La observación inicial, el vínculo de autorización, la prueba y la hora en que se resolvió el caso quedan en el historial. La misma solicitud, enviada de nuevo byte por byte, consulta el resultado; no vuelve a mover la máquina.

Un estado posterior que parece correcto no alcanza. El borrador exige que un perfil de evidencia atribuya el efecto a la orden concreta. Ni un permiso de política, ni un indicador de salud, ni el mero valor final del ajuste establecen esa causalidad. Si un resultado terminal ya estaba confirmado, una observación que lo contradiga se registra como inconsistencia de auditoría. No recibe licencia para cambiar a escondidas el veredicto anterior.

Hay otra separación incómoda y útil: que la acción se haya ejecutado y que la prueba se haya guardado de forma duradera son hechos distintos. El campo audit_persistence puede señalar un fallo aunque execution_outcome confirme el efecto. Si no es posible confirmar la última revisión comprometida tras un reinicio, el extremo retiene el resultado y devuelve back_pressure. El gestor conserva la revisión más alta que haya aceptado; una inferior indica retroceso, y el mismo número con otro contenido indica conflicto. El último paquete recibido no gana por llegar último.

La ficha del IETF identifica una propuesta individual con destino Experimental. Falta una traza autenticada que atraviese respuesta incierta, prueba tardía y reinicio para comprobar cómo se comporta una implementación.

Fuentes: revisión 04; revisión 03; estado IETF.