Resumo

  • A RFC 3060 padronizou um modelo reutilizável de informação sobre políticas — grupos, regras, condições, ações e associações — mas deixou explicitamente para as implementações o algoritmo que converte esses atributos em um resultado.
  • O modelo podia representar prioridades e dizer se a ordem das ações era obrigatória ou recomendada; isso não o tornava um mecanismo universal de execução. A RFC 3460 alterou o modelo e acrescentou estratégias de decisão, sem provar que equipamentos diferentes aplicavam as mesmas políticas da mesma maneira.

A regra viaja; seu significado pode não viajar

Um arquivo de políticas pode parecer portátil e ainda produzir resultados distintos na borda da rede. Dois equipamentos talvez recebam uma condição e uma ação com os mesmos nomes, mas usem capacidades locais, extensões ou rotinas de avaliação diferentes. Essa separação está no centro da RFC 3060, a primeira versão do Policy Core Information Model (PCIM), publicada em fevereiro de 2001.

O PCIM descreveu uma estrutura de informação. Classes representavam elementos de política; classes de associação registravam como eles se relacionavam. Uma PolicyRule vinculava condições a ações. PolicyGroups organizavam regras ou outros grupos, e regras podiam receber prioridades. As condições podiam ser expressas como OR de ANDs ou AND de ORs, inclusive com proposições negadas. Isso oferecia aos projetistas uma forma comum de descrever a que uma regra se referia e quando deveria valer.

Mas o esquema não era necessariamente o lugar onde a rede tomava a decisão. A RFC distinguiu o modelo de informação do algoritmo que o interpreta. Seu próprio exemplo ajuda a visualizar o problema: uma regra geral poderia dar tratamento Bronze ao tráfego da engenharia, enquanto uma exceção de maior prioridade destinaria Gold a uma pessoa daquela equipe. O modelo permitia registrar o conflito e a prioridade. Uma implementação concreta ainda precisava avaliar condições, resolver a ordem aplicável e traduzir a ação para o comportamento específico do equipamento.

“Declarativo”, com uma lacuna deliberada

A RFC 3060 chama sua abordagem de declarativa, mas delimita o que isso significa. O modelo define entidades e atributos; não define o algoritmo que produz um resultado a partir deles nem uma sequência explícita de etapas de processamento. É possível registrar se a ordem desejada das ações é obrigatória ou apenas recomendada, mas o procedimento de avaliação fica fora do modelo comum.

Isso é um limite cuidadoso, não a prova de um ambiente universal de execução. Uma declaração como “quando a condição C for verdadeira, aplique a ação A” precisa de definições concretas para C e A. Também precisa de tratamento para atributos ausentes ou não suportados, políticas conflitantes, exceções locais e capacidades diferentes entre dispositivos. O PCIM oferecia pontos de extensão, inclusive classes de condição e ação específicas de fornecedores. Isso tornava o modelo adaptável; também permitia que um esquema básico compartilhado coexistisse com semânticas locais diferentes.

Os autores explicaram o equilíbrio pretendido: representar políticas de um modo compreensível e diagnosticável, sem exigir que uma grande variedade de equipamentos processasse uma linguagem completa e complexa. A experiência coletiva com gerenciamento de políticas ainda era limitada, segundo a própria RFC. Em vez de resolver antecipadamente todo caso imaginável, os autores favoreceram um núcleo comum para necessidades então relevantes, como VPN e QoS, com espaço para evolução conforme surgissem requisitos e experiência.

O documento também situou o PCIM no trabalho conjunto do grupo Policy Framework da IETF e do esforço Common Information Model da DMTF. Documentos posteriores deveriam mapear o modelo abstrato para implementações concretas; uma diretoria apoiada em LDAPv3 aparece como exemplo. Essa observação importa: o modelo era um insumo para uma possível implementação, não evidência de que um diretório, servidor de políticas ou roteador específico o tivesse adotado.

A arquitetura ao redor cumpria outras funções

A estrutura anterior de admissão baseada em políticas da RFC 2753 separava o Policy Decision Point (PDP), onde a decisão era tomada, do Policy Enforcement Point (PEP), onde ela afetava um elemento da rede. A RFC 2748 definiu o COPS para trocar solicitações e decisões entre esses papéis. Já a RFC 3084 especificou um uso do COPS para provisionar Policy Information Bases. São camadas próximas, mas não devem ser confundidas com o PCIM: um protocolo de transporte, um modelo de provisionamento e um esquema de informação respondem a perguntas diferentes.

Essa divisão também revela um problema de medição. Um diretório pode conter uma regra; um PDP pode avaliá-la; um PEP pode receber uma decisão; e um roteador pode instalar uma configuração. Cada etapa é um evento distinto. Encontrar um objeto parecido com PCIM em um repositório não mostra qual versão de política um equipamento consumiu, se o ponto de decisão entendeu uma extensão, se o ponto de imposição aceitou a ordem ou se os pacotes receberam o tratamento pretendido.

A revisão mudou o modelo, não o padrão de prova

Publicada em janeiro de 2003, a RFC 3460 atualizou o PCIM. Ela acrescentou elementos, tornou alguns obsoletos e os substituiu por outros, alterou a representação de prioridades e introduziu estratégias de decisão que um administrador poderia especificar. Foi uma evolução real do modelo de informação. Também mostrou que o vocabulário anterior não era definitivo: documentos posteriores podiam rever como regras e opções de avaliação eram representadas.

O documento sucessor, por si só, não comprova execução uniforme. Um campo que representa uma estratégia de decisão não prova que duas implementações a avaliem da mesma forma, aceitem as mesmas extensões ou instalem o mesmo comportamento de encaminhamento. A RFC 3198 distinguiu abstrações de política de negócio de parâmetros específicos de dispositivos e observou que a tradução entre eles pode exigir informações externas sobre capacidades e configuração. Uma representação compartilhada reduz ambiguidades, mas não elimina o trabalho de tradução.

A conclusão histórica deve permanecer restrita. A RFC 3060 documentou uma tentativa de tornar reutilizável a informação de políticas em ambientes de gerenciamento diversos. Seus autores também registraram o limite: objetos comuns não equivalem a um algoritmo universal. As normas demonstram a existência do modelo e de sua revisão posterior; não mostram quais fornecedores o implementaram, quantas redes o usaram ou se as decisões foram interoperáveis em produção.

A lição duradoura é pedir evidências da cadeia inteira. Qual esquema e quais extensões estavam presentes? Que versão de política o ponto de decisão avaliou? Qual algoritmo resolveu sobreposições e prioridades? O que o ponto de imposição instalou? O que a rede efetivamente fez? Uma descrição de políticas interoperável pode ser valiosa. Ela não é um comprovante de resultados interoperáveis.

Fontes