Resumen

  • draft-ietf-netmod-yang-xml-00 reúne las reglas que convierten nodos y tipos YANG en elementos y valores XML, incluido el tratamiento de namespaces, listas, metadatos y referencias.
  • La buena formación, la validación o la igualdad tras canonicalización no demuestran el mismo árbol efectivo, la misma política de defaults, una RPC aceptada, un datastore modificado ni un resultado de red.

Un auditor recibe dos respuestas de configuración. En una, un valor por defecto no aparece. En la otra, está escrito de forma explícita. Ambas pasan el parser; tras una transformación, incluso terminan con una vista visual idéntica. Pero el primer servidor opera en modo trim y el segundo conserva datos escritos por el cliente. Si más tarde cambia el default del modelo, los dos historiales no tienen el mismo significado.

Ese caso muestra por qué una especificación de codificación no debe convertirse en una teoría completa de equivalencia. XML Encoding of Data Modeled with YANG, revisión 00 del 8 de junio de 2026, extrae de RFC 7950 las reglas normativas de XML para configuración, estado, parámetros de RPC/action y notificaciones. Es un Internet-Draft de Standards Track, expira el 10 de diciembre de 2026 y todavía deja FIXME en IANA y seguridad. Describe una frontera útil, no una certificación de productos.

Un nombre XML combina identificador y namespace

Cada instancia de nodo YANG se codifica como un elemento cuyo nombre local coincide con el identificador YANG y cuyo namespace procede del módulo. El namespace debe establecerse en cada elemento superior y cambiar cuando un hijo fue definido por otro módulo.

El prefijo no es identidad. Dos prefijos pueden vincularse al mismo URI y representar el mismo nombre expandido. Por eso comparar texto produce falsos positivos. Pero normalizar prefijos sin conservar sus bindings produce el error opuesto: nombres distintos pueden parecer iguales.

identityref lleva esta cuestión al valor del elemento. La misma identidad admite prefijos locales distintos. instance-identifier exige prefijos explícitos en todos los nombres de nodo, aunque esos prefijos también son locales al documento. Resolver la cadena requiere el schema adecuado; resolverla no demuestra que el nodo referido exista en el árbol o datastore pertinentes.

Ordenar puede corregir ruido o borrar intención

En containers ordinarios, los hijos pueden aparecer en cualquier orden; en entradas y salidas de RPC/action siguen el orden del schema. Las claves de una list se codifican antes que sus otros hijos. Las entradas ordered-by user conservan el orden del usuario, mientras que las system-ordered dependen de la implementación.

Un comparador que ordena todos los hermanos puede destruir el significado de una lista de prioridad o una regla first-match. Otro que trata cada cambio de posición como semántico llenará el sistema de falsos cambios. El recibo necesita el camino YANG del nodo, su regla ordered-by, el orden original y el readback del servidor.

Los defaults no están definidos por este borrador

La revisión 00 no especifica los modos NETCONF para datos por defecto. RFC 7950 determina cuándo un default está en uso y exige que el servidor se comporte como si el nodo estuviera presente; expresiones when o if-feature pueden impedirlo. RFC 6243 define report-all, trim, explicit y report-all-tagged.

La ausencia en XML no equivale, por tanto, a ausencia semántica. La presencia de un valor igual al default tampoco indica si fue escrito, almacenado o sintetizado. Antes del diff hay que declarar la vista comparada: bytes de transporte, configuración almacenada, árbol accesible con defaults en uso o respuesta expandida bajo un modo concreto.

C14N resuelve una clase de diferencias

Canonical XML 1.1 estabiliza detalles físicos como codificación de caracteres, orden de atributos y declaraciones de namespace. El W3C advierte que la equivalencia propia de una aplicación queda fuera de un algoritmo XML general. Dos formas canónicas distintas pueden significar lo mismo para una aplicación; una forma idéntica no incorpora automáticamente las reglas de YANG.

Esas reglas incluyen schema revision, features, deviations, formas léxicas y canónicas de tipos, defaults, orden, restricciones y referencias. C14N no selecciona módulos, no compila el schema ni comprueba el destino de un leafref.

YANG Library de RFC 8525 anuncia el conjunto de modelos del servidor, pero la declaración aún debe vincularse con lo cargado por el proceso. RFC 8528 añade una dificultad: instancias diferentes del mismo mount point pueden tener schemas montados diferentes. Copiar el mismo fragmento XML sin su mount instance puede cambiar o perder su significado.

Los metadatos también viajan como atributos XML según RFC 7952. Un intermediario que elimina atributos desconocidos puede dejar datos ordinarios válidos y, al mismo tiempo, perder la anotación que explicaba origen o condición. Para anydata con modelo desconocido y para anyxml, tampoco existe una garantía general de conversión a otros formatos.

La respuesta del protocolo no es el efecto final

Un archivo válido no acredita que el servidor recibió una RPC. RFC 6241 separa <rpc-reply>, <rpc-error> y <ok>. Este último indica procesamiento sin error o warning y sin datos que devolver; no prueba por sí solo la realización física posterior.

El expediente de cambio debe enlazar request y message-id, sesión autenticada, capacidades, schema anunciado, respuesta y lecturas del datastore antes y después. RFC 8342 distingue running, intended y operational precisamente porque configuración, intención transformada y estado aplicado pueden separarse. Sólo una medición externa cierra el resultado empresarial o de servicio.

La especificación da significado interoperable. La ejecución aporta consecuencias observadas. Confundir ambas cosas no hace más rigurosa la automatización; sólo adelanta su veredicto.

Fuentes