Resumo

  • Um confirmed commit aceito já coloca candidate em running. O prazo de confirmação não segura a execução; ele mantém viva a obrigação do servidor de restaurar a configuração anterior.
  • No modo comum, a queda da sessão iniciadora provoca a restauração. Com persist, o procedimento sobrevive à sessão, e outra conexão que apresente o persist-id correspondente pode confirmá-lo, estendê-lo ou cancelá-lo.
  • Finalizar running não comprova autorização, isolamento de outros escritores, cópia para startup, aplicação em operational, entrega de pacotes nem consistência entre vários equipamentos.

O retorno <ok> veio antes da perda de acesso

Uma equipe altera a rota de gerenciamento de um roteador distante. A configuração é preparada em candidate, validada e enviada com <commit><confirmed/>. O servidor responde <ok>. A nova configuração entra em running. Logo depois, a sessão SSH cai e o endereço novo não responde.

O operador não consegue mandar uma ordem de volta. Ainda assim, no confirmed commit comum, o servidor tem uma instrução anterior e independente: se a sessão que iniciou o procedimento terminar antes da confirmação, restaure o estado que existia antes. A mesma restauração deve ocorrer quando o prazo expira ou quando o equipamento reinicia antes da conclusão.

Esse mecanismo trata um risco preciso. Uma mudança remota pode destruir o caminho pelo qual seria corrigida. O servidor mantém a capacidade de desfazê-la sem depender desse caminho. Mas ele não mantém o contexto completo do negócio. Não sabe se a mudança foi aprovada pela pessoa certa, se outro sistema escreveu depois, se o hardware voltou ao estado anterior ou se o tráfego se recuperou.

Por isso, a frase correta após <ok> é aparentemente contraditória: a mudança já estava em execução, mas ainda não tinha conquistado o direito de permanecer.

A confirmação não fica na frente do commit

O RFC 6241 define candidate como um datastore em que o cliente pode compor uma configuração completa sem modificar imediatamente running. <commit> estabelece running a partir de candidate. A capacidade :confirmed-commit:1.1, dependente de :candidate, acrescenta uma regra de finalização depois dessa transição.

Quando confirm-timeout não é informado, o valor padrão é 600 segundos. Um commit posterior confirma e encerra a obrigação de reverter. Outro commit confirmado pode estender o procedimento com um novo prazo aplicável. <cancel-commit> manda restaurar a configuração anterior. O timeout faz o mesmo.

Há, portanto, uma sequência que precisa sobreviver nos registros:

  1. o candidate foi montado e validado;
  2. o servidor aceitou o confirmed commit;
  3. running passou a refletir o candidate;
  4. o procedimento foi estendido, confirmado, cancelado ou expirou;
  5. running terminou em uma configuração específica;
  6. startup e o estado operacional seguiram — ou não — esse resultado.

O RFC 6470 dá nomes observáveis a parte dessa história: start, extend, complete, cancel e timeout. As notificações são úteis para separar fases, mas não produzem a decisão. Um coletor pode perdê-las, e um evento complete pode chegar antes de o dataplane convergir. A correlação precisa juntar RPC, usuário, sessão, fingerprints de candidate e da base, prazo, notificações e estado posterior.

Quem escolhe o prazo escolhe uma parte do risco

Dez minutos não têm o mesmo significado em todos os ambientes. Uma alteração pequena de filtro pode ser observável em segundos. A reprogramação de hardware ou a reconvergência de uma rede grande pode produzir sintomas lentamente. Um prazo curto reduz a exposição a um estado ruim, mas talvez reverta antes de os testes terminarem. Um prazo longo dá tempo à observação e também a falhas e edições concorrentes.

É necessário declarar o conjunto de evidências que cabe na janela. A conexão de gerenciamento retornou? As adjacências estabilizaram? A rota foi escolhida e instalada? Pacotes reais atravessaram os dois sentidos? O serviço respondeu por um caminho independente? Sem essa lista, estender o relógio apenas adia uma decisão sem torná-la melhor.

Também há vários relógios. O cliente registra o envio, o servidor inicia sua regra quando aceita o RPC e o controlador observa a resposta depois. Numa mudança de dez equipamentos, os procedimentos começam em momentos distintos. Uma tela com um contador único inventa uma finalização comum que o protocolo não criou.

O prazo deve ser tratado como um objeto de autoridade: quem pode defini-lo, estendê-lo, quantas extensões cabem e qual ausência de evidência exige cancelamento.

O token persistente não é um segundo aprovador

No modo não persistente, o confirmed commit pertence à sessão que o iniciou. Se essa sessão acaba, ocorre rollback. A dependência é intencional: perder contato antes de provar o resultado é motivo para voltar.

O modo persistente atende outra necessidade. O iniciador envia um valor opaco em persist. O procedimento deixa de depender da vida daquela sessão. Outra sessão pode apresentar o mesmo valor como persist-id para executar a operação apropriada de confirmação, extensão ou cancelamento.

É uma transferência de continuidade, não uma afirmação de identidade. O servidor não descobre se o portador é outra pessoa, se houve dupla aprovação ou se o trabalho foi revisado. Um mesmo serviço pode abrir duas sessões e confirmar a si próprio. Separação organizacional só existe quando identidades, credenciais, regras NACM e atribuições de tarefa também estão separadas.

A custódia do token precisa resistir a duas falhas opostas. Se apenas o processo iniciador o conhece, a morte do processo pode deixar uma configuração persistente sem responsável. Se o valor bruto aparece em logs amplos, o material de auditoria vira capacidade operacional. Uma impressão digital protegida serve para correlacionar eventos; o valor reutilizável deve permanecer em um cofre e fluxo de autorização próprios.

Sessão válida, token correspondente e usuário autorizado são três verificações, não três nomes para a mesma coisa.

Rollback pode apagar uma mudança que não causou o problema

É confortável imaginar que o servidor conhece o patch inverso da mudança. A garantia de confirmed commit é a restauração de uma configuração anterior. O RFC 6241 alerta que alterações feitas depois do commit provisório podem ser modificadas ou removidas quando a restauração acontece.

Considere A, que muda uma política sob uma janela de cinco minutos. Dois minutos depois, B atualiza telemetria. A perde a sessão. Para a organização, B talvez seja um trabalho independente. Para o servidor, há uma base anterior a A que precisa ser restaurada. Sem semântica de merge comprovada, B pode sair junto.

Locks ajudam a delimitar a autoria. O lock global do NETCONF impede outras sessões de escrever no datastore coberto. O RFC 5717 permite lock parcial, mas obriga o servidor a negá-lo em running quando um confirmed commit está aberto: o mecanismo pode precisar restaurar uma área mais ampla.

Um lock prova exclusão apenas dentro de sua cobertura real e para os caminhos que o respeitam. Não prova que a configuração é correta, que uma API paralela usa o mesmo lock ou que o estado físico voltará. A evidência deve registrar escopo, proprietário, aquisição, liberação, conflitos, escritores concorrentes e fingerprints antes e depois da recuperação.

Uma edição RESTCONF pode confirmar o trabalho NETCONF

Em um servidor colocalizado, a fronteira entre protocolos pode não ser uma fronteira entre estados. O RFC 8040 modela RESTCONF sobre datastores conceituais compartilhados com NETCONF. Quando candidate é usado, uma edição RESTCONF faz commit automático do candidate resultante.

Se houver um confirmed commit NETCONF não persistente em aberto, esse novo commit funciona como confirmação. Um cliente RESTCONF pode fechar a janela de rollback de outra equipe sem enviar uma chamada chamada “confirmar”. A autoridade nasce da superfície compartilhada, não do nome da API.

O caso persistente é diferente. RESTCONF não oferece um campo persist-id. Se o procedimento em aberto exige o token, a edição deve falhar com HTTP 409 in-use. Um lock NETCONF também pode gerar esse status. Esses 409 precisam ser ligados ao confirmed commit ou lock correspondente; tratá-los como ruído esconde uma disputa real de controle.

Há ainda a persistência de reboot. Se o servidor colocalizado suporta startup, o RFC 8040 exige que uma edição RESTCONF bem-sucedida o atualize automaticamente. O commit NETCONF para running não comprova a mesma cópia. Saber qual caminho escreveu é parte do resultado.

Identidade SSH, autorização NACM e validade YANG

O transporte do RFC 6242 protege NETCONF sobre SSH e autentica as pontas segundo a política instalada. Isso não decide se o usuário pode chamar <commit> ou editar cada nó alcançado.

O NACM do RFC 8341 separa acesso a operações, a nós de dados e a notificações. Uma sessão autenticada pode ter a operação negada. Uma operação permitida pode encontrar dados proibidos. Sessões de recuperação podem receber exceções específicas da implementação, concentrando autoridade adicional. O log precisa manter cada decisão em sua camada.

Depois vem a validade do modelo. O RFC 7950 define YANG 1.1, seus tipos, estruturas e restrições. Um endereço pode ser válido pelo schema e pertencer ao local errado. Uma política pode satisfazer todas as referências e interromper o serviço. Validar significa que o candidate respeita o contrato declarado, não que expressa a intenção correta.

O contrato exato também muda. O RFC 8525 expõe módulos, features, deviations, associações de schema e um content-id específico do servidor. Se essa biblioteca muda entre preparação e commit, a interpretação do mesmo texto pode mudar. A prova de validação precisa carregar esse estado.

Running, intended e operational não são sinônimos

O NMDA do RFC 8342 separa o que foi configurado do que o sistema tenta aplicar e do que usa de fato. Running guarda a configuração completa atual. Transformações produzem intended. Operational reúne configuração e estado efetivamente utilizados no momento observado.

Uma configuração para um recurso ausente pode permanecer em running e intended sem aparecer aplicada em operational. Limites físicos, dependências internas, trabalho assíncrono e outros protocolos podem atrasar ou alterar a aplicação. O confirmed commit pode estar complete enquanto a realidade do equipamento continua divergente.

O canário deve corresponder ao mecanismo. Interface exige estado efetivo e pacotes. Política de roteamento exige adjacências, rotas candidatas, seleção, instalação e forwarding. Endereço de gestão exige teste do caminho novo e preservação de um caminho de recuperação. Comparar texto de configuração é uma prova de datastore, não de rede.

Ticket aprovado, canal autenticado, RPC autorizado, candidate válido, running final, intended produzido, operational aplicado e serviço funcional formam camadas sucessivas. Cada uma pode ser verdadeira com a próxima ainda falsa.

Dez servidores continuam sendo dez decisões

O RFC 6244 posiciona NETCONF e YANG numa arquitetura maior de gestão. Um controlador pode montar uma mudança de rede usando confirmed commits, mas cada servidor conserva sua base, relógio, capacidades, locks e processo de aplicação.

As chamadas não começam juntas. Um equipamento pode reiniciar, outro negar acesso, outro aceitar running e não aplicar um recurso. Se nove retornam <ok> e o décimo falha, existe estado parcial. Confirmar os nove torna a parcialidade final. Cancelá-los exige depois provar que operational e o tráfego voltaram, não apenas que os RPCs foram aceitos.

O nível distribuído pertence ao orquestrador: identidade comum, bases por dispositivo, ordem de início e confirmação, critérios de aborto, canários, compensação e reconciliação. Uma política gradual pode ser mais honesta que uma promessa impossível de atomicidade. O que não é honesto é chamar várias respostas verdes de um único ponto de commit.

A conclusão que o mecanismo realmente sustenta

Os nomes registrados pela IANA permitem que implementações independentes descubram candidate, confirmed commit, startup, validate e outras capacidades. O núcleo comum é deliberadamente estreito. Tempos, papéis, bloqueios, evidência e coordenação de rede continuam decisões locais.

Uma afirmação defensável diz: este usuário e sessão, sob este schema e esta política, colocaram este candidate em running a partir desta base; este prazo e esta regra de sessão ou token controlaram a finalização; o procedimento terminou neste evento; running e startup ficaram nestes estados; intended, operational, pacotes e serviços mostraram estes resultados; todos os dispositivos foram reconciliados.

Autoridade prática pertence a quem consegue executar os verbos: enviar o RPC, guardar o token, estender o tempo, confirmar, escrever startup e escolher quando a observação basta. Um fluxograma que nomeia aprovadores, sem ligar esses nomes aos controles em execução, pertence à camada simbólica.

Confirmed commit é valioso porque não pretende resolver tudo. Ele fornece um mecanismo preciso de execução provisória e restauração. A responsabilidade de não transformar essa precisão em uma falsa prova total permanece com quem opera a rede.

Fontes