Resumo

  • A revisão 10 do rascunho de candidata privada cria um espaço de configuração por sessão NETCONF e atualiza esse espaço de forma atômica quando running mudou. Todo commit usa implicitamente revert-on-conflict, fazendo o conflito interromper a operação.
  • As outras opções distribuem perdas. prefer-candidate mantém o valor privado para uma futura substituição do valor em execução; prefer-running elimina a edição privada conflitante. Permissão NACM e anúncio de capacidade não registram por que a organização autorizou uma dessas perdas.
  • Um mandado de commit deve vincular base, conflitos, modo escolhido, valores perdidos, responsável, escopo aprovado, testes, confirmed commit e alvo de reversão. Trata-se de proposta de Daniel Kade, não de requisito do IETF.

Privacidade de trabalho não é prioridade de serviço

O candidate datastore da RFC 6241 permite montar uma configuração antes de ativá-la. Como o espaço é compartilhado, outra sessão pode alterá-lo. Um cliente corre o risco de confirmar uma edição que não criou e talvez nem tenha visto. Bloquear o datastore reduz a possibilidade, mas impede outros clientes de avançar. O bloqueio parcial da RFC 5717 tampouco garante que o commit contenha mudanças de um só autor, não resolve edições simultâneas na mesma árvore e depende de conhecimento sobre relações entre modelos.

O draft-ietf-netconf-privcand-10 enfrenta essa mistura. Publicado em 24 de agosto de 2026, é um Internet-Draft ativo do grupo NETCONF, em Working Group Last Call e destinado a Proposed Standard. Ainda não é RFC, mandato de implantação ou evidência de produto em operação.

No NETCONF, cliente e servidor negociam o modo privado para a sessão inteira. A primeira operação relevante copia running para uma candidata exclusiva. Outras sessões de configuração NETCONF não veem nem acessam suas edições. Ao encerrar ou perder a sessão, o servidor destrói a candidata e descarta mudanças não confirmadas.

O ganho é concreto: um cliente não deve mais levar o trabalho inacabado de outro ao ambiente ativo. A separação também permite preparação concorrente sem transformar um bloqueio global em rotina. Só que running continua mudando enquanto cada ramo privado existe. Quando o ramo volta a tocar a produção, autoria e precedência deixam de ser a mesma pergunta.

Uma candidata privada diz de quem é o rascunho. Não diz a quem pertence a decisão sobre o serviço.

Atualizar é testar a intenção contra um novo início

O update substitui a base antiga da candidata pelo running atual e reaplica as mudanças privadas. A operação é atômica: não deixa uma fusão parcial caso falhe.

O conceito de conflito considera a intenção possível do cliente. Durante o intervalo de preparação, running e candidata precisam ter alterado o mesmo nó, em circunstância na qual o novo ponto de partida poderia ter produzido outra ação. Valor, existência, ordem do usuário, presence container, leaf-list, leaf e metadado YANG podem contar. O servidor pode ampliar as verificações e utilizar identificadores de transação.

O estado in conflict é mantido por nó. O mecanismo interno de marcação fica fora do escopo, e a marca não sobe automaticamente para todos os ancestrais. O cliente deveria receber locais XPath e valores para reavaliar seu propósito.

Esse desenho é melhor do que uma comparação cega de texto, mas não lê a organização. O servidor não sabe se o valor de produção surgiu de uma contenção emergencial, se a candidata representa uma migração aprovada, se um leaf aparentemente local governa dependências de vários serviços, ou se a janela de uma automação expirou. Duas identidades corretamente autenticadas podem carregar mandatos legítimos e incompatíveis.

Detectar o conflito preserva a divergência; não cria competência para julgá-la.

Cada modo escolhe onde a perda ficará

revert-on-conflict é obrigatório e padrão. Qualquer conflito faz o update falhar sem executar merge. Todo commit dispara implicitamente esse modo, ainda que o servidor use outra preferência em atualizações automáticas. O cliente precisa editar, descartar ou chamar conscientemente um update com modo escolhido antes de tentar novamente. A parada abre o último espaço em que a perda pode ser autorizada antes de ocorrer.

prefer-candidate mantém os valores privados conflitantes e incorpora as demais mudanças de running. Um commit posterior sobrescreve os valores correspondentes em produção. Perde-se a intenção que entrou em running depois da criação do ramo.

prefer-running traz os valores conflitantes de produção para a candidata e apaga as edições privadas nesses pontos. O restante do ramo sobrevive, mas parte do projeto do autor deixa de existir.

Nenhum rótulo resolve legitimidade. Candidata não significa necessariamente mudança mais nova, mais revisada ou mais importante. Running não significa política futura: pode conter uma correção temporária. A posição no modelo de dados não confere hierarquia institucional.

O servidor também pode escolher um modo diferente para atualizações automáticas provocadas por alterações em running. Uma escolha fora do padrão deve ser anunciada, bem como o conjunto de modos quando nem todos são oferecidos. Isso permite descobrir o comportamento. Não registra quem autorizou a preferência, para quais serviços e durante qual período.

Surge então uma lacuna temporal. O commit final pode ocorrer sem conflito porque um update automático anterior já removeu uma das intenções. O log mostra corretamente quem ativou o resultado, mas não quem decidiu a regra que o construiu.

NETCONF e RESTCONF comprimem decisões de maneiras diferentes

Uma sessão NETCONF negocia a capacidade privada. Se o cliente pedir e o servidor não suportar, o pedido pode ser ignorado por compatibilidade ou a sessão pode ser encerrada; o rascunho recomenda o encerramento para implementações novas. A preferência configurada no cliente, portanto, não prova que houve isolamento.

RESTCONF não tem anúncio equivalente do lado cliente. Se o servidor anuncia private-candidate, uma escrita no recurso de dados usa candidata privada da requisição e faz commit automático. Assim clientes que desconhecem a extensão mantêm a expectativa de efeito imediato. Isso não cria um ramo duradouro e multioperação como a sessão NETCONF.

A diferença altera o lugar da aprovação. No NETCONF, a candidata pode atravessar mudanças em produção, na política NACM e na janela de manutenção. No RESTCONF, preparação e ativação ficam comprimidas em uma requisição. Não se pode copiar um controle “entre edição e commit” sem redesenhar o fluxo.

Acesso autorizado não é autorização para derrotar outra mudança

A RFC 8341 permite que NACM limite leitura, escrita e execução conforme usuário e conteúdo. O rascunho chama update de operação sensível e adverte que acesso não autorizado pode produzir alterações indesejadas. Autenticação mútua e transporte seguro são essenciais.

Mesmo assim, o conflito mais difícil costuma envolver dois atores autorizados. Uma conta de plataforma pode escrever na árvore de interfaces, mas ter mandato apenas para rotacionar endereço, não para reverter um isolamento de incidente. Um administrador com privilégios amplos talvez não possa afetar a dependência de outro serviço. A credencial de uma automação pode seguir válida depois do fim da janela aprovada.

O controle de acesso responde se o principal pode chamar uma operação sobre determinado conteúdo. A governança responde se este fluxo pode, agora, fazer este valor prevalecer sobre outra intenção válida. Tratar a primeira resposta como a segunda transforma credencial duradoura em delegação permanente.

A comparação é igualmente limitada. A extensão da RFC 9144 permite comparar candidata privada com running, ponto de criação ou último update quando os pontos de referência são suportados. A diferença fica clara, mas não a importância para o serviço, a cobertura das dependências ou a legitimidade do decisor.

O mandado de commit

Não é necessário inventar outro datastore. A escolha destrutiva precisa de um mandado de commit curto e perecível.

O registro fixa dispositivo, datastore, sessão ou requisição, principal autenticado e dono da automação. Inclui referências estáveis ao ponto de criação, ao último update e à revisão atual de running. Depois preserva o delta exato e todo o conjunto de conflitos informado pelo servidor, acrescido do contexto de serviço ou ancestral conhecido pela política local.

O mandado registra padrão anunciado, modos disponíveis, natureza automática ou explícita do update e opção aplicada. A perda é descrita diretamente: valores de running que prefer-candidate fará desaparecer; edições privadas apagadas por prefer-running; ou divergências ainda abertas sob revert-on-conflict e a próxima ação permitida.

A versão da política NACM prova a moldura de acesso, não a aprovação. Um responsável humano ou automatizado informa motivo, serviço, janela, limite de impacto e validade. Comparação, validação de configuração e testes representativos sustentam a escolha.

Por fim, o mandado fixa uso e prazo de confirmed commit, identificadores persistentes quando aplicáveis, sinais de saúde e estado exato de reversão. O fechamento grava o resultado e a impressão digital de running. Nova alteração, política diferente, observador ausente ou janela vencida invalida o mandado.

O instrumento é uma proposta de Daniel Kade. Não é RPC, nó YANG nem obrigação do IETF. Sua função é conservar a autoridade e a justificativa depois que sessão, candidata e marcas de conflito já não existirem.

Reversibilidade não absolve a escolha original

Confirmed commit é uma proteção valiosa. Se a sessão cair durante um commit confirmado com candidata privada, o rascunho mantém a reversão imediata de running e o descarte da proposta. Isso contém o risco de perder o canal de controle.

Mas conseguir voltar não prova que o primeiro vencedor tinha autoridade. Uma escolha fora do mandato pode ter excelente rollback. Uma ação emergencial legítima pode não ter reversão adequada; nesse caso, a falta deve impedir a execução, não apagar a pergunta de autoridade.

Também é preciso descrever discard-changes com exatidão. A candidata volta ao ponto de criação ou ao último update, o que for mais recente. Esse estado pode ser diferente do running atual. Descartar não significa necessariamente retornar à produção presente.

Isolamento guarda autoria. Detecção de conflito guarda desacordo. Rollback guarda uma saída. Só um mandado criado na decisão guarda por que uma intenção teve direito de prevalecer.

Fontes