Resumo

  • A RFC 3159 exigia que PIB-INDEX apontasse para um único InstanceId e dizia que esse valor não possuía semântica além de identificar a instância da PRC. Endereço preciso não era explicação de política.
  • O significado dependia do módulo PIB, das definições de PRC e convenções textuais, da categoria de assunto, do modo de acesso, das restrições de unicidade e referência, da conformidade e dos ciclos de vida de AUGMENTS e EXTENDS.
  • Aceitação, instalação e efeito precisavam de recibos posteriores: COPS-PR, resultado da transação, estado do PEP, comportamento efetivo e resultado da aplicação. O status Historic e a adoção limitada não apagam essa fronteira.

Duas chaves não provavam duas intenções

Considere um PDP enviando duas Provisioning Instances para um roteador. Classificador, ação, limiar e fila referenciada são idênticos. Apenas os valores de InstanceId diferem.

Uma tabela mostra duas linhas, mas ainda não mostra duas políticas. O módulo pode aceitar conteúdo duplicado. Uma cláusula de unicidade pode proibi-lo. Uma linha pode ser extensão esparsa sem a base necessária. As linhas podem viver em depósitos virtuais distintos. Mesmo com o esquema válido, o PEP pode recusar a instalação.

Na SPPI, PIB-INDEX tinha exatamente um descritor de sintaxe InstanceId. O valor, baseado em Unsigned32, não possuía outro significado além de identificar a instância da PRC. Acrescentado ao OID da definição da linha, ele formava o PRID.

O PRID era um endereço. Se um produto codificasse cliente, prioridade ou região dentro do número, criaria um segundo esquema invisível. Uma renumeração quebraria esse contrato clandestino sem violar o esquema oficial. Retirar significado do identificador protegia a clareza: o sentido precisava aparecer onde pudesse ser validado.

A SPPI aproveitou a SMI, mas redesenhou os substantivos

Publicada em agosto de 2001, a Structure of Policy Provisioning Information adaptou a SMI do SNMP para escrever Policy Information Bases. O formato ASN.1, a experiência e as ferramentas existentes poderiam ser reutilizados.

Havia, porém, uma colisão de linguagem. COPS já chamava seus elementos de protocolo de objects. Por isso, SPPI chamou a tabela e a definição de linha de Provisioning Class, ou PRC; chamou uma linha instanciada de Provisioning Instance, ou PRI; e chamou as colunas de atributos. Não incluiu o equivalente aos objetos escalares da SMI.

MODULE-IDENTITY descrevia a semântica do módulo. OBJECT-TYPE descrevia PRCs e atributos. Convenções textuais acrescentavam significado específico a tipos reutilizáveis. Grupos e declarações de conformidade definiam mínimos de implementação.

Tudo isso estruturava dados; não executava a política. Uma PRI podia estar bem formada e completa sem ter sido aceita. A aceitação podia ocorrer sem confirmação do estado local. A configuração podia existir sem jamais encontrar tráfego correspondente.

O PIB-INDEX localizava; o INDEX comum servia à conversão

Uma linha base precisava de PIB-INDEX, salvo quando herdava identidade por AUGMENTS ou EXTENDS. O descritor apontava para um atributo InstanceId, em geral da mesma PRC, mas não necessariamente.

Também podia existir um INDEX comum. Sua finalidade era outra: a conversão algorítmica de PIB para MIB. Tratar as duas cláusulas como sinônimos confundiria a identidade da instância de provisionamento com a indexação de uma representação administrativa derivada.

Um arquivo de auditoria não pode guardar apenas o PRID. Precisa do módulo e da revisão, da definição da PRC, das convenções textuais e do contexto. Sem esse dicionário, o OID é exato e órfão ao mesmo tempo.

O esquema recupera o significado possível da linha. Não recupera sozinho a prova de que o equipamento a instalou.

O significado estava distribuído por vários contratos

A PRC definia atributos e descrições. Convenções textuais davam semântica específica a inteiros ou cadeias comuns. SUBJECT-CATEGORIES associava o módulo a COPS Client Types nomeados ou a todos. Um módulo podia aparecer em mais de um depósito virtual.

PIB-ACCESS dizia como a PRC circulava. install permitia ao PDP instalar instâncias no PEP. notify obrigava o PEP a informar ao PDP todas as instâncias e valores. install-notify combinava as duas propriedades. report-only não tinha nenhuma delas, embora pudesse aparecer em relatórios síncronos ou assíncronos.

O número não revelava esse papel. Uma linha instalável e uma linha usada apenas em relatório podiam ter identificadores igualmente estáveis. Para saber quem produz a informação e o que pode fazer com ela, era necessário consultar a definição.

A declaração de conformidade também tinha limite: dizia o que uma implementação alegava suportar, não qual PRI estava ativa naquele instante.

Unicidade e identidade eram perguntas diferentes

UNIQUENESS listava atributos cujo conjunto de valores não podia se repetir entre instâncias da PRC. O atributo indicado por PIB-INDEX não podia aparecer nesse conjunto.

Assim, o protocolo mantinha duas noções separadas. O ID oferecia uma chave para referência. Os atributos de unicidade podiam constituir uma chave de conteúdo. Uma cláusula vazia permitia que duas linhas fossem iguais em todos os atributos, exceto o número.

IDs diferentes não demonstravam políticas diferentes. Conteúdo igual também não autorizava fusão automática, porque referências, depósitos ou relações de ciclo de vida poderiam divergir.

A RFC recomendava UNIQUENESS quando ela fosse útil, mas não a tornava universal. Na ausência da declaração, uma ferramenta não podia escolher campos por conveniência e chamar a escolha de regra do padrão.

Uma referência precisava conservar seu destino declarado

Um atributo ReferenceId exigia PIB-REFERENCES, que nomeava a PRC da instância de destino. Um TagReferenceId exigia PIB-TAG, que informava o atributo usado para montar uma lista de instâncias com a mesma etiqueta.

Uma forma apontava para uma instância em um tipo declarado; a outra selecionava um conjunto. Os bytes do número não informavam qual relação estava em uso.

A instância 12 na PRC de filas não era automaticamente a instância 12 na PRC de limiares. Uma etiqueta 7 não era global fora do atributo e da PRC que definiam seu escopo. Guardar só o inteiro preservava a aparência de um vínculo e apagava o endereço real.

Uma evidência recuperável precisava da origem, da convenção textual, da PRC de destino, das regras de identidade do destino e da revisão do módulo.

Base, aumento e extensão esparsa obedeciam a vidas distintas

Cada definição de linha usava exatamente um dos três caminhos: PIB-INDEX, AUGMENTS ou EXTENDS.

Uma linha AUGMENTS tinha relação um para um com a base, reutilizava seu índice e compartilhava sua existência. Instalar ou remover a base instalava ou removia todos os aumentos correspondentes.

Uma linha EXTENDS era esparsa. Não podia existir sem a base, mas a base podia existir sem ela. Exigia instalação explícita, podia ser removida antes e desaparecia implicitamente com a base. Se base e extensão fossem instaladas juntas, deveriam seguir em uma única mensagem COPS.

O mesmo valor de instância podia, portanto, participar de três regimes temporais. Restaurar linhas sem restaurar relações criava registros endereçáveis que não satisfaziam suas condições de existência.

Identidade conecta registros. Ciclo de vida determina se a conexão é válida ao longo do tempo. Uma captura estática não substitui a história de instalação e remoção.

Uma linha válida ainda podia falhar na instalação

INSTALL-ERRORS permitia enumerar motivos específicos para rejeitar a instalação ou remoção de uma PRC. Cada motivo tinha um subcódigo COPS. A falta da cláusula não significava sucesso garantido; a operação ainda podia falhar, apenas sem erro específico da PRC.

Essa regra impede uma escalada indevida de certeza. Validação de esquema não é aceitação pelo PEP. Aceitação não é conclusão da transação. Transação concluída não é estado local verificado. Configuração presente não é tráfego afetado. Tráfego afetado não é resultado da aplicação.

COPS-PR oferecia decisões, erros, conclusão ou aborto, cache e reconciliação após reconexão. SPPI oferecia a linguagem dos dados. Um não substituía o recibo do outro.

Se o painel tiver um único “sucesso”, precisa dizer qual etapa foi comprovada. Caso contrário, o primeiro êxito sintático encobre todas as incertezas seguintes.

Conformidade descrevia capacidade, não uma execução

Grupos de objetos reuniam atributos relacionados. MODULE-COMPLIANCE declarava grupos obrigatórios e mínimos de acesso. Uma implementação que alegasse conformidade deveria implementar os atributos e PRCs correspondentes.

Ela ainda podia não ter nenhuma instância instalada. Podia armazenar uma PRI sem ativar a conduta. A conduta ativa podia nunca encontrar tráfego. Capacidade, configuração e resultado eram estados diferentes.

A seção de segurança também era estreita. A RFC dizia que a linguagem de definição de informações de provisionamento, por si, não causava impacto de segurança na Internet. Não certificava a sessão COPS, a autoridade do PDP, o conteúdo da política ou a implementação do PEP.

Uma afirmação de segurança não pode crescer além da camada que ela realmente cobre.

Historic registrou uma mudança, não apagou o mecanismo

Mais tarde, a RFC 6632 registrou que COPS-PR não teve implantação ampla. Operadores consideravam a codificação binária difícil para tarefas simples em linguagens de script textuais. Nenhum módulo PIB recebeu aprovação como Proposed Standard, e o uso de COPS-PR deixou de ser recomendado. A RFC 3159 hoje é Historic.

Essa trajetória precisa aparecer. SPPI não deve ser retratada como a configuração dominante atual. Mas implantação limitada não quer dizer que nenhuma implementação existiu, e Historic não autoriza inferências sobre cada equipamento.

O caminho abandonado ainda expõe uma boa fronteira: endereço, significado, acesso, relação de existência, transação e efeito não são equivalentes. Um sistema moderno pode repetir o erro ao tratar um URI ou uma resposta HTTP 200 como prova de comportamento em execução.

Popularidade decide qual tecnologia venceu. Não decide sozinha qual disciplina de evidência continua valiosa.

O artefato durável era a cadeia completa

Um registro auditável começa com módulo PIB, revisão, categoria de assunto e depósito virtual. Preserva PRC, convenções, relação base/aumento/extensão, InstanceId, PRID, unicidade, referências, etiquetas, acesso e perfil de conformidade.

Depois guarda solicitação e decisão COPS-PR, identificador e resultado da transação, erros, cache, reconexão e estado do PEP antes e depois. A observação do tráfego demonstra a aplicação. O sistema consumidor avalia o resultado final.

O módulo explica os campos. O PRID aponta a instância. O protocolo prova o intercâmbio. O dispositivo prova a instalação. O tráfego prova a aplicação, e a aplicação prova a utilidade.

O índice da RFC 3159 era confiável porque não fingia ser toda essa cadeia. Ele nomeava a linha; não fabricava o resultado.

Fontes