Resumo

  • A RFC 3318 permitia * numa combinação de papéis de política, fazendo uma regra abranger interfaces com os papéis exigidos e qualquer quantidade de papéis adicionais.
  • O curinga não definia prioridade: o PDP precisava resolver incompatibilidades, e o PEP tinha de rejeitar o conflito restante em vez de montar uma política local.

Repetição aparece em qualquer revisão de configuração. Sobreposição costuma aparecer apenas quando duas regras tentam controlar o mesmo recurso. A Framework PIB ligou os dois problemas ao uso de papéis: eles libertavam a política dos nomes locais das interfaces, mas o curinga tornava possível que mais de uma regra cobrisse o mesmo conjunto.

Na arquitetura COPS-PR, o Policy Decision Point escolhia o que provisionar e o Policy Enforcement Point representava o equipamento que receberia a decisão. A SPPI definia classes e instâncias de uma Policy Information Base. A RFC 3318 acrescentava vocabulário comum para papéis, capacidades, versões de estado, limitações e erros.

Um papel era uma string associada à função de uma interface, como finance, manager, backbone ou firewall. Uma interface podia ter vários papéis. A política carregava uma RoleCombination, usada para definir aplicabilidade sem depender do identificador físico de cada porta. Interfaces funcionalmente equivalentes podiam receber uma única cópia da política.

A representação era rígida. A comparação diferenciava maiúsculas e minúsculas, e os papéis eram ordenados lexicograficamente pelos valores ASCII. a+b era válido; b+a não era outro conjunto, mas uma forma inválida do mesmo. O conjunto vazio era null. A forma canônica evitava que diferenças de impressão fossem confundidas com diferenças de política.

O asterisco ampliava essa reutilização. Em classes install ou install-notify, *+a+b combinava com uma interface que incluísse a e b, além de zero ou mais outros papéis. * não podia ser um papel real informado pela interface nem um curinga dentro de um nome. O exemplo normativo dizia que *+b+e+g combinava com a+b+c+e+f+g.

Assim, três interfaces com A e B, mas também R1, R2 e R3, podiam compartilhar uma política *+A+B. O PDP enviava menos cópias e o operador exprimia diretamente a propriedade comum.

Mas inclusão não é precedência. Uma interface podia coincidir com várias combinações que continham curinga. Algumas políticas seriam compatíveis; outras atribuiriam tratamentos incompatíveis ao mesmo mecanismo. O padrão dizia que ambas eram aplicáveis, sem dizer qual deveria vencer.

A RFC 3318 deixava a resolução com o PDP. Ele deveria eliminar o conflito antes de enviar. Se políticas incompatíveis ainda chegassem ao PEP, por erro do controlador ou por uma limitação específica do dispositivo, o equipamento deveria rejeitar a instalação e retornar erro. A recusa impedia que execução virasse decisão sem autorização.

O exemplo de finanças e gerência fixava a fronteira. Duas interfaces inicialmente tinham finance e outra tinha manager. Quando uma pessoa de finanças era promovida, a interface passava a informar finance+manager. O PDP podia preferir a política de gerência ou criar uma terceira, por exemplo DSCP 7 para gerentes financeiros. Mesmo que repetisse uma política existente, precisava enviar uma resposta explícita para a nova combinação.

O PEP não tinha permissão para construir a nova política combinando as anteriores. Se pudesse fazê-lo, fabricantes diferentes poderiam produzir resultados diferentes a partir da mesma entrada, e o controlador perderia a explicação da autoridade. Uma rejeição deixa prova de uma decisão incompleta; uma fusão silenciosa deixa apenas um resultado aparentemente bem-sucedido.

Mudar papéis também levava tempo. O PEP informava associações no estado completo. O PDP podia alterá-las por decisão não solicitada. Depois de processar com sucesso, o PEP primeiro reportava sucesso e então enviava estados completos atualizados para os contextos abertos. Se falhasse, enviava apenas o relatório de falha. Antes disso, o PDP não devia pressupor o novo estado.

Durante a transição, decisões ainda podiam refletir papéis antigos. Portanto, a etiqueta nova não provava que todas as políticas dependentes tinham sido recalculadas. A RFC 3084 fornecia o ciclo de solicitação, decisão e relatório; a RFC 3159 fornecia o modelo PIB. A evidência precisava separar papel pretendido, aceitação, estado atualizado, política instalada e comportamento de pacotes.

Proteção de transporte não resolvia significado. A RFC 3318 alertava que informação configurável podia ser mal configurada com efeitos graves. Autenticação identificava o remetente e criptografia protegia o conteúdo, mas nenhuma determinava se finance ou manager deveria prevalecer.

Em 2016, o IESG moveu a RFC 3318, COPS-PR e SPPI para Historic, citando implantação limitada e a mudança do trabalho de gestão para NETCONF e YANG. Isso impede tratar a arquitetura como adoção ampla. Não elimina a lição: um curinga reduz texto, não a obrigação de indicar quem arbitra.

Fontes: RFC 3318, RFC 3084, RFC 3159 e a mudança de status do IESG de 2016.