Resumen

  • La revisión 10 del borrador sobre candidatas privadas crea un espacio de configuración por sesión NETCONF y define una actualización atómica frente a cambios de running. Cada commit emplea implícitamente revert-on-conflict, de modo que un solapamiento no resuelto detiene la operación.
  • La elección posterior tiene consecuencias opuestas: prefer-candidate conserva el valor privado para que pueda reemplazar el valor en ejecución; prefer-running borra la edición privada conflictiva. El permiso NACM y la publicidad de esas capacidades no contienen el mandato organizativo para escoger al ganador.
  • Un mandato de commit debe unir base de la rama, conflictos, modo aplicado, valores perdidos, dueño de la decisión, alcance aprobado, pruebas y objetivo de reversión. Es una propuesta de Daniel Kade y no forma parte de las exigencias del IETF.

Separar borradores no elimina la disputa

La candidata compartida de RFC 6241 permite preparar una configuración antes de activarla, pero varias sesiones pueden escribir sobre el mismo espacio. El cliente que hace commit puede llevarse consigo una edición que otra sesión dejó allí. Un bloqueo evita parte del riesgo a costa de paralizar a otros actores. El bloqueo parcial de RFC 5717 tampoco demuestra que el commit contiene solo el trabajo de un cliente ni resuelve dos ediciones sobre el mismo árbol; además, exige conocer dependencias entre modelos.

El documento draft-ietf-netconf-privcand-10 intenta conservar la preparación previa sin esa mezcla involuntaria. Es un Internet-Draft activo del grupo NETCONF, publicado el 24 de agosto de 2026, en Working Group Last Call y con destino previsto a Proposed Standard. No es todavía un RFC ni prueba que exista una implantación concreta.

En una sesión NETCONF que negocia la capacidad, la primera operación pertinente crea una candidata privada a partir de running. Solo esa sesión puede acceder a ella mediante NETCONF. Las ediciones permanecen invisibles para otras sesiones y, cuando la conexión se cierra o se pierde, la candidata se destruye junto con cualquier cambio no confirmado.

Es una mejora de control muy concreta. Un cliente ya no debería confirmar sin advertirlo el borrador de otro. También puede haber trabajo paralelo sin convertir el bloqueo global en la arquitectura por defecto. Sin embargo, cuanto mejor funciona el aislamiento, más clara queda otra cuestión: dos ramas pueden expresar intenciones legítimas y aun así chocar con el mismo nodo cuando una de ellas regresa a la realidad de producción.

La propiedad privada de una candidata acredita quién preparó el cambio. No concede preferencia sobre un servicio compartido.

Actualizar significa cambiar el pasado de la rama

La operación update toma el running actual como nueva base y vuelve a aplicar las modificaciones privadas. El borrador exige atomicidad: no debe quedar una combinación parcial si la operación falla.

El conflicto se define pensando en el propósito, no solo en bytes diferentes. Debe haber cambios tanto en running como en la candidata sobre el mismo nodo durante el intervalo, y el cliente podría haber actuado de otra manera si hubiera visto el nuevo punto de partida. Cuentan cambios de valor, existencia, orden definido por el usuario, contenedores de presencia, leaf-lists, hojas y metadatos YANG. El servidor puede añadir comprobaciones y aprovechar identificadores de transacción.

Los nodos se marcan internamente como in conflict. El mecanismo concreto queda fuera del borrador y la marca no se hereda automáticamente por los antecesores. El cliente debería recibir ubicaciones XPath y valores para reconsiderar su intención.

Ese diseño conserva información útil, pero no la historia completa. El dispositivo desconoce si el cambio de producción fue una mitigación de emergencia, si la rama privada pertenece a una migración aprobada, si el nodo es local o controla una dependencia amplia, y si el permiso de ayer sigue siendo válido durante la ventana de hoy. El árbol técnico permite localizar el choque; no puede reconstruir la institución que lo produjo.

Los modos de resolución asignan la pérdida

revert-on-conflict es obligatorio y predeterminado. Si aparece cualquier conflicto, la actualización falla sin fusionar nada. Todo commit ejecuta primero este modo de forma implícita, incluso si el sistema emplea otra preferencia para actualizaciones automáticas. El cliente tiene que editar, descartar o escoger conscientemente otro modo antes de reintentar. Esta fricción es una característica: hace visible el momento en que alguien debe asumir una pérdida.

prefer-candidate mantiene el valor privado en cada nodo conflictivo e incorpora los cambios no conflictivos de running. En el commit posterior, ese valor privado reemplazará lo que ahora existe en producción. La intención sacrificada es la que llegó a running después de crear la rama.

prefer-running introduce en la candidata el valor conflictivo de producción. La rama conserva el resto de su trabajo, pero pierde precisamente las ediciones enfrentadas. La intención sacrificada es la del autor privado.

El nombre de los datastores no establece una jerarquía moral. Una candidata puede ser antigua, incompleta o ajena a una emergencia reciente. Running puede contener un parche temporal que la ventana aprobada debe reemplazar. El reloj técnico tampoco basta: la última escritura no siempre representa la última decisión institucional.

El servidor puede fijar una preferencia distinta para actualizaciones automáticas cuando cambia running. Si se aparta del valor predeterminado debe anunciarlo; también tiene que anunciar los modos compatibles si no ofrece los tres. Saber qué hará la máquina es esencial, pero no equivale a saber quién autorizó esa política, para qué equipos y hasta cuándo.

Aquí aparece un fallo de auditoría sutil. El commit definitivo puede usar revert-on-conflict y terminar sin conflicto porque una actualización automática anterior ya eliminó una de las posiciones. El registro del commit parece impecable mientras el acto decisivo queda atribuido a una opción de servidor sin contexto.

Una sesión NETCONF y una petición RESTCONF tienen tiempos distintos

La capacidad privada se negocia para toda la sesión NETCONF. Si el cliente la solicita y el servidor no la soporta, el servidor puede ignorar la petición por compatibilidad o cerrar la sesión; el borrador aconseja la segunda conducta a implementaciones nuevas. Por eso la intención del cliente de usar privacidad no prueba que la obtuvo.

RESTCONF no permite que el cliente anuncie una capacidad equivalente. Cuando el servidor anuncia soporte, cada escritura sobre el recurso de datos usa una candidata privada para esa petición y la confirma automáticamente. Así se conserva la semántica inmediata que esperan clientes no conscientes de la extensión. No hay que describirlo como un espacio privado persistente con varias operaciones equivalente a NETCONF.

La diferencia temporal cambia el diseño de aprobación. Una rama NETCONF puede vivir mientras cambian la producción, los permisos o la ventana. Una petición RESTCONF concentra edición y activación. Un control humano colocado después de la edición y antes del commit en NETCONF no se traslada automáticamente al otro protocolo.

Credenciales amplias no son un voto permanente

NACM, definido en RFC 8341, puede separar lectura, escritura y ejecución según usuario y contenido. El borrador advierte que update es sensible y que el acceso no autorizado puede alterar una candidata. La autenticación mutua y el transporte seguro siguen siendo imprescindibles.

Pero muchos conflictos peligrosos ocurren entre actores autorizados. Una cuenta de plataforma puede escribir en un subárbol y, aun así, estar aprobada solo para rotar un parámetro, no para deshacer una mitigación. Un administrador puede ejecutar la operación sin tener autoridad para afectar otro servicio conectado por un antecesor. Un controlador puede pertenecer al equipo correcto y actuar después de que expiró su ventana.

NACM responde si una identidad puede hacer algo. La gobernanza del cambio responde si ese flujo puede hacer esto ahora y elegir su valor sobre otro propósito válido. Usar la primera respuesta como sustituto de la segunda convierte un permiso reutilizable en una delegación ilimitada.

La comparación tampoco decide. La extensión de RFC 9144 permite, cuando existe soporte, comparar la candidata privada con running, con su punto de creación o con el último punto de actualización. Es una evidencia excelente para entender qué cambió y cuándo. No conoce el impacto de servicio, la integridad del mapa de dependencias ni la legitimidad del propietario.

El mandato de commit conserva el porqué

No hace falta añadir otro datastore al protocolo. Hace falta rodear la elección destructiva con un mandato de commit de vida corta.

Primero fija el dispositivo, datastore, sesión o petición, identidad autenticada y propietario del proceso automático. Conserva referencias estables al punto de creación, al último update y a la revisión de running. Después adjunta el delta exacto y todos los nodos en conflicto, ampliados con contexto de servicio o antecesores que conozca la política local.

El mandato registra la preferencia predeterminada anunciada, los modos disponibles, si la resolución fue automática o explícita y cuál se aplicó. Sobre todo, formula la pérdida: qué valores de producción serán reemplazados bajo prefer-candidate, qué ediciones privadas desaparecieron bajo prefer-running, o qué desacuerdo permanece tras revert-on-conflict.

La versión de la política NACM documenta la superficie de acceso, pero no actúa como aprobación. Una persona o sistema responsable firma el motivo, el alcance, la ventana, el límite de impacto y la caducidad. Se incluyen comparación, validación y pruebas representativas del servicio.

La parte final describe la salida: uso y plazo de confirmed commit, identificadores persistentes si proceden, observadores de salud y estado exacto de reversión. Tras el commit se conserva una huella de la nueva configuración. Si cambia running, expira la ventana, se modifica la política o desaparece una señal, el mandato deja de ser válido.

Este mandato no es un RPC ni una norma del IETF. Es la propuesta de Daniel Kade para que la decisión institucional no se pierda cuando se destruyan la candidata, la sesión y las marcas de conflicto.

Poder volver no legitima el viaje

Confirmed commit ofrece una defensa importante. Si la sesión se desconecta durante un commit confirmado desde una candidata privada, el borrador mantiene la reversión inmediata de running y descarta la propuesta. La maquinaria limita el riesgo de perder contacto con el dispositivo.

Sin embargo, la reversibilidad no demuestra que la preferencia original estuviera autorizada. Un actor puede ejecutar una decisión impropia y aun disponer de un buen rollback. También puede existir una orden legítima sin una reversión fiable; en ese caso, la falta de reversión debería bloquear el paso, no redefinir quién manda.

discard-changes exige otra cautela lingüística. La candidata vuelve al punto de creación o al último punto de actualización, el más reciente de ambos, que puede diferir del running actual. Descartar no significa necesariamente regresar al estado de producción.

El aislamiento conserva la autoría. La detección de conflictos conserva el desacuerdo. La reversión conserva una salida. Solo un mandato unido a la decisión conserva por qué una intención válida tuvo derecho a imponerse a otra.

Fuentes