Resumo

  • draft-ietf-ivy-entitlement-inventory-05 propõe um modelo YANG somente de leitura para direitos, capacidades e restrições. É um Internet-Draft ativo, não um RFC nem comprovação de implantação.
  • Um installed entitlement pode representar ativação local no equipamento ou mera atribuição lógica em um sistema central. O sistema que informa o dado faz parte do significado.
  • allowed, in-use e o resultado efetivo do serviço são afirmações diferentes. O inventário pode relacioná-las, mas não pode transformar uma em prova automática da outra.

Considere uma licença associada ao roteador r9. Para a plataforma de ativos, ela está instalada porque o contrato foi vinculado ao equipamento. Para o roteador, nada foi recebido: o uso depende de um servidor externo ou de uma regra comercial. Se as duas plataformas exportarem installed, o problema não está necessariamente em uma delas estar errada. Está em um consumidor apagar a diferença entre atribuição e ativação.

A revisão 05 comporta os dois sentidos. Na definição de escopo, um direito instalado é aquele atribuído a um ativo, e a instalação pode ocorrer por provisionamento direto ou por atribuição lógica centralizada. No glossário, Installed Entitlement aparece como direito ativado localmente e disponível às capacidades do elemento. A linguagem comum permite integração, mas não oferece um recibo operacional único.

Os modelos de implantação deixam isso claro. O direito pode residir no próprio equipamento, que aplica as restrições. Pode ficar num servidor de licenças consultado pelo ativo. Ou pode existir apenas como acordo comercial, com controle externo e sem conhecimento direto pelo elemento de rede. Equipamento, servidor e sistema de monitoramento podem apresentar partes válidas da árvore. A consolidação precisa preservar qual parte veio de qual testemunha.

O desenho também aceita cobertura parcial. No nível 1, existe o catálogo corporativo. No nível 2, aparecem as atribuições a ativos. No nível 3, as capacidades. No nível 4, a relação entre capacidades e direitos de suporte, incluindo allowed e in-use. O nível 5 acrescenta restrições globais e específicas, como quantidade de instalações, taxa máxima ou conexões.

Esses níveis limitam a conclusão possível. O catálogo prova que a organização administra um direito, não que um equipamento o recebeu. A atribuição identifica a intenção sobre um ativo, não a capacidade executável. A lista de capacidades não informa necessariamente o direito habilitador. Quem consome o modelo deve saber quais níveis e desvios estão presentes. Caso contrário, uma visualização completa pode esconder uma fonte incompleta.

Os presence containers são a forma escolhida para declarar capacidade de reporte. Quando um contêiner não aparece, a implementação não consegue informar aquele conteúdo. Isso não demonstra que o direito ou a capacidade inexiste no mundo real. Sistemas de decisão precisam manter desconhecido separado de falso. Trocar um pelo outro pode tanto bloquear uma função legítima quanto liberar uma função sem base suficiente.

No nível 4, allowed deve combinar todos os direitos necessários. A falta, expiração ou revogação de um deles deve levar a falso. in-use informa se a capacidade está operacional. Mesmo assim, ambos são observações em um modelo de leitura. Não são o comando que ativou a função, a transação de configuração, uma medição independente ponta a ponta ou prova de que o serviço entregue funcionou.

O próprio texto recomenda detectar divergências entre registros centralizados, direitos instalados localmente e uso real. A reconciliação existe porque as camadas não são equivalentes. Uma operação madura registra a divergência, procura a causa e conserva as versões; não escolhe silenciosamente o último valor escrito como verdade universal.

Há ainda uma questão de granularidade. O fornecedor pode expor uma capacidade ampla como Advanced Services ou separar MPLS, BGP e QoS. Portanto, allowed: true só é interpretável junto da definição e da versão do catálogo do fornecedor. Um esquema comum padroniza a ligação, não o conteúdo comercial de todos os pacotes.

Descoberta automática não faz parte da revisão atual. As associações podem ser carregadas em um servidor, relatadas pela interface do dispositivo ou inseridas manualmente. Alertas de vencimento também ficam fora: o modelo fornece datas para que uma aplicação externa monitore e notifique. Ter a data não comprova que o alerta chegou ao responsável.

Segurança de acesso é necessária, mas trata de outro recibo. NETCONF, RESTCONF, autenticação mútua e NACM protegem dados capazes de revelar SKUs, contratos, perfis operacionais e superfície de ataque. Esses controles não certificam a correção da origem. O rascunho alerta que a injeção de estado falso nos canais externos pode fazer uma capacidade parecer permitida ou restrita contra os direitos reais da organização.

Também não se deve antecipar o status do documento. A revisão 05, datada de 29 de setembro de 2026, pretende seguir a Standards Track, porém permanece um Internet-Draft. Validar o módulo ou registrá-lo futuramente não comprova aprovação final, adoção, implementação completa, atualidade dos dados ou situação de uma rede específica.

O benefício do modelo é tornar as camadas comparáveis: direito comercial, catálogo, atribuição, ativação local, permissão, uso reportado, restrição e resultado do serviço. O risco começa quando a interface converte toda essa cadeia em um único indicador verde chamado “licenciado”.

Fontes