Resumo

  • O RFC 10016 acrescenta à NMDA o datastore <system>, somente leitura, para a configuração fornecida pelo sistema e não apagável por clientes. Ainda assim, eles podem referenciar seus nós, sobrepor valores permitidos em <running> ou adicionar descendentes configuráveis sob entradas criadas pelo sistema.
  • origin=system informa de onde veio o valor, não quem o aprovou, se permanecerá igual ou se foi aplicado. Ao remover uma sobreposição, o valor do sistema pode reaparecer em <intended>; mudanças de hardware, licença, recurso ou software também podem alterar os nós existentes.

A solicitação dizia “remover configuração explícita”. O revisor interpretou a mudança como redução: depois dela, não haveria escolha local. No equipamento, porém, a exclusão retirou apenas a camada superior. O valor do sistema que ela escondia voltou a vencer a combinação e apareceu em <intended>.

Esse resultado não é uma exceção obscura. É a consequência da precedência que o RFC 10016 torna observável ao introduzir <system> como datastore convencional. Clientes NETCONF e RESTCONF só podem lê-lo, mas seu conteúdo continua sendo uma das entradas que formam a configuração efetiva.

O erro de governança é transformar uma limitação de escrita em promessa de estabilidade. “Somente leitura” delimita a ação do cliente sobre aquele datastore. Não congela o que o servidor produzirá depois de um boot, uma troca de placa, uma licença ou uma atualização. Também não garante que o valor ganhou a combinação, foi aceito por alguém ou alcançou <operational>.

Dar endereço a uma origem antes implícita

A NMDA de RFC 8342 já separa a configuração pretendida da configuração e do estado realmente usados. Também reconhece origens convencional, dinâmica, aprendida, de sistema e padrão. O RFC 10016 passa a tratar como system configuration tudo o que está em <system>, seja ou não referenciado e aplicado naquele momento.

Essa configuração não pode ser excluída pelo cliente. Um dado entregue pelo servidor, mas apagável por quem o administra, não entra na definição. A implementação compatível oferece a identidade ietf-system-datastore, apoiada nos modelos YANG de RFC 7950. O cliente descobre a capacidade pelas informações de YANG Library descritas em RFC 8525.

Há dois ciclos de vida relevantes. A configuração sempre presente nasce quando o dispositivo liga, independentemente de um recurso físico específico; uma interface de loopback é o exemplo do RFC. A configuração condicionalmente presente depende de placa, recurso, licença ou funcionalidade. Quando a condição some, o nó também pode desaparecer.

O próprio <system> não persiste por reinicializações. O servidor reconstrói o conteúdo conforme o ambiente atual. Uma captura feita antes de reiniciar não prova que os mesmos insumos existiram depois. Preservar apenas <running> também não preserva tudo o que produzirá o próximo <intended>.

O cliente não escreve na fonte, mas muda o vencedor

Em <running>, um cliente pode referenciar nós de <system>. Quando o servidor autoriza, uma folha correspondente sobrepõe o valor do sistema. Também pode haver permissão para criar descendentes configuráveis abaixo de uma entrada de lista cuja identidade foi fornecida pelo sistema.

A regra de precedência é direta: o nó de <running> vence o correspondente de <system> na formação de <intended>. Se houver transformações, como expansão de template ou remoção de configuração inativa, cada datastore deve ser transformado separadamente antes da combinação. Uma comparação dos dados brutos pode apontar o candidato errado.

Considere A no sistema e B em <running>. Enquanto B existe, ele prevalece. Ao excluir B, o cliente não remove A — isso lhe é vedado. A retorna a <intended> e pode ser aplicado. Por isso, a remoção da sobreposição seleciona um fallback e merece a mesma atenção de uma escrita, mesmo que o formulário mostre um sinal de menos.

O sentido contrário também importa. Uma alteração de hardware ou licença pode eliminar um nó condicional do sistema. As referências podem permanecer em <running> e <intended>, mas faltar em <operational> porque o recurso desapareceu. A árvore de intenção ainda é visível; sua condição material deixou de existir.

Origem descreve procedência, não consentimento

O RFC 7952 define o mecanismo de metadados usado para anotações, entre elas a origem. O RFC 10016 esclarece que a configuração vinda de <system> apresenta origem system, exceto quando foi explicitamente configurada ou sobreposta em <running>. O conteúdo que nasce em <running> segue as regras de origem da NMDA.

Essa anotação responde “qual fonte forneceu este nó?”. Não responde “qual pessoa aceitou o efeito?”. O fornecedor real pode ser a imagem de plataforma, o mecanismo de licenciamento, o gerenciador de recursos ou um processo local. Nenhum deles representa necessariamente uma decisão humana atual. Da mesma forma, uma escrita em <running> pode ter sido produzida por um controlador automático.

Tratar system origin como selo de confiança converte escolha do produto em política da organização. Tratar running origin como vontade do operador converte automação em consentimento. Procedência é indispensável, mas precisa ser ligada à autoridade de mudança, à revisão da política e ao proprietário do risco.

A intenção validada ainda pode não estar aplicada

Toda mudança em <system> exige, segundo o RFC 10016, atualização e validação imediatas de <intended>. O texto também afirma que <running> deve continuar sendo uma árvore válida depois de alterações do sistema, embora não determine o mecanismo. São garantias sobre processamento dos dados; não são comprovação de que um valor chegou ao hardware.

O RFC não muda <operational>. Sob RFC 8342, ausência de recursos, atraso de propagação, falha e estado remanescente podem separar intenção e realidade. A cadeia completa transforma <system> e <running> de modo independente, combina ambos em <intended> e só então aplica o resultado, conforme as condições, em <operational>. Cada transição tem evidência e falha próprias.

Mudanças podem gerar notificações através das assinaturas YANG e atualizações de datastore previstas por RFC 8639 e RFC 8641. Um evento publicado prova que o emissor o produziu dentro da cobertura contratada. Não prova que todos os consumidores receberam, recalcularam políticas ou verificaram o novo estado operacional.

<system> também não é sinônimo de <factory-default>. O RFC 8808 define um datastore de padrões de fábrica e uma operação de restauração. <system> descreve o que o sistema oferece nas condições correntes. Os valores podem se parecer, mas os papéis e os momentos são outros.

Um recibo de origem e precedência

Um recibo de origem e precedência tornaria cada ajuste relevante auditável. Ele começaria pelo caminho do nó, fingerprint do valor, origem e condição de presença. A condição nomearia a época de hardware, licença, função, boot e software, evitando que “valor de sistema” seja entendido como uma constante sem tempo.

Depois registraria mutabilidade e precedência: se a sobreposição é permitida, qual nó de <running> referencia ou encobre a fonte, quais descendentes foram acrescentados, quais transformações rodaram de cada lado e qual valor entrou em <intended>. Antes de apagar uma sobreposição, o fluxo mostraria o valor que será revelado.

A seção de ativação compararia <intended> com <operational>, incluindo horário, presença de recurso, atraso, falha, estado remanescente e a observação usada para dizer que o ajuste está em vigor. Uma referência válida pode mirar um recurso inativo; uma árvore válida pode descrever hardware ausente.

Por fim, a autoridade seria dividida entre fornecedor do sistema, cliente de configuração, aprovador operacional e proprietário do risco. Atualização de software, transição de licença, inserção de hardware e commit de política seriam associados à decisão que aceitou o resultado. Segredos podem ficar protegidos, sem apagar hashes e referências delimitadas.

O recibo é uma proposta editorial de governança de Daniel Kade, não uma nova exigência do RFC 10016. Ele existe para manter separados fonte visível, valor vencedor, decisão aprovada e resultado aplicado.

Segurança começa pelo direito de ler

Somente leitura não significa inofensivo. O RFC 10016 alerta que <system> pode revelar identificadores de hardware, políticas de segurança e recursos críticos. O acesso a nós e subárvores sensíveis precisa ser controlado, e tentativas de leitura devem ser registradas. O RFC 8341 fornece o NACM para restringir usuários NETCONF e RESTCONF.

A sobreposição cria outro risco. Um invasor ou cliente defeituoso pode gravar em <running> uma folha que esconda um valor de segurança fornecido pelo sistema, causando desvio de política ou indisponibilidade sem tocar em <system>. Monitorar apenas escritas no datastore somente leitura significaria vigiar o caminho que o cliente já não pode percorrer.

O ganho do RFC 10016 é concreto: a configuração do sistema se torna inspecionável por um método comum. Isso não transforma a escolha da máquina em intenção do operador, não a torna permanente nem prova aplicação. Visibilidade inicia a governança; precedência e operação completam a evidência.

Fontes