Resumo

  • RFC 10016 acrescenta o datastore <system>, somente leitura para clientes de gerenciamento, que expõe configuração fornecida pelo dispositivo. Software, licença e recursos físicos ainda podem mudar seu conteúdo.
  • Um nó autorizado em <running> prevalece sobre o valor correspondente do sistema. Ao remover essa sobrescrita, o valor do sistema pode reaparecer em <intended>; ao remover o recurso, a intenção do cliente pode ficar armazenada sem chegar a <operational>.
  • A norma fixa a ordem de transformação, mesclagem e validação, mas não comprova aplicação, cobertura completa de notificações nem a resposta segura a uma árvore cliente invalidada por mudanças do sistema.

Um sucesso administrativo sem efeito operacional

O controlador mostra que a política foi enviada, aceita e preservada. Enquanto isso, a licença que fazia o dispositivo gerar a função correspondente foi desativada. O nó condicionado à licença desapareceu de <system>. A entrada do controlador ainda ocupa <running> e pode continuar na composição de <intended>. Nada garante que ela apareça em <operational>.

RFC 10016, publicado na trilha de padrões em julho de 2026, torna essa diferença explícita ao atualizar a arquitetura NMDA. <system> registra o que o equipamento fornece. <running> registra o que clientes declararam. <intended> é o alvo depois das transformações, da mesclagem e da validação. <operational> mostra o que efetivamente está em uso.

O controlador não mentiu sobre seu commit; apenas respondeu a uma pergunta menor. A falha de governança aparece quando sua resposta é usada para declarar que a função está ativa.

Somente leitura para o cliente, mutável para o sistema

Edições NETCONF ou RESTCONF direcionadas diretamente a <system> devem ser negadas. Isso protege a origem do valor, mas não o congela. O dispositivo pode criar configuração sempre presente e configuração que depende de placa, licença ou funcionalidade. Retirada de hardware, expiração de licença e upgrade de software podem mudar essa árvore.

<system> tampouco persiste entre reinicializações. Ele é regenerado pelo sistema atual. Já <factory-default>, de RFC 8808, deve persistir e pode inicializar datastores graváveis numa restauração de fábrica. Misturar os dois conceitos transforma reinicialização e reset em operações aparentemente equivalentes, embora mexam com autoridades diferentes.

Um servidor ainda pode permitir que o cliente escreva em <running> um valor correspondente a um nó de <system>. O cliente não altera a fonte do dispositivo; ele cria uma entrada que vence a mesclagem naquele ponto.

A exclusão que revela outro comando

Uma sobrescrita ativa em <running> tem precedência sobre o valor do sistema, mesmo se este for alterado mais tarde. Quando o cliente apaga a sobrescrita, o valor inicializado pelo sistema reaparece em <intended> e pode entrar em uso se for aplicado com sucesso.

Portanto, excluir não significa deixar vazio. Significa retirar a prioridade do cliente e expor a fonte que permaneceu embaixo. O pedido de mudança deve mostrar o valor removido e o valor do sistema que assumirá o resultado. Sem essa dupla leitura, a aprovação não cobre o efeito real.

O desaparecimento de um recurso opera na direção oposta. A placa sai e o nó condicionado some de <system>, mas o endereço e a descrição preparados pelo cliente continuam. Se a placa voltar, essa intenção dormente pode se tornar executável. O momento de revisar a configuração é antes da reinserção ou renovação, não depois que o tráfego começar.

Transformar separadamente antes de decidir precedência

Quando há expansão de templates, remoção de configuração inativa ou transformação semelhante, RFC 10016 exige que <system> e <running> sejam tratados de forma independente. Só depois ocorre a mesclagem; onde a sobrescrita é permitida, o nó de <running> vence. Qualquer mudança em <system> exige atualização e validação imediata de <intended>.

A norma diz que <running> deveria continuar válido após uma mudança do sistema, mas deixa o mecanismo fora de escopo. Se um upgrade remove um alvo referenciado ou uma licença muda uma restrição, ainda cabe ao operador decidir se interrompe, corrige, isola ou reverte.

RFC 8342 mantém a distinção final: <intended> é o que o sistema tenta aplicar. Recursos ausentes e atrasos locais podem impedir que o alvo apareça em <operational>. Validação é necessária; observação da aplicação continua indispensável.

Uma superfície nova para leitura e sombra

O datastore padroniza a descoberta da configuração do sistema. Clientes NMDA antigos seguem funcionando, mas precisam ser atualizados para usar plenamente a nova origem e entender sua prioridade.

O conteúdo pode revelar identificadores de hardware, políticas de segurança e recursos críticos. RFC 10016 exige controle de leitura e recomenda fortemente auditoria das tentativas. NACM, definido em RFC 8341, fornece a estrutura, mas identidades e permissões são configuração operacional.

Há também risco de sombra: um valor errado ou hostil em <running> pode ocultar um nó sensível de <system>, causando desvio de política ou indisponibilidade. A fonte ser somente leitura não torna seguro o resultado que outra fonte pode sobrepor.

Assinaturas e notificações de RFC 8639 e RFC 8641 podem transportar mudanças. Suporte on-change, porém, pode variar entre objetos e implementações. O receptor precisa provar cobertura, continuidade e ressincronização; silêncio não comprova estabilidade.

A primazia do código em execução de Heng Lu oferece o critério de fechamento: o modelo descreve a regra, o controlador descreve a intenção e o estado operacional descreve o efeito. Seu desenho de especificação inicial mínima e decisão futura localizada preserva uma mesclagem comum e verificável sem tirar dos participantes a decisão sobre sobrescritas, implantação e rollback.