Resumo

  • No RFC 9675, o Manager formula política à distância, mas o Agent autoriza e executa Controls ao lado do equipamento, com condições locais.
  • Um Control não tem código de retorno de RPC; relatórios podem combinar ações, ficar na fila, expirar, ser substituídos ou chegar em ordem diferente da geração.
  • Uma conclusão defensável preserva recibos distintos para intenção, codificação, custódia, recepção, autorização, precondições, execução, recuperação, relatório, fila, reconciliação e observação posterior.

Três ações entraram; um único estado saiu

Um Agent recebeu três Controls em momentos diferentes. O primeiro ajustou um limite. O segundo tentou ativar uma função, encontrou uma precondição inválida e disparou recuperação. O terceiro, escolhido por uma regra local, estabilizou o equipamento. Quando finalmente surgiu uma janela de contato, o Agent enviou apenas um relatório compacto com o estado final.

O relatório pode estar correto. Mesmo assim, ele não responde sozinho qual Control produziu qual mudança, se o primeiro ajuste sobreviveu, por que o segundo falhou nem se o terceiro já alterou novamente o contexto. Se a interface o anexar à última ordem visível, criará uma relação comando-resposta que a arquitetura nunca prometeu.

O cenário é hipotético e não descreve um equipamento real. Ele mostra o custo informacional da gestão tolerante a atrasos. A compressão economiza armazenamento e transmissão; a governança precisa decidir quais vínculos causais não podem ser comprimidos junto.

RFC 9675 torna possível operar sem o diálogo contínuo. Não transforma o produto final desse diálogo ausente em prova universal.

Uma arquitetura lógica com limites explícitos

Publicado em novembro de 2024, o RFC 9675 descreve a Delay-Tolerant Networking Management Architecture, a DTNMA. É um documento Informational do fluxo IETF, aprovado pelo IESG e representativo do consenso da comunidade IETF. Não é uma especificação Internet Standards Track.

Seu escopo é uma arquitetura lógica e informacional: componentes, comportamentos habilitados e casos de uso. Ele não fornece um desenho funcional completo nem todas as interfaces. Não exige BPv7, embora Bundle Protocol seja uma escolha natural em alguns ambientes intermitentes. Transporte, nomes, endereçamento, roteamento e segurança das comunicações ficam fora do escopo.

Esses limites evitam extrapolações. O RFC não prova que um produto implementa DTNMA, que um comando chegou a um dispositivo, que foi autorizado ou que uma mudança ocorreu. Também não é registro de implantação. A evidência de adoção aparece em Agents e Managers em operação, modelos, regras, Controls, esquemas de relatório, políticas de fila e históricos de execução.

A necessidade surge onde dispositivos dormem, enlaces são unidirecionais, a capacidade de ida e volta é desigual e a desconexão dura dias. Serviços como DNS ou autoridade certificadora podem não estar disponíveis continuamente. Uma oportunidade de contato pode terminar antes de uma única rodada de pergunta e resposta.

O Manager configura quem age localmente

O DTNMA Manager representa o operador remoto. Recebe objetivos de aplicações de gestão, codifica a política, agrega mensagens e endereça os Agents. O DTNMA Agent representa o operador local. Próximo ao equipamento, coleta e funde dados, valida informações, aplica autorização, executa Controls e trata falhas.

Há, portanto, dois níveis. Um administra a configuração do operador local; o outro opera o equipamento por meio desse operador. A intenção remota não se converte diretamente em estado físico ou de aplicação. Ela entra numa superfície onde já existem observações, limites de recursos, regras e atualizações concorrentes.

Mesmo numa conexão rápida, todo controle é local. O Agent avalia e executa o Control como resposta de sua autonomia. A sessão que trouxe a mensagem não precisa permanecer, e o Manager não contorna a política local.

Essa divisão torna a autoridade mais precisa. O remoto declara o objetivo e sua abrangência; o local registra por que admitiu, adiou, rejeitou ou reverteu uma ação. Uma auditoria precisa das duas narrativas, não de uma etiqueta que substitua ambas.

Control não é RPC com timeout enorme

Control é um procedimento parametrizado predefinido, executado pelo Agent por direção do Manager ou por seleção de uma regra local. Uma macro é uma sequência ordenada de Controls.

O RFC 9675 destaca que Controls não têm conceito de código de retorno. Um retorno pressupõe relação síncrona entre chamador e procedimento, justamente a relação indisponível numa rede desafiada.

Alongar o timeout não recupera a sincronia. Quando a execução começa, o objetivo pode ter vencido, uma leitura pode estar velha e outra atualização pode disputar o mesmo recurso. Uma macro pode falhar após os primeiros passos já terem alterado o sistema. A falha vira estado do Agent e pode acionar regra de rollback ou safing antes de qualquer notícia chegar ao centro.

O recibo útil contém versão de política, hora exata de recepção, autorização, entradas e frescor, precondições, cada etapa, conflito, recuperação e observação posterior. “Concluído” pode significar apenas que um procedimento terminou; não prova o objetivo nem a permanência de seu efeito.

Em malha aberta, relatório e comando deixam de formar pares

Uma aplicação pode esperar por uma resposta antes de agir novamente ou continuar emitindo política em malha aberta. Na arquitetura, uma malha fechada pode demorar milissegundos, horas, dias ou anos.

Não há bijeção entre comandos e relatórios. Um relatório pode representar o estado após vários Controls. Um Control pode influenciar vários relatórios. A associação pode não existir. Uma política de armazenamento pode remover um relatório antes da transmissão.

Um identificador de mensagem prova qual objeto transitou na custódia, não qual estado decorreu dele. Um identificador de política nomeia a intenção, não sua validade ao chegar. Um identificador de Control nomeia um procedimento, não mostra as entradas efetivas nem o que uma recuperação posterior desfez.

O livro de evidências precisa ligar, sem fundir, objetivo, expressão codificada, custódia, autorização, execução, observações, relatório e estado posterior. Relações muitos-para-um devem permanecer visíveis. Caso contrário, a tela seleciona a última ordem por conveniência e passa a vender conveniência como causalidade.

O relógio de recebimento conta uma história diferente

Relatórios nascem do estado local, independentemente de conexão com o Manager. Podem permanecer armazenados, viajar por rotas distintas e sofrer retransmissões. O RFC 9675 alerta que o receptor não deve extrair significado da ordem de chegada.

Cada relatório requer horário de geração e contexto: Agent, esquema, versões de regra e política. A hora em que uma API recebeu o objeto serve à operação do transporte, mas não substitui a hora observada. Quando os relógios são incertos, a incerteza deve ficar registrada; impor uma ordem total só deixa o gráfico mais convincente do que a prova.

O armazenamento cria outra fronteira. Relatórios podem expirar, ser substituídos ou removidos sem envio. O silêncio pode significar ausência de evento, supressão por regra, espera na fila, expiração, recusa de autorização, mudança de destino, falta de conectividade ou indisponibilidade do Agent. Sem recibo adicional, nenhuma dessas hipóteses vence.

A fusão cria informação, não preserva tudo

O Agent pode transformar amostras e contadores em médias, extremos, alertas e estados resumidos. Isso reduz volume e permite aproveitar contatos curtos. O resultado, porém, é um novo objeto produzido por uma regra específica. Não contém automaticamente todas as observações de origem.

Se a regra de fusão muda, relatórios com aparência semelhante podem deixar de ser comparáveis. Um estado final verdadeiro pode omitir a falha intermediária que importa para uma investigação. O RFC não proíbe manter dados brutos e reconhece seu valor para depurar interações complexas. A organização deve definir o que é insubstituível antes que a fila fique cheia.

Frescor também tem janela. Um valor pode ser atual quando a regra o consome, histórico quando o relatório é gerado e obsoleto quando chega. Assinatura e confidencialidade preservam propriedades de segurança; não transportam a medição de volta para o presente.

Muitos Managers exigem uma história da autoridade

A topologia pode apresentar Managers diferentes a partições diferentes. RFC 9675 permite associações muitos-para-muitos e separa “controle vindo de” de “relatório enviado a”.

Essa flexibilidade evita presumir um centro permanentemente alcançável. Também exige escopo, precedência, validade e regras de conflito. Na reconexão, a evidência precisa indicar o mapeamento de Managers, as políticas concorrentes, a decisão de autorização do Agent e a regra local vencedora. O primeiro relatório a chegar não pode promover seu Manager retroativamente.

Segurança não elimina as separações. Custódia autenticada não prova autorização para modificar uma aplicação. Autorização não prova precondições. Execução não prova objetivo. Relatório assinado pode ser autêntico, incompleto e velho simultaneamente.

Treze degraus, não um selo de sucesso

A trilha começa com objetivo, escopo, autoridade, versão, decisão e validade. Em seguida preserva codificação exata do Manager, conjunto de Agents, agregação e custódia. No Agent, registra bytes recebidos, autorização, entradas frescas, limites e atualizações concorrentes.

Depois vêm cada Control e etapa da macro, deltas, falhas, rollback e safing. Observações brutas e fundidas carregam origem e frescor. Relatórios carregam esquema, geração, Controls contribuintes, inserção, substituição, expiração, remoção e transmissão. O Manager reconcilia por contexto de evento, não por chegada.

O último degrau é uma observação independente e recente, limitada no tempo, para a decisão que realmente depende do estado atual. Nenhum dos degraus iniciais pode ser promovido para esse lugar por conveniência da interface.

Da coordenação escrita à adoção observável

O caráter Informational e lógico do RFC 9675 marca o alcance correto de sua autoridade. O texto coordena papéis; implementações escolhem transporte, segurança e política local; o código em execução e os recibos mostram o que se tornou efetivo.

As lentes de Heng Lu sobre especificação mínima, camadas de realidade e primazia do running code ajudam a evitar o salto. Política escrita, regra executável, relatório apresentado e resultado físico são camadas relacionadas, mas não idênticas. Um símbolo verde não deve ocupar o lugar de todas elas.

Para a liderança, a rede difícil não justifica prova fraca. Quanto maior a demora, mais importantes se tornam tempo, custódia, autoridade e causalidade.

Fontes