Resumen

  • draft-ietf-netmod-yang-anydata-validation-00 propuso usar la identidad codificada de un nodo para localizar en RFC 8525 YANG Library el esquema aplicable a los descendientes de anydata.
  • anydata-complete aplicaría todas las reglas del esquema; anydata-candidate no ejecutaría comprobaciones de restricciones. Ningún veredicto demuestra por sí solo identidad, autorización, estado operativo, reenvío o resultado económico.

El problema no empieza con un mensaje rechazado, sino con uno aceptado demasiado deprisa. Un contador cruza una pasarela, obtiene una marca verde y entra en el cálculo de tráfico. Cuando la cifra se cuestiona, ya no queda constancia de la revisión del módulo, de las features, de las deviations ni del build del validador que produjeron aquella aprobación.

La revisión 00 de Validating anydata in YANG Library context intentó cerrar una parte de ese vacío. YANG 1.1 define anydata para contenido modelable con YANG cuyo modelo concreto no se conocía al diseñar el módulo contenedor. La pieza abierta sirve en filtros, resultados de datastore, operaciones de edición, ficheros de instancia y notificaciones. Pero el receptor necesita saber qué esquema puede examinarla.

El borrador parte de la identidad que conserva cada codificación. XML une nombre local y namespace del módulo. JSON usa el identificador del nodo, cualificado por módulo cuando corresponde. CBOR puede recurrir a SID, delta de SID, nombre cualificado o instance-identifier. Con esa identidad, el validador buscaría el nodo correspondiente en YANG Library.

La búsqueda solo tiene sentido dentro de un contexto congelado. RFC 8525 asocia un datastore a un schema; el schema es la unión de module-sets; y los módulos se describen con revision, submodules, features y deviations. El content-id cambia cuando cambia la información de la Library, pero es específico de la implementación y no un hash universal. Un schema mount puede introducir, además, otro contexto bajo el mismo árbol aparente.

La palabra candidate conserva una deuda

anydata-complete debía comprobar el subtree y exigir todas las reglas de validación del esquema correspondiente. anydata-candidate omitía los constraint checks. La terminología se alinea con RFC 7950: running y startup aplican restricciones al final de la operación; candidate puede aplazarlas hasta commit o validate.

Por eso un pass candidate no es una versión barata del pass complete. Dice que una ruta candidata aceptó la estructura sin terminar los controles. El pass complete dice que una implementación concreta no encontró infracciones entre todas las reglas que ejecutó bajo un contexto concreto. Cada frase contiene sus límites; eliminar cualquiera de ellos produce una garantía inexistente.

El fail tampoco atribuye culpa. Puede localizar un tipo erróneo, una restricción de rango, un must, un when, una cardinalidad, un nodo desconocido o un desacuerdo de contexto. La causa puede estar en el emisor, en una transformación intermedia, en la Library elegida o en el propio validador. El resultado permite aislar e investigar, no identificar por sí solo al responsable.

El borrador usa el ejemplo de un contador negativo de octetos enviado por un nodo defectuoso mediante YANG-Push. Un sistema analítico podría sumar mal el tráfico y contaminar facturación o planificación de capacidad. La validación completa puede interceptar esa clase de error. No demuestra que un valor positivo sea reciente, íntegro, completo ni proceda de la interfaz que el proceso de negocio cree observar.

Guardar el contexto convierte el test en evidencia

Un recibo reproducible conserva hash y hora del payload, encoding e identidad decodificada. Adjunta el content-id y la instantánea completa de YANG Library; señala datastore, schema, module-sets, revisions, submodules, features, deviations y mount path. También registra nombre y build del validador, flags, modo, diagnóstico y disposición.

Así puede explicarse una discrepancia futura. Una feature puede retirar un nodo; una deviation cambia una regla; un mount desplaza la resolución; una actualización del parser altera casos límite. Si los mismos bytes cambian de veredicto, la primera pregunta pasa a ser qué contexto cambió.

El proyecto dejaba la respuesta al consumidor: ignorar, registrar o alertar ante un mensaje no conforme. Esa decisión no pertenece al motor de validación. El dueño del dato debe fijar qué fallos detienen automatización, cuáles admiten reintento y cuáles exigen revisión humana antes de conectar el veredicto con facturación o control.

El expediente está cerrado, no a punto de convertirse en estándar

Datatracker identifica el 2 de diciembre de 2025 como fecha de la última revision y registra la disponibilidad de la versión WG 00 ese día. El texto venció el 3 de junio de 2026. Hoy aparece como Expired Internet-Draft, Expired & archived, Dead WG Document e IESG Expired; el campo Intended RFC status figura como None.

La cabecera del borrador decía por separado Intended status: Standards Track. Era una intención editorial del documento, no aprobación de IETF. El análisis de seguridad quedó sin terminar, no hubo petición a IANA y Datatracker no muestra shepherd.

La sección Implementation Status enlazaba una rama de libyang para anydata-candidate y pedía retirarla antes de una eventual publicación. Una rama muestra como máximo que existió una ruta experimental. No prueba merge, implementaciones independientes, interoperabilidad ni despliegue.

La conformidad no habla por la realidad operativa

RFC 8342 separa running, intended y operational: que un valor satisfaga un schema no demuestra que el dispositivo lo aplique. RFC 8341 resuelve control de acceso: la estructura correcta no concede NACM. Las RFC de subscriptions y YANG-Push tratan selección y entrega: un subtree válido no descarta pérdidas, repeticiones, desorden o reescritura.

La identidad del emisor, la integridad de transporte y la cadena de custodia requieren registros propios. Contadores del equipo, FIB, captura de paquetes, observación remota y conciliación económica responden a otras preguntas. El validador no adquiere autoridad sobre ellas por producir JSON o un icono verde.

La aportación duradera de la revisión 00 es una disciplina: hacer comprobable un contenido antes opaco dentro de un contexto nombrado y distinguir dos profundidades de prueba. Con recibo, un resultado reduce la investigación. Sin él, la aprobación solo desplaza la incertidumbre hacia el futuro.

Fuentes

Expediente: revisión 00, estado actual e historial.

Contexto técnico: RFC 7950, RFC 8525, RFC 8342, RFC 8341, RFC 8528, RFC 8639 y RFC 8641.

Marco analítico: Minimum Initial Specification, On Reality Layers y Running Code Primary.