Resumen

  • La revisión 10 propone un candidato por sesión, un update atómico parecido a un rebase, conflictos por solapamiento de nodos, tres modos de resolución y comparaciones opcionales con el punto de creación o última actualización.
  • La propuesta reduce commits accidentales de trabajo ajeno, sin demostrar por sí sola frescura de la base, cobertura semántica de la concurrencia, autoridad de la resolución, aplicación efectiva ni mejora de negocio.

Una copia privada no congela running

draft-ietf-netconf-privcand-10 parte de un fallo sencillo: en un candidato compartido, un cliente puede comprometer cambios que otro todavía estaba preparando. El servidor crea una copia de running cuando la primera operación la necesita y la asocia a una sesión NETCONF o a un cliente RESTCONF.

Después, otros escritores pueden cambiar running. El propio borrador advierte que una rama larga puede quedar muy desfasada. La actualidad vuelve mediante update, mediante la actualización automática anunciada por el servidor o mediante la actualización implícita previa al commit.

El registro de Datatracker muestra la revisión 10 como Internet-Draft activo del grupo NETCONF, en Working Group Last Call y con objetivo Proposed Standard. El historial fecha la revisión el 24 de agosto de 2026. No es un RFC ni una prueba de implementación.

Ocho comprobantes para no sobreinterpretar el merge

Base. Registrar dispositivo, revisión o hash exacto de running, biblioteca YANG, esquema, valores por defecto, creación, último update y capacidad trigger=all-updates. Comparar contra creation-point, last-update o running actual produce afirmaciones distintas. discard-changes también puede volver a una fotografía ya antigua.

Propiedad. En NETCONF ambas partes anuncian la capacidad privada. Un servidor que no la soporte puede ignorar la petición y seguir sin aislamiento o cerrar la sesión. El recibo debe unir identidad autenticada, sesión, capacidades negociadas, vida del candidato y operaciones con el digest del conjunto de cambios. Otras interfaces del dispositivo quedan fuera del alcance del borrador.

RESTCONF no negocia capacidad desde el cliente. Conforme a RFC 8040, el borrador hace que el servidor use un candidato privado y lo comprometa automáticamente para conservar la expectativa de escritura inmediata. El modelo probatorio no es idéntico al de NETCONF.

Diferencias. La extensión de RFC 9144 puede comparar el candidato con running, la creación o la última actualización, aunque el punto de referencia es opcional. Filtros, opción all, esquema, defaults y visibilidad delimitan el resultado. no-matches significa que nada coincidió y nada se comparó.

RFC 8341 aplica control de acceso por operación y contenido; datos sin permiso de lectura pueden desaparecer silenciosamente. Un resultado vacío solo habla de la vista efectivamente comparada.

Concurrencia. El núcleo detecta cambios coincidentes sobre el mismo nodo: valor, existencia, orden de listas, contenedores de presencia, hojas y metadatos YANG. Un servidor puede ampliar las comprobaciones. Sin embargo, ediciones en nodos distintos pueden combinarse para agotar capacidad, romper redundancia o contradecir una política. El comprobante debe incluir escritores, intervalos y validaciones de invariantes entre nodos.

Resolución. revert-on-conflict falla sin importar cambios; prefer-candidate conserva el valor conflictivo del candidato; prefer-running lo reemplaza. Con actualización automática, el modo del sistema puede alterar la rama sin que el cliente se entere. Guardar disparador, modo, nodos, antes/después, intención descartada y autoridad responsable.

Commit. Primero se ejecuta un update atómico implícito con revert-on-conflict; solo después se copia el candidato a running. El conflicto obliga a fallar. En RFC 6241, <ok> confirma que la operación no produjo un error de protocolo. No mide la conducta de la red. El message ID, hash del candidato, resultado del update, informe de conflicto y nueva revisión deben formar una unidad.

Convergencia. RFC 8342 mantiene separados running, intended y operational; transformaciones, falta de recursos y retrasos pueden abrir diferencias. RFC 8526 da acceso NETCONF a esas vistas, no equivalencia. Compararlas exige dispositivo y ventana temporal declarados.

Resultado. Un observador independiente verifica interfaz, ruta, cola, política o forwarding y, después, la población de clientes, SLA o negocio afectada. Estado aplicado y recuperación comercial son dos afirmaciones diferentes.

Fuentes y revisión histórica

La revisión OPSDIR de -06 señaló cuestiones sobre puntos de referencia, definición del datastore y seguridad. La revisión YANG Doctors de -06 concluyó “Almost ready”. Ninguna es una revisión nueva de -10.

El marco técnico consultado comprende RFC 6241, RFC 8040, RFC 8341, RFC 8342, RFC 8526 y RFC 9144. Describe semántica, no un despliegue concreto.