Resumen

  • draft-ietf-ivy-entitlement-inventory-05 modela por separado el catálogo, la vinculación a activos, la instalación declarada, las dependencias, allowed, in-use y las restricciones.
  • Todos los nodos del módulo son de solo lectura. Los canales que cambian y hacen cumplir el estado, las alertas de vencimiento y la reconciliación siguen perteneciendo a otros sistemas.
  • Un valor vigente solo es accionable cuando conserva productor, alcance, instante, regla de combinación y el recibo de lo que ocurrió en el equipo y en el servicio.

Veinte unidades libres que dos sistemas gastaron a la vez

Imagine un pool de cien licencias de capacidad. El inventario informa ochenta en uso. Dos orquestadores, en regiones diferentes, consultan el mismo valor y solicitan veinte unidades cada uno. Las dos decisiones parecen caber. El dato era correcto en el instante de la lectura, pero ninguna lectura reservó el saldo.

Uno de los equipos puede quedar activado y el otro rechazado. También pueden quedar ambos activos durante una ventana de reconciliación, aunque el contrato permita solo cien. El error no está necesariamente en el número 80. Está en atribuir a un contador el poder de serializar decisiones concurrentes.

Ese ejemplo resume la frontera que hace útil el borrador A YANG Module for Entitlement Inventory. La revisión 05 lleva fecha de 29 de septiembre de 2026, pretende avanzar por Standards Track y vence el 2 de abril de 2027. Continúa siendo un Internet-Draft del grupo Network Inventory YANG de la IETF. No es un RFC, una prueba de implantación ni un dictamen sobre la validez jurídica de una licencia.

El proyecto ofrece vocabulario común para ver derechos, activos, capacidades y límites. No promete que una vista común sea un árbitro transaccional.

El recorrido de un derecho

El catálogo superior registra un entitlement de la organización: identificador, producto, proveedor, estado, fechas y restricciones. Ese derecho puede asociarse a un titular, elemento de red o componente. El activo puede publicar una referencia bajo installed-entitlements. En otra rama aparecen sus capacidades. Una capacidad puede señalar los entitlements que la respaldan, declarar si está allowed, indicar si está in-use y exponer límites globales o locales.

Después empieza la realidad que el inventario no puede sustituir: aceptación de la configuración, estado operativo, entradas de reenvío, tráfico y experiencia del servicio.

Cada paso responde una pregunta. Poseer no es asignar. Asignar no es instalar. Instalar no es satisfacer todas las dependencias. Estar permitido no es tener autorización de usuario. Estar en uso no es entregar el resultado. Un máximo y un valor actual no forman por sí solos una reserva.

La disciplina consiste en mantener los verbos separados incluso cuando comparten un identificador.

“Instalado” puede ser una asignación lógica

La propia revisión 05 conserva una tensión terminológica. Su sección de alcance dice que los entitlements instalados han sido asignados a un activo y que la instalación puede representar tanto aprovisionamiento directo como asignación lógica en un sistema central. La sección de definiciones habla de activación local y disponibilidad. Más adelante, las referencias instaladas se describen como activas y otorgando derechos al activo.

No conviene convertir esa diferencia de redacción en una acusación: es trabajo en curso. Sí conviene impedir que una implementación esconda el punto de observación.

Un gestor de activos sabe que una licencia está destinada a un número de serie. Un servidor sabe que emitió un arrendamiento. Un dispositivo sabe que aceptó una credencial local. Un recolector sabe lo que recibió en la última consulta. Los cuatro pueden usar el mismo ID y conservar estados distintos.

Por eso una afirmación operativa debe llevar productor, semántica, hora, edad del caché y camino de validación. installed sin procedencia es una palabra demasiado grande.

Lo ausente no equivale a cero

Los contenedores de presencia permiten expresar conocimiento. Si installed-entitlements está presente con una lista vacía, el sistema declara que conoce la clase y no ve ninguna licencia instalada. Si el contenedor falta, puede no saber informar. Lo mismo ocurre con in-use: una hoja ausente puede significar incapacidad de expresión, no falsedad.

En supporting-entitlements, una lista explícitamente vacía puede decir que la capacidad no requiere un derecho especial. La ausencia del contenedor puede decir que el productor no conoce la dependencia. Convertir ambos casos en [] borra una diferencia decisiva.

La normalización correcta conserva verdadero, falso, vacío declarado y desconocido. Debería conservar además la versión del modelo y el productor. De otro modo, una plataforma de automatización puede tratar la ignorancia como libertad para actuar.

Cinco niveles de cobertura

El borrador permite implementar el modelo por niveles. El primero es el catálogo. El segundo añade entitlements instalados por activo. El tercero informa capacidades. El cuarto enlaza capacidad y derecho, junto con allowed e in-use. El quinto incorpora restricciones y consumo.

Los proveedores deberían documentar niveles y desviaciones. Una ficha que solo diga “compatibilidad con entitlement inventory” no permite comparar productos. Un nivel 1 ayuda a compras, pero no observa el dispositivo. Un nivel 3 muestra funciones posibles sin explicar el permiso. Un nivel 4 puede calcular permiso sin exponer el pool global que limita la operación.

La especificación de adquisición debe pedir ejemplos exportables de cada nivel, el comportamiento ante datos ausentes y la frecuencia real de actualización.

allowed depende de un cierre de dependencias

Una capacidad puede necesitar varios derechos. El borrador indica que allowed debe reflejar el efecto combinado y debería ser falso si falta un requisito o si está vencido o revocado.

El Booleano, por tanto, contiene una decisión. Para auditarla hacen falta la lista completa de requisitos, el estado de cada uno, la regla de composición y el instante. Un catálogo incompleto puede autorizar de más. Un controlador sin conocimiento de una gracia puede denegar de más. La salida no es más fuerte que el cierre de dependencias.

Tampoco decide quién puede configurar. El RFC 8341 define NACM para restringir operaciones y datos de usuarios NETCONF o RESTCONF. El entitlement expresa el derecho de la organización a usar una capacidad. Una cuenta privilegiada no sustituye la licencia; una licencia no autoriza a cualquier cuenta.

Incluso con ambas decisiones favorables, el equipo puede carecer de versión, memoria, tarjeta o topología adecuada. El permiso precede a la ejecución; no la certifica.

in-use necesita una definición operacional

El modelo ofrece in-use en el entitlement instalado y en la capacidad. Cuando ambos se informan, deberían ser coherentes. Esa comprobación detecta inconsistencias simples, pero no define el sensor.

Para un servidor de licencias, uso puede ser una plaza prestada. Para un equipo, puede ser una configuración cargada. Para un controlador, el último estado recibido. Para operaciones, una sesión levantada o tráfico contado. Cada método tiene una autoridad distinta.

Un recibo de uso debe decir qué evento cambió el estado, cuánto dura, cómo se invalida y qué observación independiente lo confirma. Si la función es BGP, por ejemplo, configuración, proceso, sesión, ruta, FIB y paquetes son escalones separados.

Un esquema válido puede contener un grafo imposible

Los entitlements pueden formar jerarquías mediante un padre. YANG impide ciertas referencias inválidas, pero no detecta todos los ciclos profundos. La aplicación de gestión debe rechazar A→B→A. La validez sintáctica no demuestra que el grafo de derechos tenga solución.

Después queda la concurrencia. current-value necesita unidad, ámbito, ventana temporal y regla de reinicio. En un pool compartido necesita además una reserva atómica o un único árbitro. Si no, el dato sirve para observar, no para comprometer capacidad futura.

Solo lectura, escritura exterior

El módulo completo es config false. Informa estado; no lo cambia. Los servidores de licencias y las plataformas de activos escriben la realidad por canales externos al documento.

NETCONF o RESTCONF pueden proteger la consulta mediante autenticación mutua y transporte seguro. Eso no impide leer un estado antiguo. La sección de seguridad advierte que un atacante que manipule canales externos puede introducir un estado falso y hacer que una capacidad parezca permitida o restringida contra la realidad organizativa.

La reconciliación entre catálogo central, instalación local y uso real es por ello una función separada. El borrador recomienda detectar discrepancias, pero no define una precedencia universal. También expone fechas de expiración sin definir alertas. El dueño del aviso, la escalada, la renovación y la prueba posterior debe existir fuera del modelo.

Los nueve recibos mínimos

Una cadena operativa conserva el otorgamiento, la asignación, la activación local, el cierre de dependencias, la decisión allowed, la autorización NACM, la observación de uso, la reserva y aplicación del límite, y el resultado de red. Cada recibo necesita actor, tiempo y objeto.

No es necesario concentrarlos. De hecho, separar custodios puede mejorar la auditoría. Lo indispensable es que una API o panel no reemplace nueve preguntas por una etiqueta verde imposible de impugnar.

Fuentes