Resumo

  • O código 314, o Application-Id 16777243 e o AVP Policy-Data identificam o intercâmbio registrado pelo RFC 5224. Eles coordenam implementações, mas não certificam a origem dos fatos nem o mandato de quem decidiu.
  • A arquitetura da OMA permite avaliação sem execução. A decisão pode voltar ao recurso solicitante, que controla a ação seguinte, ou a própria PEEM pode executar. Os dois caminhos não são evidenciados pelo mesmo sinal genérico de sucesso.
  • O registro operacional deve ligar pedido, versão da política, proveniência dos dados, decisão, recebimento pelo executor, instalação, ativação, substituição posterior e efeito observado.

Uma resposta pode chegar a um atuador parado

Considere um teste de mesa. Às 13:30:00, um recurso envia PDR. Um segundo depois, PDA chega com a aplicação esperada, correlação válida e resultado de sucesso. O painel anuncia “política aplicada”. O adaptador de enforcement continua desconectado. Quando volta, uma decisão local mais nova já domina o alvo.

Nada falhou na camada que o painel efetivamente mediu. O erro foi emprestar o sucesso dessa camada às seguintes.

O RFC 5224 é Informational. Ele registra o Command Code 314 para PDR/PDA, o código 1 para Policy-Data no espaço OMA e o Application Identifier 16777243. Para a descrição detalhada e o uso normativo de Diameter, remete à especificação PEM-1 da OMA.

Essa divisão evita que um documento de registro seja tratado como telemetria de produção. O RFC mostra como uma mensagem deve ser reconhecida. Só a implantação pode mostrar qual política foi escolhida, quais fatos a alimentaram, quem deveria executar e o que mudou no final.

O número identifica a linguagem, não a autoridade

O registro AAA da IANA mantém as atribuições. A ligação OMA usa Vendor-Id 30079 e anuncia suporte no capabilities exchange. Isso permite interoperabilidade.

Mas Application-Id não é delegação. Vendor-Id não autoriza uma decisão sobre qualquer assinante ou serviço. Realm e Host encaminham; não conferem competência. Capability indica suporte, não confiança ilimitada.

O RFC 5224 herda as considerações de segurança do RFC 3588, depois substituído pelo RFC 6733. Proteger a conexão autentica o par e preserva a mensagem. Não prova que um saldo, uma localização ou um score interno era atual, nem que aquele par possuía autoridade empresarial sobre o recurso.

Uma auditoria deve distinguir o par criptográfico, a relação que permite a aplicação e o principal autorizado para a política específica. Se a arquitetura liga os três, essa ligação precisa de versão, validade e evidência.

Template correto não torna o contexto verdadeiro

A especificação PEM-1 usa BLOBs e templates padrão ou personalizados para transportar entradas e saídas variáveis. A solução oferece estrutura comum sem impor um único conjunto de dados.

O templateID e a versão ajudam a interpretar os campos. Eles não demonstram que todos os dados necessários estavam presentes, que cada origem era legítima ou que o valor não envelheceu antes da avaliação.

A própria OMA declara fora de escopo os mecanismos de publicação das opções suportadas. Também não define como uma implementação processa os parâmetros de entrada ou como o solicitante processa a saída. Essa margem pertence à implantação.

Por isso o recibo do pedido deve preservar Policy-Data bruto, template e versão, sujeito, recurso, política e versão, fonte e tempo de cada entrada e chamadas delegadas. Sem isso, o resultado é decodificável, mas sua razão não é auditável.

Processar pode terminar antes de executar

PEM-1 define policy processing como avaliação, ou avaliação e enforcement. A arquitetura PEEM mostra as alternativas.

PEEM pode devolver uma decisão ao solicitante, que decide como tratá-la. Pode executar por conta própria e talvez não devolver valor. Também existe um modelo de avaliação apenas, sem ação nem enforcement pela PEEM.

PV avalia e devolve resultado; PF realiza a ação consequente e pode delegar. Estarem no mesmo produto não elimina a necessidade de saber se o segundo estágio aconteceu.

O IETF conserva a mesma separação. O RFC 2753 situa decisão no PDP e execução no PEP. O RFC 3198 define enforcement como execução de uma decisão. “O PEP deve executar” é uma obrigação; “este PEP executou agora” é um fato a provar.

Há mais de um sucesso dentro da resposta

Diameter possui Result-Code ou Experimental-Result. O termo Experimental identifica um contêiner de resultado do fornecedor, não uma observação experimental do estado do serviço.

PEM-1 acrescenta Output Status com statusCode obrigatório para o processamento ou erro. A política ainda pode produzir decisão e dados próprios. Protocolo aceito, processamento concluído e decisão devolvida podem coexistir antes de qualquer instalação.

Use estados explícitos: transportado, aceito, avaliado, decisão devolvida, recebido pelo executor, instalado, ativo, efeito observado, substituído e revertido. Uma tela pode agrupá-los; o ledger não deve apagá-los.

O binding usa NO_STATE_MAINTAINED. O servidor não guarda estado de sessão Diameter e o cliente não precisa encerrá-la. A resposta prova o intercâmbio, não a permanência da política ou sua história de substituição.

Fiabilidade não é execução

O RFC 3539 cobre watchdog, failover, pedidos pendentes e duplicatas AAA. Ele ajuda a explicar repetição e entrega, não efeito. O RFC 2989 cobre capacidades AAA; capacidade não é recibo de uma ação. O RFC 7683 e o RFC 4006 reforçam que carga, estado da aplicação e resultado do serviço têm semânticas próprias.

O caminho mínimo registra pedido e rota, par seguro, sujeito, recurso, versão da política e do template, proveniência, dependências, resultado Diameter, status PEEM, saída de negócio, executor escolhido, recibo, alvo, estado anterior, instalação, readback, ativação, falhas parciais, rollback, decisões posteriores e efeito medido.

Uma decisão substituída continua tendo sido devolvida. Uma instalação que falhou não transforma retroativamente a resposta em falha; acrescenta um fato ao estágio seguinte. Preservar essa sequência permite localizar causa e compensar sem falsificar a história.

Na doutrina das camadas de realidade de Lu Heng, o identificador classifica, a resposta registra e a decisão orienta. A realidade seguinte só existe quando sistemas em execução recebem, instalam, agem e expõem estado observável. Clareza é impedir que o registro mais cedo governe por linguagem aquilo que ainda não controlou.

Fontes

  1. RFC 5224
  2. RFC 5224 em texto
  3. RFC 5224 no IETF Datatracker
  4. Status do RFC 5224
  5. Histórico do RFC 5224
  6. Errata do RFC 5224
  7. RFC 3588
  8. RFC 6733
  9. RFC 3539
  10. RFC 2989
  11. RFC 2753
  12. RFC 2748
  13. RFC 3198
  14. RFC 3084
  15. RFC 2903
  16. RFC 2904
  17. RFC 4006
  18. RFC 7683
  19. RFC 5234
  20. Parâmetros AAA da IANA
  21. Especificação técnica OMA PEM-1
  22. Arquitetura OMA PEEM
  23. Requisitos OMA PEEM
  24. Registro OMA de AVPs privados
  25. Lu Heng — Camadas da realidade e poder simbólico
  26. Lu Heng — Primazia do código em execução
  27. Lu Heng — O problema de agência