Resumen

  • draft-ietf-netmod-node-tags-11 planteaba reunir etiquetas definidas en el módulo, añadidas por una implementación y configuradas por el usuario, y después eliminar del resultado operativo los valores que coincidieran con masked-tag.
  • Una etiqueta superviviente sólo demuestra que un servidor la mostró para un selector, datastore y contexto de autorización concretos. No demuestra que el nodo exista ahora, que el dato sea reciente, que la implementación responda a la etiqueta ni que el borrador se haya desplegado.

El problema empieza con una ausencia. Un sistema de inventario pide todos los nodos clasificados para una función concreta y recibe cinco rutas. Esperaba seis. La ruta que falta podría no haber sido etiquetada, podría estar enmascarada, fuera del alcance de NACM, ausente de la revisión de esquema activa o consultada en el datastore equivocado. La lista no conserva por sí sola la causa.

La propuesta YANG Data Model for Node Tags organizaba esas clasificaciones en el módulo ietf-node-tags. Cada asociación llevaba un id numérico, un node-selector del tipo nacm:node-instance-identifier, un conjunto tag y otro masked-tag. El selector podía referirse a un nodo de esquema o a una instancia. El texto proponía descubrirlos con <get-data> en el datastore operacional y mencionaba <get-schema> para nodos de esquema. En el apéndice, una ruta encontrada alimentaba después una solicitud establish-subscription.

Es una ilustración técnica, no una constancia de uso. Las fuentes revisadas no aportan despliegues, productos, implementaciones independientes ni pruebas de interoperabilidad.

La suma tiene una costura visible

Las secciones de origen distinguen etiquetas incorporadas al diseñar el módulo, etiquetas que añade la implementación y etiquetas que configura el usuario. El usuario también puede enmascarar cualquier valor, sin importar de dónde llegó.

Sin embargo, el algoritmo enumerado para la vista operacional no repite ese reparto con cuatro pasos. Indica añadir las etiquetas con origen system asignadas en la definición del módulo, añadir las etiquetas del usuario con origen intended y eliminar cada valor igual a masked-tag. No separa las etiquetas de implementación.

Es razonable interpretar que las adiciones automáticas de una implementación forman parte del material del lado servidor o system. Esa reconciliación sigue siendo una interpretación. Una evidencia honesta debe registrar la ambigüedad y no presentar una procedencia más nítida que el propio documento.

Enmascarar tampoco borra la historia. Retira una coincidencia exacta de la vista final; no dice que el valor nunca existió ni que era falso. Que vendor:critical siga visible tampoco revela quién lo introdujo, cuándo, con qué versión del software o sobre qué observación.

Los prefijos ietf:, vendor: y user: ordenan el espacio de nombres. El borrador acepta además etiquetas con un prefijo no registrado y recomienda procesarlas. Registrar un prefijo demuestra coordinación nominal; no certifica lo que se afirma después de los dos puntos.

El selector depende de una realidad que no transporta

El tipo de node-selector reduce errores de forma, pero no contiene todo el esquema. RFC 7950 define YANG. RFC 8525 describe en YANG Library los módulos, revisiones, features y deviations que conforman el contexto efectivo. Con otro conjunto o un montaje distinto, la misma ruta puede dejar de resolver o señalar otro objeto.

RFC 8342 separa intended de operational. El borrador utiliza esa diferencia al situar la configuración del usuario en intended y el conjunto compuesto en operational. Pero operational significa la vista que el servidor construye y expone, no una lectura directa de la realidad física.

La autorización introduce otra mediación. RFC 8341 permite que NACM oculte asociaciones o nodos. RFC 6241 y RFC 8040 aportan NETCONF y RESTCONF para recuperarlos, pero una transacción correcta prueba sólo qué respondió el servidor a esa identidad. La ausencia sigue teniendo varias explicaciones.

RFC 7952 ilustra un diseño vecino: sus anotaciones acompañan instancias de datos, mientras que node-tags centraliza asociaciones alrededor de selectores. Ningún formato genera automáticamente autor, hora, custodia o actualidad.

No saltar peldaños de evidencia

La existencia de la revisión 11 demuestra que hubo una propuesta. Datatracker demuestra su ciclo documental. El registro de un prefijo demuestra una asignación. Una respuesta con una etiqueta demuestra que el servidor expuso el resultado de la composición en una consulta y con unos permisos determinados.

Resolver el selector contra una captura de YANG Library demuestra que esa ruta corresponde a un nodo en ese esquema. Leer el nodo con autorización demuestra lo que el servidor entregó en esa operación. La frescura, la exhaustividad, la implementación correcta, la recepción completa de notificaciones, el FIB, los paquetes y el resultado del servicio necesitan observaciones adicionales.

RFC 8639 y RFC 8641 permiten crear suscripciones y YANG-Push. RFC 9195 y RFC 9196 modelan datos de instancia y capacidades. Ninguno eleva una clasificación a prueba de entrega o ejecución. El tratamiento de identificadores de proveedor de RFC 9371 mejora el orden del namespace, no avala el producto.

El propio borrador alerta de que una etiqueta puede revelar el uso de un nodo y facilitar un vector de ataque. Añadirla o retirarla exige privilegios, y las acciones que se tomen por su presencia quedan fuera del alcance del documento. Si una organización conecta una etiqueta con un cambio, permiso o bloqueo, la autoridad es suya y debe definirla por separado.

El borrador no heredó la condición de RFC 8819

La revisión 11 está fechada el 21 de octubre de 2023 y anunciaba su caducidad el 23 de abril de 2024. Datatracker la registra como Expired Internet-Draft, Expired & archived, Dead WG Document y con estado IESG Expired. Aspiraba a Proposed Standard, pero nunca se convirtió en RFC.

Su validación YANG figura con cero errores y cero avisos. Eso demuestra que los módulos enviados pasaron esas comprobaciones. No demuestra adopción, interoperabilidad, despliegue ni una composición operacional correcta.

RFC 8819 sí es una norma Standards Track para etiquetas de módulos YANG. Su modelo de orígenes y máscaras sirvió de precedente, pero actúa a nivel de módulo. Node-tags intentó extender la idea a nodos. El estatus publicado del primero no puede transferirse al borrador vencido.

Los ensayos de Heng Lu sobre especificación mínima, autoridad, poder de implementación, capas de realidad y running code se usan aquí como lente editorial, no como norma técnica. Ayudan a separar el símbolo que coordina de la operación observable que produce efectos. La disciplina resultante es modesta: usar la etiqueta para descubrir, sin permitir que tome prestada la autoridad del documento, el registro o el servidor.

Fuentes

Registro principal: revisión 11, estado actual en Datatracker e historial.

Modelo y acceso: RFC 6241, RFC 7950, RFC 7952, RFC 8040, RFC 8341, RFC 8342, RFC 8407, RFC 8525 y RFC 8526.

Etiquetas, suscripciones y modelos próximos: RFC 8639, RFC 8641, RFC 8819, RFC 9195, RFC 9196 y RFC 9371.

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