Resumen

  • La configuración explícita ajena a plantillas tiene máxima prioridad; el ancestro interior vence al exterior; y, en un mismo nodo, gana la primera plantilla aplicable de la lista ordenada por el cliente.
  • Reproducir intended requiere running y system completos y contemporáneos, definiciones, ubicaciones, orden, claves evaluadas con I-Regexp y sobrescrituras. No prueba quién envió la edición, ausencia de carreras, NACM, identidad de implementación ni entrega de tráfico.

La frase “se aplicaron las plantillas A y B” parece una descripción suficiente hasta que A y B escriben el mismo nodo. En ese momento, una lista deja de ser inventario y se convierte en una decisión. La revisión 03 de draft-tt-netmod-yang-config-templates especifica esa decisión con un detalle que conviene conservar sin inflarlo.

Hay tres reglas. Primero, una configuración ordinaria y explícita en running o system manda sobre el contenido heredado. Segundo, una plantilla aplicada en el ancestro más cercano al nodo manda sobre otra situada más arriba. Tercero, si el conflicto nace en una misma ubicación, importa el orden que envió el cliente.

El ejemplo del borrador elimina una ambigüedad importante. La lista es ethernet-interface base-interface; para las entradas Ethernet que coinciden, el MTU 1500 de la primera plantilla desplaza el 65536 de la segunda. Es la primera plantilla aplicable, no la última, la que conserva la prioridad. Guardar los nombres en un conjunto o reordenarlos al serializar destruye información ejecutable.

La sustitución de la metainformación también tiene semántica propia. Un valor no vacío reemplaza la lista entera; un valor vacío o sólo con espacios la elimina; omitir el atributo conserva la lista previa. Para reconstruir una edición no basta con un registro diferencial improvisado: hace falta el valor completo recibido.

El patrón no contiene sus coincidencias

Las plantillas pueden seleccionar instancias de lista con expresiones regulares cuando la clave tiene tipo integrado string o deriva de él. La referencia es I-Regexp, RFC 9485, un subconjunto reducido de las expresiones de XML Schema. Esa decisión facilita la interoperabilidad, pero el texto del patrón sigue siendo sólo una parte de la evidencia.

eth.* no enumera las interfaces. Para saber qué tocó, hay que conservar las claves que existían en la misma captura, la revisión de reglas y la interpretación del motor. Una entrada generada por system, un cambio de nombre o una toma fuera de tiempo altera la coincidencia aunque la cadena no cambie.

Una plantilla puede ser parcial. El servidor debería validarla cuando sea posible; el resultado fusionado debe cumplir las restricciones YANG aplicables. El Datatracker muestra actualmente 0 errores y 0 avisos para su comprobación del módulo extraído ietf-config-template (revision 2026-07-03). Ese dato describe una ejecución de herramientas sobre el documento. No demuestra adopción por NETMOD, aprobación del IETF, conformidad de un producto ni interoperabilidad.

intended no es el historial de entrada

NMDA conserva en running la representación compacta: definiciones, metadatos de aplicación y valores explícitos. La expansión aparece en intended. Cambiar una plantilla aplicada en running o system debería reflejarse allí.

La regla de borrado muestra por qué el control de tiempo importa. Una plantilla en uso no puede borrarse; el servidor debe rechazarlo con data-missing. Antes hay que modificar todas las referencias y luego eliminar la definición. El borrador establece el orden lógico, no una garantía automática de atomicidad entre solicitudes. Otro cliente puede intervenir entre ambos pasos. La transacción o el bloqueo deben demostrarse en el sistema concreto.

Un árbol intended leído con éxito tampoco identifica de forma única la edición original. Distintas definiciones ocultas por la misma sobrescritura explícita pueden producir igual salida. Dos órdenes diferentes pueden coincidir mientras no exista conflicto. El resultado es una observación válida, no una máquina del tiempo.

Reproducción significa congelar todas las entradas

Una expansión fuera del equipo es útil si recibe un paquete indivisible: revisión exacta del borrador y reglas; identidad del servidor y del expansor; running y system completos del mismo momento; todas las definiciones; rutas y profundidad de aplicación; listas ordenadas; semántica I-Regexp y claves candidatas; sobrescrituras explícitas; y una relación de versión o tiempo entre los datos.

El hash debe cubrir el paquete. Después se compara el árbol reproducido, nodo y valor, con la lectura del servidor. Coincidir prueba acuerdo entre dos transformaciones para esas entradas. No prueba que todos los servidores compartan código o que no haya habido una carrera antes de la captura.

Los recibos de NETCONF y RESTCONF pertenecen a otra etapa. Informan sobre solicitudes y recursos, no sobre la aplicación futura. NACM, RFC 8341, define quién puede leer o cambiar cada superficie; hay que ensayar la matriz de roles. Y RFC 8342 separa intended de operational: una limitación de recursos puede impedir que lo previsto se aplique. El FIB, los paquetes y el servicio exigen observadores adicionales.

Estado documental, sin atajos

La revisión está fechada el 3 de julio de 2026. Su cabecera dice “Intended status: Standards Track”. Por separado, Datatracker la clasifica como Internet-Draft individual activo, sin stream, sin intended RFC status y con estado I-D Exists. La descripción honesta conserva ambos campos; no afirma una adopción de grupo ni un RFC futuro.

Fuentes

Fuentes primarias: revisión 03; registro Datatracker; YANG 1.1, RFC 7950; metadatos YANG, RFC 7952; NMDA, RFC 8342; NACM, RFC 8341; NETCONF, RFC 6241; RESTCONF, RFC 8040; I-Regexp, RFC 9485. Cronología: historial Datatracker. Fuentes de encuadre: System Configuration revisión 20; Lu Heng sobre primacía del código en ejecución, especificación inicial mínima y capas de realidad.