Resumen

  • RFC 10016 incorpora a NMDA el datastore <system>, de solo lectura, para configuración suministrada por el sistema que los clientes no pueden borrar. Los clientes sí pueden referenciar sus nodos, sustituir valores permitidos desde <running> o añadir descendientes configurables bajo entradas creadas por el sistema.
  • origin=system identifica la fuente, no una aprobación humana, una permanencia o una aplicación correcta. Al retirar una sustitución puede volver el valor del sistema a <intended>; un cambio de hardware, licencia, función o software también puede hacer aparecer o desaparecer nodos.

En la revisión constaba una sola eliminación. Se quitaba un valor de <running> para «dejar el parámetro sin configurar». Sin embargo, el equipo no quedó vacío. Al desaparecer la sustitución, un valor que ya residía en <system> ganó la combinación, entró en <intended> y pudo alcanzar el estado operativo.

La interfaz había descrito la operación, pero no su consecuencia. RFC 10016 permite representar esa consecuencia al añadir un datastore convencional para la configuración que aporta el servidor. Es de solo lectura para clientes NETCONF y RESTCONF. No por ello deja de participar en la construcción de la configuración efectiva.

El problema de gobierno surge cuando «no escribible por este actor» se convierte en «incapaz de cambiar». Son afirmaciones distintas. El sistema puede regenerar el dato bajo otras condiciones; <running> puede cambiar qué valor prevalece; <intended> puede validar una intención que no llega completa a <operational>. Ninguna de esas diferencias cabe en una etiqueta de candado.

Una casa explícita para la configuración del sistema

La arquitectura NMDA de RFC 8342 ya separa la configuración que se pretende aplicar de la configuración y el estado realmente usados. También reconoce procedencias convencionales, dinámicas, aprendidas, del sistema y predeterminadas. RFC 10016 define que cualquier configuración presente en <system> es configuración del sistema, esté o no referenciada y aplicada.

La imposibilidad de borrado por parte del cliente forma parte de la definición. Un dato que el servidor entrega pero el cliente puede eliminar no cuenta aquí como system configuration. Un servidor compatible implementa la identidad ietf-system-datastore sobre modelos YANG definidos por RFC 7950. La capacidad puede descubrirse mediante YANG Library, descrita en RFC 8525.

La visibilidad común no uniforma el ciclo de vida. La configuración siempre presente se genera al encender el dispositivo sin depender de un recurso físico concreto; el RFC usa como ejemplo una interfaz de loopback. La configuración condicionalmente presente depende de una tarjeta, un recurso, una licencia o una función. Cuando la condición cesa, el nodo puede dejar de existir.

<system> no es persistente entre reinicios. El servidor reconstruye sus contenidos conforme al entorno que encuentra. Observar el mismo camino antes y después no prueba que se conservara el mismo objeto. Guardar <running> tampoco conserva por sí solo todos los insumos que formarán el siguiente <intended>.

La fuente es de solo lectura; la precedencia no

El cliente puede construir en <running> referencias hacia nodos del sistema. Si el servidor autoriza una sustitución, una hoja coincidente en <running> prevalece sobre el valor de <system>. También puede permitir que se añadan descendientes configurables a una entrada de lista cuya existencia procede del sistema.

La combinación tiene una regla decisiva: en caso de coincidencia, <running> gana al formar <intended>. Cuando hay transformaciones —por ejemplo, expansión de plantillas o eliminación de configuración inactiva— cada datastore debe transformarse de manera independiente antes de combinarse. Dos volcados previos a esa fase no prueban cuál será el resultado.

Si el sistema aporta A y el operador escribe B, B prevalece. Cuando el operador borra B, no ha borrado A: ni siquiera tiene autorización para hacerlo dentro de <system>. A vuelve a <intended> y puede aplicarse. Por eso, borrar una sustitución debe revisarse como la selección de un valor alternativo, no como la ausencia de una selección.

También puede ocurrir lo opuesto. Al retirarse hardware o expirar una licencia, desaparece un nodo condicional de <system>. La configuración que lo referencia puede seguir en <running> y <intended>, pero no aparecer en <operational> porque el recurso ya no existe. La intención persiste como dato; el objeto real al que apuntaba, no.

Procedencia no equivale a consentimiento

RFC 7952 define el mecanismo de metadatos utilizado para anotar procedencia. RFC 10016 aclara que la configuración que fluye de <system> lleva origen system, salvo que haya sido configurada explícitamente o sustituida en <running>. La configuración nacida en <running> conserva su origen conforme a las reglas de NMDA.

La anotación contesta «¿qué fuente suministró este nodo?». No identifica a la persona que aceptó el efecto. El valor puede proceder de una imagen de plataforma, un subsistema de licencias, un administrador de recursos o un proceso local. Cualquiera puede actuar sin una decisión humana contemporánea. A su vez, una escritura en <running> puede haberla realizado un controlador autónomo.

Leer system como «confiable» transforma una decisión del producto en política local. Leer running como «querido por el operador» transforma un resultado automático en consentimiento. La procedencia es indispensable, pero solo se vuelve rendición de cuentas al conectarse con autoridad de cambio, revisión y dueño del riesgo.

<intended> no acredita lo aplicado

Cuando cambia <system>, RFC 10016 exige que el servidor actualice y valide de inmediato <intended>. También señala que <running> debería seguir siendo un árbol válido tras el cambio, aunque deja fuera de alcance el mecanismo para conseguirlo. Son garantías de procesamiento, no una comprobación de que el valor llegó al hardware.

El documento no altera <operational>. Bajo RFC 8342, recursos ausentes, retardos de propagación, fallos y configuración remanente pueden separar intención y realidad. La cadena completa transforma <system> y <running> por separado, los combina en <intended> y aplica condicionalmente ese resultado a <operational>. Cada flecha necesita evidencia propia.

Los cambios del sistema pueden notificarse con suscripciones YANG y actualizaciones de datastore como las de RFC 8639 y RFC 8641. Que el emisor produzca una notificación demuestra un hecho dentro de su cobertura. No demuestra que todos los consumidores la recibieran, recalcularan su política y comprobaran el nuevo estado.

Tampoco debe confundirse <system> con <factory-default>. RFC 8808 define un datastore de valores de fábrica y una operación de restauración. <system> representa lo que el sistema actual entrega bajo las condiciones actuales. Pueden coincidir algunos valores sin que coincidan las funciones.

Un recibo de origen y precedencia

Un recibo de origen y precedencia puede convertir el ajuste efectivo en un objeto auditable. Para cada nodo material registraría camino, huella del valor, origen y condición de presencia. La condición incluiría la época de hardware, licencia, función, arranque y software, evitando describir un valor del sistema como constante sin fecha.

Después anotaría la mutabilidad y el resultado de la combinación: si se permite sustituirlo, qué nodo de <running> lo referencia u oculta, qué descendientes añadió un cliente, qué transformaciones se hicieron en cada fuente y qué valor ganó en <intended>. Antes de autorizar la eliminación de una sustitución, mostraría el valor que reaparecerá.

La sección de activación compararía <intended> con <operational>: hora de aplicación, presencia del recurso, retraso, fallo, estado remanente y observación utilizada para afirmar que está vigente. Una referencia válida puede apuntar a un recurso inactivo; un árbol válido puede describir hardware que ya no está.

La sección de autoridad distinguiría al proveedor del sistema, el cliente de configuración, el aprobador operativo y el dueño del riesgo. Una actualización, transición de licencia, inserción de tarjeta o confirmación de política quedaría enlazada a quien aceptó el resultado. Los detalles sensibles pueden protegerse mientras se conservan huellas y referencias controladas.

Este recibo es una propuesta editorial de gobierno de Daniel Kade, no una obligación nueva de RFC 10016. Su objetivo es conservar la distancia entre una fuente visible, el ganador de la precedencia, una decisión aprobada y un resultado aplicado.

La seguridad empieza por controlar la lectura

Solo lectura no significa inocuo. RFC 10016 advierte que <system> puede contener identificadores de hardware, políticas de seguridad y recursos críticos. Debe controlarse el acceso a nodos y subárboles sensibles y registrar los intentos de lectura. RFC 8341 aporta NACM para limitar lo que pueden consultar usuarios NETCONF y RESTCONF.

La sustitución abre un riesgo diferente. Un atacante o cliente defectuoso puede escribir en <running> una hoja que oculte un valor de seguridad del sistema, provocando evasión de política o indisponibilidad aunque <system> nunca se modifique. Vigilar solo escrituras en <system> significaría observar precisamente la ruta que el cliente tiene cerrada.

RFC 10016 da a los operadores una vista estándar de la configuración del sistema. No convierte esa fuente en voluntad humana, no congela la elección y no certifica la aplicación. La visibilidad permite empezar a controlar; la precedencia y el estado operativo determinan si el control termina.

Fuentes