Resumen

  • La marca describe configuración proporcionada por el sistema que un cliente no puede cambiar por la vía normal; no congela la capacidad del servidor para modificarla.
  • La ausencia de una anotación explícita puede resolverse por herencia o por el valor predeterminado del nivel superior.
  • Un recibo temporal debe conservar la consulta, el origen de herencia, la instantánea, la autoridad del servidor y la causa real de un rechazo de escritura.

La palabra nombra una frontera, no una eternidad

En otros contextos, «inmutable» sugiere que un objeto permanecerá idéntico con el paso del tiempo. En draft-ietf-netmod-immutable-flag-14 la palabra tiene un alcance operativo. El servidor señala una instancia de configuración del sistema que no permitirá que el cliente sustituya por un valor distinto en un datastore de lectura y escritura ni retire de la configuración intended.

La necesidad surge porque el árbol de configuración no siempre cabe en la división sencilla entre config true y datos de estado. El sistema puede aportar una entrada que deba existir, permitir que el cliente configure nodos debajo de ella o mezclar entradas predefinidas con otras creadas por usuarios. Explicar cada restricción en texto libre no ayuda a una herramienta de automatización. Una anotación de metadatos sí puede hacerlo.

La propuesta insiste en que describe comportamiento existente y no lo prescribe. Además, la configuración inmutable del sistema puede ser creada, actualizada y eliminada por el servidor. No hay contradicción: la inmutabilidad responde quién puede actuar desde la interfaz del cliente, no si el valor será igual después de un cambio de hardware o de una nueva versión.

Cuando una plataforma de cumplimiento traduce verdadero como «no puede cambiar», pierde ese sujeto. La frase correcta es «el cliente no puede cambiarlo por esta vía». Solo esa formulación deja espacio para registrar una transición controlada por el servidor.

Para verla hay que pedirla

La anotación no se adjunta a todas las respuestas. El cliente incluye with-immutability cuando consulta los datastores de solo lectura system, intended u operational. Pedirla sobre otro datastore produce un error según el borrador. En NETCONF, la biblioteca YANG permite descubrir el módulo correspondiente. En RESTCONF, la capacidad se anuncia mediante un identificador específico.

La prueba comienza antes del booleano. Debe saberse que el servidor admitía la capacidad, qué datastore y qué subárbol solicitó el cliente, qué identidad tenía permiso para leerlo y cuándo llegó la respuesta. La fotografía de un nodo sin esa envoltura no permite distinguir una observación válida de una interpretación posterior.

Los equipos antiguos crean más estados. Un cliente anterior no pide la metainformación y no la recibe. Un cliente nuevo ante un servidor anterior puede recibir un error por parámetro desconocido o ver cómo se ignora el parámetro. Una anotación ausente también puede haber sido suprimida porque se hereda o coincide con el valor predeterminado. Por eso ausencia y mutabilidad no son sinónimos.

Resolver el árbol es parte del resultado

Un hijo sin anotación explícita hereda el estado de su padre. Para un nodo superior sin marca, el valor predeterminado es falso. Los descendientes pueden reiniciar el estado heredado y cambiar lo que se aplica a sus propios subárboles. El texto no fija un máximo de cambios de inmutabilidad a través del árbol.

Esta economía de representación traslada trabajo al cliente y al auditor. Guardar solo el resultado verdadero o falso elimina la explicación. Hace falta conservar si la decisión fue explícita, heredada o predeterminada, y qué ancestro o reinicio determinó el resultado. Si cambia el padre, esa procedencia permite calcular qué descendientes requieren nueva observación.

Las listas muestran por qué la ruta exacta importa. Los metadatos se aplican a instancias. Dos entradas de una misma lista pueden diferir. Una lista completa no recibe una única anotación en el sentido de RFC 7952; parte de su conducta puede llegar por herencia, mientras una entrada concreta reinicia el estado. Agregar, retirar, modificar o reordenar no siempre quedan restringidos de la misma manera.

El recibo mínimo debe incluir ruta de instancia, tipo de nodo, revisión del esquema, marca explícita, valor resuelto y origen de herencia. El booleano es el resultado de una evaluación del árbol, no un hecho independiente de su contexto.

Repetir el valor en running no cambia su dueño

El cliente puede configurar en running el mismo valor que ya aporta el sistema y luego retirar esa entrada. La configuración intended sigue reflejando el valor del sistema. El cliente ha cambiado la representación visible en el datastore escribible, pero no ha adquirido autoridad sobre el origen.

Un registro de cambios que solo ve running puede afirmar que el cliente «creó» el nodo. Esa descripción será incompleta si se usa para atribuir la configuración efectiva. En dirección contraria, un nodo inmutable del sistema puede no aparecer en running hasta que se repita explícitamente. Un inventario basado solo en running puede omitir la restricción que gobierna el dispositivo.

Se necesitan dos acontecimientos: el intento o la copia del cliente, y el acontecimiento que estableció el valor del sistema. Este último puede provenir de detección de hardware, perfil de arranque o política del producto. La anotación estándar no lo identifica. Cuando la plataforma carece de ese dato, debe reconocer «origen del servidor desconocido» en vez de fabricar una explicación.

El control de acceso decide primero

Si el servidor usa NACM, evalúa el acceso antes de comprobar la inmutabilidad. Una persona no autorizada obtiene una respuesta de acceso denegado aunque la operación también hubiera chocado con un nodo inmutable. Ese orden limita la información revelada.

También cambia la lectura de los fallos. Un rechazo no demuestra automáticamente que funcionó la política de inmutabilidad. La identidad autenticada, la operación, la ruta, el resultado NACM y la etiqueta de error deben conservarse antes de clasificar el caso. De otro modo, una métrica de «ediciones evitadas» mezclará permisos, validaciones y mutabilidad.

La propia anotación revela qué partes de una configuración son rígidas. El borrador advierte que esta información podría orientar a un atacante. Solo un cliente autorizado a leer el nodo puede obtenerla, y las protecciones de NETCONF o RESTCONF siguen siendo necesarias. Un almacén analítico que reciba la anotación sin su alcance de lectura puede ensanchar la audiencia sin darse cuenta.

Un recibo con caducidad de observación

No es necesario hacer más grande el estándar. Junto a la respuesta puede mantenerse un recibo local que identifique servidor o elemento lógico, versión, datastore, módulo y revisión YANG, capacidad y protocolo. Después registra subárbol, ruta, valor, estado inmutable resuelto, origen explícito o heredado, hora de respuesta y, si existe, identificador o resumen criptográfico de la instantánea.

El siguiente bloque pertenece al gobierno local: fuente de configuración del sistema, autoridad, último cambio del servidor y motivo. Lo que no pueda probarse queda vacío. Para una edición intentada se añaden rol, intención, resultado NACM, resultado de inmutabilidad y error devuelto.

El recibo termina con una fecha de revisión. De ese modo «observado como inmutable» no se transforma en «certificado para siempre». Si el servidor cambia el valor, se crea otro recibo y se conserva el anterior. La secuencia documenta la transición sin negar la frontera que existía para el cliente.

Meter toda esa historia en la anotación destruiría su sencillez común. La solución es conservar pequeño el contrato interoperable y unirlo, fuera del protocolo, con los hechos que la operación realmente posee.

La adopción se parece a una matriz

En el momento de la investigación, la revisión 14 había sido aprobada por el IESG y estaba en la cola editorial, aunque seguía siendo un Internet-Draft activo. Su validación YANG informaba cero errores y advertencias. Ninguna de esas etapas demuestra despliegue.

Habrá servidores con y sin capacidad, clientes que la soliciten o no, y combinaciones nuevas-antiguas que rechacen o ignoren el parámetro. También habrá valores ausentes que deban resolverse por herencia. Una cifra única de compatibilidad oculta más de lo que explica.

La unidad útil es una ruta completada: capacidad descubierta, petición válida, respuesta recibida, estado resuelto y, si hubo edición, resultado clasificado después del acceso. La casilla donde termina cada ruta señala una decisión concreta de actualización, configuración o observabilidad.

Fuentes