Resumo

  • O draft-feng-netconf-naim-op-00 permite que compensation contenha objetos Operation IR destinados a reverter ou mitigar mudanças já executadas. O próprio rascunho prevê falha da compensação, timeout do grupo e perda de conectividade durante o rollback.
  • Um identificador compartilhado agrupa operações, mas não especifica commit atômico, isolamento, bloqueio, ordenação ou um ponto único de restauração entre dispositivos e protocolos.
  • Uma alegação de recuperação precisa do percurso probatório completo: referência anterior, autorização de cada ação, precondições ao vivo, mensagens e respostas, concorrência, estado posterior, validação independente do serviço e efeitos que não podem ser desfeitos.

Voltar é uma nova mudança

Imagine dez interfaces que devem receber uma política nova. O agente prepara a intenção e também uma compensação: recolocar a referência antiga se o teste falhar. Três equipamentos aceitam a alteração; o quarto perde a sessão; a verificação de serviço aponta problema.

O plano de retorno agora opera contra outra realidade. Um segundo controlador atualizou uma das interfaces. Um vizinho já processou anúncios. Uma notificação abriu um procedimento humano. A função usada na ida talvez não possa excluir ou alterar objetos na volta. Escrever o valor anterior pode corrigir duas caixas, apagar uma edição legítima na terceira e não alcançar a quarta.

Por isso a definição do rascunho é importante. Uma Compensation Operation é destinada a “reverter ou mitigar” o efeito anterior. Destino não é resultado. Mitigação não é sinônimo de restauração exata. O objeto descreve o próximo ato permitido; não apaga a história.

A separação entre intenção e executor

Operation IR é uma representação intermediária neutra em relação ao protocolo. Ela fica entre o pedido em linguagem natural e NETCONF, RESTCONF ou outro backend. Pode carregar escritas, consultas, RPC/actions, filtros, datastore, precondições, expressões, metadados de transação e compensações. A IA codifica intenção; um Handler determinístico valida, lê o estado vivo, traduz e executa.

O status precisa permanecer explícito. O Datatracker apresenta a revisão 00, de 18 de julho de 2026, como Internet-Draft individual ativo, sem stream de RFC e sem Intended RFC status formal. Também informa que o I-D não é endossado pelo IETF e não tem posição formal. O cabeçalho submetido diz “NETCONF Working Group” e “Intended status: Standards Track”; são declarações do documento, não adoção pelo grupo nem consenso do IETF.

O texto ainda exclui algoritmos automáticos de derivação da compensação, detalhes do escalonador e lógica privada do executor. Assim, Handlers distintos podem gerar compensações diferentes a partir da mesma ida. Um log que registra apenas “rollback automático acionado” omite justamente o que deve ser auditado: os objetos, alvos, valores, datastores e pressupostos efetivamente usados.

O número da transação não cria uma transação de banco de dados

A seção 12 permite associar objetos por um identificador compartilhado. A correlação ajuda a juntar eventos. Não há, porém, uma definição de tudo-ou-nada, isolamento serializável, trava global, ordem obrigatória, log durável ou ponto comum de retorno.

A diferença aparece quando o grupo atravessa superfícies heterogêneas. Um dispositivo pode oferecer candidate e confirmed commit; outro escreve diretamente em running; um RPC de aplicação pode produzir uma consequência fora da rede. O mesmo identificador encontra esses fatos no relatório, mas não uniformiza capacidades ou falhas.

Nem mesmo a ordem inversa é automática. Criar uma política, vinculá-la e ativar um serviço produz dependências. Se outro serviço passou a usar o objeto, excluí-lo durante a compensação cria novo dano. O inverso sintático pode estar errado porque o estado mudou desde a elaboração do plano.

A volta precisa de autorização própria

O rascunho afirma que compensações devem obedecer às mesmas expectativas de autorização, validação e logging das operações normais. A seção de segurança destaca autorização para operações compensatórias e auditoria de execução e rollback.

A permissão de ida não deve ser copiada. Criar e excluir podem exigir privilégios distintos. O papel pode expirar. Uma referência dinâmica pode apontar para outro alvo. RFC 8341 controla separadamente operações e nós de dados em NETCONF/RESTCONF; o objetivo de recuperação não transforma negação em permissão.

Precondições impedem que um valor antigo seja aplicado sobre estado novo. Ainda assim, uma leitura correta antes do envio é um ponto no tempo. Ela não prova que a escrita chegou, persistiu ou recuperou o serviço. Cada compensação precisa registrar principal, regra de acesso, alvo resolvido, valor observado e resultado.

O caminho de emergência também falha

O documento pede que implementações com transações definam comportamento para precondição malsucedida, falha no meio do grupo, falha da compensação, timeout e perda de conectividade durante rollback. Isso coloca a recuperação dentro do modelo de falhas, onde ela pertence.

Depois de uma queda de sessão, o Handler talvez não saiba se o dispositivo não recebeu a mensagem ou se aplicou e perdeu a resposta. Repetir uma ação não idempotente pode duplicar o efeito; não repetir pode deixar o estado parcial. Um booleano rolled_back não é suficiente. Devem existir estados separados para planejado, autorizado, precondição verificada, enviado, confirmado, observado e validado no serviço.

NETCONF mostra uma garantia estreita e seus limites

O RFC 6241 define rollback-on-error para um servidor que anuncia essa capacidade. Dentro de um edit-config, o servidor pode parar no erro e restaurar a configuração especificada ao estado completo do início daquela operação.

Mesmo nesse escopo, o RFC alerta que, em configuração compartilhada, o rollback pode alterar ou remover mudanças de outras sessões se não houver bloqueio. Também existe o erro rollback-failed. Confirmed commit tem outra capacidade e depende do candidate datastore.

Uma compensação Operation IR pode ser mapeada para esse mecanismo, para uma escrita RESTCONF ou para uma action. A garantia mais forte de um backend não se espalha pelo grupo apenas porque todos usam a palavra rollback. Restaurar um trecho de configuração tampouco prova recuperação de todo o serviço.

O mesmo valor não recria o mesmo mundo

O RFC 8342 separa configuração pretendida de estado operacional. Um subtree pode coincidir com o snapshot anterior enquanto o estado aplicado e o serviço permanecem diferentes. Fora do datastore, há efeitos sem inverso: pacotes enviados, notificações consumidas, credenciais expostas, temporizadores vencidos, alertas de clientes e decisões humanas.

Uma compensação bem-sucedida pode mitigar o dano sem restaurar tudo. Isso não diminui seu valor. O erro começa quando a interface converte “compensação concluída” em “sem impacto”. O relatório deve delimitar o que voltou, o que não pôde ser observado e o que permaneceu.

Dry-run é ensaio com lacunas declaradas

No modo dry-run, o Handler não deve aplicar mudanças e deve apresentar alvos, valores, datastore, checagens, resumo das mensagens, plano de compensação, efeitos e limitações. O texto admite que estado vivo, autorização e condições externas podem não ser verificáveis antes da execução.

Logo, uma boa prévia dá destaque ao que ainda é desconhecido: resolução baseada em snapshot, permissão adiada, sistema externo não simulado e efeito sem inverso. Uma tela verde é apoio à decisão, não certificado do futuro.

A cadeia de recibos

Para cada grupo, preserve a intenção imutável e a versão de contexto; o modelo canônico usado pelo Handler; decisões de autorização; leituras de precondição com horário; mensagens exatas; sequência de respostas, erros e timeouts; objetos compensatórios exatos; suas próprias verificações; bloqueios e escritas concorrentes; observações posteriores de configuração e estado operacional; efeitos externos residuais; e teste de serviço independente do Handler.

O resultado final deve separar “compensação tentada”, “estado modelado restaurado no escopo declarado” e “serviço recuperado”. Uma etapa não preenche a seguinte. O identificador correlaciona provas, mas não se torna a prova.

Fontes