Resumo

  • draft-ietf-ivy-entitlement-inventory-05 separa catálogo organizacional, vínculo com o ativo, referência instalada, licenças de suporte, allowed, in-use e restrições.
  • O módulo YANG proposto é todo somente leitura. Os sistemas que alteram e aplicam o direito, a sincronização e os alertas de expiração ficam fora dele.
  • Uma decisão segura precisa guardar produtor, instante, escopo e regra de cada campo, além dos recibos de aceitação local, autoridade do usuário e efeito do serviço.

O teto de 100 que não dizia 100 de quê

Considere uma licença que admite até 100 unidades de throughput. O painel mostra max-value=100 e current-value=72. Parece haver margem para ativar mais uma interface de 20. Mas o contador pode medir capacidade configurada, enquanto o servidor cobra pico de uso; pode agregar a organização inteira, enquanto o controlador vê um único chassi; pode estar dez minutos atrasado; ou pode ignorar uma reserva concorrente.

O número é real dentro de sua origem. A autorização de consumir mais 20 é outra transação. E a prova de que o tráfego ficou abaixo do limite depois da ativação é uma terceira.

Essa distinção atravessa a revisão 05 de A YANG Module for Entitlement Inventory. O documento é datado de 29 de setembro de 2026, tem status pretendido Standards Track e expira em 2 de abril de 2027. Continua sendo um Internet-Draft do grupo Network Inventory YANG da IETF, não um RFC, uma implantação ou uma garantia de comportamento de produto.

A cadeia que o modelo torna visível

No nível organizacional, o catálogo registra uma entitlement: identificador, produto, fornecedor, estado, datas e restrições. A licença pode ser vinculada a detentor, elemento de rede ou componente. O ativo pode expor uma referência em installed-entitlements. Suas capacidades aparecem em outro ramo, com referências aos entitlements que as sustentam. O estado de entitlement da capacidade pode dizer allowed e in-use. Restrições globais e locais podem trazer máximo e valor atual.

Depois disso ainda vêm a aceitação da configuração, o estado operacional, o dataplane e o serviço observado.

São afirmações diferentes: a organização possui; alguém atribuiu; o ativo recebeu; as dependências estão completas; a política permite; um principal pode configurar; a função está em uso; o limite está sendo respeitado; o serviço funciona. Um identificador comum conecta os recibos, mas não os funde.

Instalada no cadastro ou ativada no ativo

O texto em elaboração usa “installed entitlement” sob mais de uma perspectiva. A seção de escopo permite que instalação represente uma atribuição lógica central, além do provisionamento direto. A seção de definições fala em ativação local e disponibilidade. A descrição posterior trata a referência como ativa e concedendo direito ao ativo.

Uma revisão futura pode fechar essa distância. A operação atual deve registrar a procedência.

O inventário de ativos sabe para qual serial a licença foi destinada. O servidor sabe se emprestou uma credencial. O dispositivo sabe se a aceitou. O controlador sabe o resultado da última leitura. Os quatro podem citar o mesmo entitlement-id e discordar legitimamente sobre o momento presente.

Por isso, installed precisa vir acompanhado de produtor, semântica, horário, idade de cache e caminho de validação. Sem esses campos, uma atribuição administrativa pode ser confundida com enforcement local.

Ausência não é negação

Presence containers também carregam evidência. Um installed-entitlements presente e vazio pode significar que o sistema sabe informar e não encontrou licença. Um container ausente pode significar que o produtor não oferece essa visão. Uma folha in-use ausente pode ser desconhecida, não false.

Em supporting entitlements, uma lista explicitamente vazia pode indicar que a capacidade não exige licença especial. A ausência do container pode indicar que a relação não é reportada. Converter os dois em array vazio é atribuir permissão onde talvez exista ignorância.

Uma plataforma deve preservar true, false, vazio explícito e não informado, junto com versão, fonte e timestamp.

Cinco níveis que não cabem em um selo

O nível 1 entrega o catálogo central. O nível 2 inclui entitlements instalados nos ativos. O nível 3 informa capacidades. O nível 4 liga capacidades às licenças e expõe allowed e in-use. O nível 5 acrescenta restrições e consumo.

Implementações devem documentar nível e desvios. Um sistema de nível 1 pode apoiar compras sem saber nada do estado local. O nível 3 conhece a função técnica, não o direito. O nível 4 calcula permissão, mas pode não resolver a concorrência do pool global.

Em vez de comprar uma caixa chamada “entitlement inventory”, o operador deve exigir exemplos dos cinco níveis, significado da ausência, ritmo de atualização e comportamento sob partição.

allowed carrega uma política

Uma capacidade pode depender de várias licenças. allowed deve refletir o efeito combinado; se uma dependência obrigatória falta, expirou ou foi revogada, o draft recomenda false.

Logo, o Booleano é uma conclusão calculada. Precisa de fechamento completo das dependências, estado fresco, regra de combinação e identidade do avaliador. Um add-on omitido gera permissão excessiva. Uma grace period desconhecida gera bloqueio excessivo.

Mesmo correto, allowed=true não dá poder ao usuário. NACM, no RFC 8341, controla quais principals NETCONF ou RESTCONF podem acessar operações e dados. Entitlement expressa o direito da organização de usar a função. Um não substitui o outro.

Também não prova readiness: release, hardware, memória, configuração, topologia e política do serviço ainda podem impedir a ativação.

Uso reportado e uso observado

in-use pode aparecer na licença instalada e na capacidade, com consistência esperada entre ambos. Mas a fonte pode chamar de uso uma seat emprestada, uma configuração presente, um processo em execução ou contador de tráfego.

O operador precisa saber o sensor. Para uma função de roteamento, configuração, processo, vizinhança, rota selecionada, FIB e pacote entregue formam uma sequência. A licença pode estar em uso segundo o servidor enquanto nenhum pacote depende dela.

Um recibo de uso registra método, momento, validade e observação independente.

Pool compartilhado, corrida compartilhada

Restrições podem controlar instalações, capacidade, conexões ou túneis. O par máximo/atual não é um lock. Dois controladores podem ler a mesma folga. Um contador pode ter janela distinta da cobrança. Um entitlement filho pode herdar um pool do pai.

Hierarquias precisam de validação. YANG impede autorreferência direta, mas não todos os ciclos profundos. A aplicação deve rejeitar A→B→A. Um documento válido no schema ainda pode descrever um grafo inválido.

Para decidir, registre recurso, unidade, escopo, janela, fonte, timestamp, reset e reserva. Sem arbitragem atômica, current-value é observabilidade, não compromisso.

O modelo lê; outro sistema escreve

Todos os nós são config false. O módulo publica estado, mas servidores de licença e plataformas de ativos alteram a realidade por canais externos ao draft.

NETCONF ou RESTCONF com autenticação mútua pode transportar com segurança um valor velho. A seção de segurança alerta que a manipulação dos canais externos pode injetar estado falso e fazer uma capacidade parecer permitida ou restringida contra o direito real.

O texto recomenda detectar diferenças entre catálogo central, licenças locais e uso efetivo. Não escolhe árbitro universal. Datas de expiração são expostas, mas alertas e renovação pertencem à aplicação. Se há cache, sua identidade e o último refresh bem-sucedido são parte do status.

Nove recibos para um direito executável

Uma cadeia auditável guarda grant, assignment, activation, dependency closure, permission, NACM access, usage, restriction enforcement e service outcome. Cada recibo nomeia ator, objeto, tempo e ligação com o anterior.

Eles não precisam morar no mesmo banco. Precisam sobreviver à automação. O inventário comum é forte quando coordena o que sabe e não reivindica o poder do equipamento que executa.

Fontes