Resumen

  • draft-ietf-ivy-entitlement-inventory-05 propone un modelo YANG de solo lectura para derechos, capacidades y restricciones. Sigue siendo un Internet-Draft, no un RFC ni evidencia de implantación.
  • El término installed entitlement abarca tanto la activación local como la asignación lógica en un sistema central. El origen de cada dato forma parte de su significado.
  • allowed, in-use y la prestación efectiva de un servicio son afirmaciones diferentes; ninguna debe ascender automáticamente a prueba de la siguiente.

Un panel muestra que una licencia está instalada en un router. La frase parece cerrar la cuestión. Sin embargo, puede proceder de dos hechos muy distintos. El router pudo recibir y validar la licencia. O una base corporativa pudo asociar el contrato al activo sin que el router almacenara nada. En ambos casos, la fila del inventario puede ser correcta dentro de su propio sistema. Lo que no sería correcto es atribuirle el mismo efecto operativo.

La revisión 05 admite expresamente esa amplitud. Su sección de alcance define los derechos instalados como derechos asignados a un activo y señala que la instalación puede ser un aprovisionamiento directo o una asignación lógica centralizada. En la terminología aparece una formulación más local: un derecho activado en el elemento y disponible para sus capacidades. El nombre común facilita la interoperabilidad, pero también obliga a conservar la ruta probatoria que lo produjo.

Hay tres arquitecturas previstas. La primera instala el derecho en el propio activo y aplica allí las restricciones. La segunda utiliza un servidor de licencias externo. La tercera se apoya en un acuerdo comercial cuyo control ocurre fuera del elemento; el equipo puede funcionar sin conocer el derecho. Un dispositivo y un servidor central pueden exponer partes del mismo modelo. Un recolector puede unirlas. Esa unión es una comparación de testigos, no la creación de un testigo absoluto.

La estructura por niveles evita pedir a todos los sistemas la misma profundidad. El nivel 1 contiene el catálogo de derechos de la organización. El nivel 2 añade la asignación a activos. El nivel 3 informa de capacidades. El nivel 4 enlaza cada capacidad con los derechos que la sostienen e incorpora allowed e in-use. El nivel 5 expresa restricciones globales y límites específicos de capacidad.

Cada nivel responde a una pregunta distinta. Saber qué compró o administra una organización no indica qué llegó a un equipo. Saber qué se asignó a un equipo no prueba qué puede ejecutar. Saber qué funciones declara tampoco identifica la autorización que las sustenta. Un consumidor debe conocer el nivel disponible y sus desviaciones. Si rellena los niveles ausentes con supuestos, el inventario deja de observar y empieza a inventar.

Los presence containers tienen una semántica crítica. Si faltan, el sistema no puede informar de esa sección. La ausencia no equivale necesariamente a que no exista una capacidad, un derecho o una restricción. Convertir lo desconocido en falso puede inutilizar recursos válidos; convertirlo en verdadero puede iniciar tareas sin respaldo. Una interfaz responsable muestra desconocido y explica qué fuente no puede hablar.

En el nivel 4, allowed debe considerar todos los derechos requeridos por una capacidad. Si falta uno, ha vencido o ha sido revocado, el resultado debería ser falso. in-use indica que la función está operativa. Pero ambos son estados reportados en un modelo de solo lectura. No constituyen la orden de activación, una transacción de configuración, una traza independiente ni la prueba de que el servicio entregado al usuario funcionó.

La sección operativa pide detectar incoherencias entre el registro central, los derechos instalados localmente y el uso real de las capacidades. Esa frase define la función correcta del inventario: acercar capas que pueden divergir para que alguien resuelva la divergencia. Si un panel elimina una de las versiones para mostrar una sola verdad cómoda, destruye precisamente el dato que debía vigilar.

También varía el objeto al que se aplica el permiso. El proveedor decide la granularidad de una capacidad. Puede publicar Advanced Services como un bloque o enumerar MPLS, BGP y QoS. Por ello, un allowed: true necesita la definición del catálogo del proveedor y su versión. Dos valores idénticos pueden autorizar conjuntos distintos de funciones.

La revisión actual no descubre automáticamente derechos ni capacidades. Los vínculos pueden llegar de un servidor, de una interfaz de gestión o de una carga manual. Tampoco define el envío de avisos de caducidad. Entrega las fechas para que otra aplicación las supervise. Una fecha próxima no demuestra que alguien recibiera el aviso, del mismo modo que una asignación no demuestra la activación local.

La seguridad del canal resuelve otro problema. NETCONF y RESTCONF, con transporte protegido, autenticación mutua y NACM, ayudan a limitar la lectura de datos que revelan contratos, productos, perfiles operativos y superficie de ataque. No certifican la veracidad de la plataforma que originó el estado. El propio borrador advierte que la inyección de datos falsos en canales externos podría hacer que una capacidad pareciera autorizada o restringida sin reflejar los derechos reales.

También hay que respetar la situación documental. La revisión 05 lleva fecha de 29 de septiembre de 2026 y aspira a Standards Track, pero continúa siendo trabajo en curso. Validar el YANG o registrar un módulo no demuestra aprobación final, implementación comercial, cobertura completa ni el estado actual de una red concreta.

El modelo es potente cuando mantiene separadas las capas: derecho comercial, catálogo, asignación, activación local, permiso de capacidad, uso observado y resultado del servicio. Su utilidad no consiste en sustituirlas por una casilla. Consiste en hacer visible dónde termina una declaración y dónde debe comenzar el siguiente recibo.

Fuentes