Resumen

  • with-immutability permite pedir al servidor anotaciones immutable en datastores de solo lectura. El borrador documenta una conducta existente y no la impone por sí mismo.
  • La propiedad pertenece a instancias, se hereda desde padres, puede restablecerse en descendientes y no puede ser creada por el cliente. Perder el contexto del árbol cambia el significado de la prueba.
  • Un invalid-value vincula una negativa a una petición concreta. No demuestra continuidad entre usuarios, protocolos, versiones, recursos, estado operacional o resultados del servicio.

Supóngase que una plataforma de automatización conserva una lectura con immutable=true y, minutos después, un error invalid-value para la misma ruta. Es razonable concluir que el servidor declaró y aplicó una restricción en esas dos interacciones. El salto indebido consiste en convertir esa conclusión acotada en “esta configuración no puede cambiar”.

El propio borrador 14 evita ese salto. Define la marca como descriptiva, no prescriptiva. El servidor informa de una conducta que ya aplica a ciertos datos de configuración proporcionados por el sistema. La anotación ayuda al cliente a anticipar un rechazo; no crea el comportamiento ni audita el código que lo ejecuta.

Datatracker lo muestra como un Internet-Draft activo de NETMOD, fechado el 2 de julio de 2026 y propuesto para Standards Track. Las revisiones editoriales, el estado de publicación o un informe de validación YANG dicen algo sobre el documento. No acreditan un producto, una red ni una política ejecutada en producción.

Pedir los metadatos también forma parte de la evidencia

Las anotaciones no aparecen sin una solicitud explícita. NETCONF amplía <get-data>; RESTCONF añade with-immutability a GET. Solo es válido al consultar <system>, <intended> u <operational>. Si se usa en otro datastore, el borrador exige unknown-element. En RESTCONF el parámetro no lleva valor; un valor inesperado produce HTTP 400 e invalid-value.

La capacidad se descubre por otra vía. NETCONF puede comprobar en YANG Library si está implementado ietf-immutable-annotation. RESTCONF anuncia una URI específica. Una declaración de capacidad es necesaria para interpretar la respuesta, pero no prueba que todas las instancias se etiqueten bien ni que todas las operaciones de escritura sigan la misma regla.

El caso heredado confirma la importancia de conservar la petición. Un servidor antiguo puede rechazar el parámetro desconocido o ignorarlo. Una respuesta sin marcas, aislada de la capacidad y del datastore consultado, no permite saber si las instancias eran mutables o si la pregunta nunca fue entendida.

Una lista no tiene una sola verdad plana

La marca se aplica a instancias. Dos entradas de una lista pueden tener estados opuestos. Un hijo sin anotación toma el estado del padre, mientras que un nodo superior sin marca parte de false. Un descendiente puede cambiar explícitamente el estado y otros descendientes pueden volver a hacerlo.

Por eso no basta con exportar las rutas marcadas. Si el valor procede del padre, se necesita el contexto que demuestra la herencia. Si existe una excepción mutable bajo un contenedor inmutable, también debe conservarse. RFC 7952 impide adjuntar la anotación a toda una list o leaf-list; las entradas individuales pueden llevarla y la colección completa solo la hereda.

Las operaciones permitidas dependen de esta geometría. Una lista enteramente inmutable no acepta altas, bajas ni reordenación definida por el usuario. Una entrada inmutable protege esa entrada y sus descendientes por defecto, pero no a sus hermanas. El cliente puede copiar en running el mismo valor que proporciona el servidor y borrar después la copia sin alterar el resultado intended.

Además, el servidor debe ignorar cualquier anotación immutable enviada por el cliente. La etiqueta es una afirmación del servidor sobre su propia conducta. Ni una firma del mensaje ni una validación del modelo convierten al cliente en la autoridad que define esa propiedad.

Antes de la inmutabilidad puede decidir NACM

El ejemplo del borrador muestra tanto para NETCONF como para RESTCONF una edición de valor distinto, una ruta de error y invalid-value. Es un recibo preciso, pero sigue describiendo una decisión.

Cuando se aplica NACM, el control de acceso precede a la comprobación de inmutabilidad. Un usuario sin permiso recibe access-denied; el servidor no tiene que revelar si la ruta habría fallado después por immutable. Comparar errores entre identidades sin conservar esta secuencia puede producir una falsa contradicción.

Tampoco una interfaz representa todas las rutas de cambio. Un rechazo NETCONF no examina RESTCONF, una consola local, un gestor del fabricante, el arranque, el proceso de actualización o una acción interna del servidor. Que el borrador exija independencia de protocolo y usuario ofrece una condición de conformidad que probar; no un certificado anticipado para cualquier implementación.

Lo que el servidor controla puede evolucionar

La palabra parece temporal, pero la regla es principalmente institucional: el cliente no puede imponer otro valor; el servidor sí controla la creación, actualización y retirada de su configuración. Cambios de software, hardware, licencia, función habilitada o recursos disponibles pueden alterar la selección.

No toda configuración del sistema es inmutable y la propiedad puede existir aunque no se exponga <system>. Estas precisiones impiden usar la marca como resumen del modelo completo de configuración del sistema. También explican por qué una diferencia en running puede coexistir con un intended idéntico: la copia del cliente puede aparecer o desaparecer sin mover el valor efectivo.

RFC 8342 separa intended de operational. Ver el mismo valor en system, intended y operational en una captura coordinada aumenta la confianza en ese instante. No establece que el recurso subyacente sobreviva a una actualización, que el dispositivo siga aplicando el valor, que el tráfico pase, que la restauración funcione o que se cumpla un compromiso comercial.

La cadena útil tiene ocho eslabones

Primero se conserva la solicitud exacta, la identidad y el datastore. Después, la capacidad y el conjunto de esquemas efectivo. El tercer registro es el subárbol devuelto, con padres, omisiones, herencias y restablecimientos. Le siguen la edición autenticada y la respuesta completa; las vistas coordinadas; el desencadenante que puede cambiar la política; la telemetría y el canario de servicio; y, por último, la recuperación ejecutada y su resultado.

El conjunto primario cerrado contiene la revisión 14, el registro y el historial de Datatracker, los RFC 7952, 7950, 8342, 8525, 8526, 8527, 6241, 8040, 8341 y 9907, y system-configuration 20: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-immutable-flag-14; https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/; https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/history/; https://www.rfc-editor.org/rfc/rfc7952.html; https://www.rfc-editor.org/rfc/rfc7950.html; https://www.rfc-editor.org/rfc/rfc8342.html; https://www.rfc-editor.org/rfc/rfc8525.html; https://www.rfc-editor.org/rfc/rfc8526.html; https://www.rfc-editor.org/rfc/rfc8527.html; https://www.rfc-editor.org/rfc/rfc6241.html; https://www.rfc-editor.org/rfc/rfc8040.html; https://www.rfc-editor.org/rfc/rfc8341.html; https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-20; https://www.rfc-editor.org/rfc/rfc9907.html.

Estas fuentes fijan la semántica propuesta, no la conformidad de un proveedor, la prevalencia, un incidente evitado, una recuperación exitosa ni un resultado del cliente. El apéndice de implementaciones pertenece al borrador y no sustituye una prueba independiente de interoperabilidad.