Resumo

  • A marca descreve configuração fornecida pelo sistema que não pode ser alterada pelo cliente na interface normal; não impede mudanças realizadas pelo próprio servidor.
  • O resultado pode vir de anotação explícita, herança de um ancestral ou padrão do nível superior, exigindo contexto além do booleano.
  • Um recibo local deve unir a consulta, o instantâneo, a origem da herança, a autoridade do servidor e a causa real de uma tentativa de edição rejeitada.

A pergunta escondida na palavra

Imutável costuma significar que algo não se modifica com o passar do tempo. No draft-ietf-netmod-immutable-flag-14, o termo responde a outra pergunta. Um nó verdadeiro representa configuração de sistema que o servidor não deixará o cliente substituir por valor diferente em um datastore gravável ou retirar da configuração intended.

Essa distinção resolve um limite do modelo. Uma entrada criada pelo sistema pode precisar continuar como config true para que o cliente configure filhos, para que restrições YANG façam referência a ela ou para que entradas obrigatórias convivam com entradas criadas por usuários. Escrever a exceção apenas em description produz texto para uma pessoa, mas não uma capacidade que a automação descubra antes de enviar uma edição.

O rascunho define a anotação como descritiva, não prescritiva. Ele também afirma que configuração imutável do sistema só pode ser criada, atualizada e removida pelo servidor. Logo, o cliente não pode mudar o valor por sua interface, enquanto o servidor pode apresentar outro valor em outro momento. Não há contradição; há sujeitos diferentes.

Um painel que exibe “não muda” apaga o sujeito. A formulação comprovável é “este cliente não podia mudá-lo por esta via quando recebeu esta resposta”.

A observação começa na capacidade

A anotação não aparece automaticamente. O cliente pede with-immutability ao ler system, intended ou operational. Usar o parâmetro em outro datastore gera erro segundo a proposta. NETCONF descobre suporte pelo módulo ietf-immutable-annotation na biblioteca YANG. RESTCONF usa um identificador de capacidade próprio.

Esse percurso deve acompanhar o resultado. É preciso saber qual servidor anunciou suporte, qual datastore e subárvore foram consultados, qual identidade podia ler o nó e em que instante a resposta chegou. Um verdadeiro isolado não demonstra que a consulta foi válida nem que descreve a mesma versão do servidor examinada mais tarde.

Em ambientes mistos, ausência é ainda mais ambígua. Cliente antigo não pede e não recebe. Cliente novo diante de servidor antigo pode receber erro ou ter o parâmetro ignorado. O servidor também pode omitir uma anotação herdada ou equivalente ao padrão. Sem a descoberta de capacidade e a requisição original, ausência não prova mutabilidade.

O estado resolvido tem uma árvore atrás dele

Se um filho não traz anotação, herda o estado do pai. No nível superior, a omissão significa falso. Descendentes podem reiniciar o estado e alterar o resultado de suas próprias subárvores, sem limite para o número de transições espalhadas pela árvore.

Essa compressão é eficiente no protocolo, mas o registro de auditoria deve descompactá-la. Para cada resultado convém guardar se ele era explícito, herdado ou padrão, o ancestral que o definiu e qualquer reinício intermediário. Caso contrário, duas respostas verdadeiras de origens distintas parecem equivalentes e não se sabe o que será afetado quando um pai mudar.

Listas tornam o cuidado mais concreto. Metadados se ligam a instâncias, e duas entradas da mesma lista podem ter estados diferentes. Pelas restrições de RFC 7952, o comportamento da lista inteira pode chegar por herança, enquanto uma entrada redefine o seu ramo. Adicionar, retirar, modificar e reordenar não são sempre a mesma operação para fins de imutabilidade.

O recibo precisa da rota da instância, tipo do nó, módulo e revisão YANG, anotação explícita, resultado resolvido e fonte da herança. O booleano é uma conclusão calculada; a prova deve conservar as premissas.

Repetir o valor em running não muda a origem

O cliente pode escrever em running o mesmo valor fornecido pelo sistema e depois remover essa entrada. Nenhuma das ações altera o valor em intended. A visibilidade no datastore gravável muda, mas a autoridade continua no servidor.

Um histórico limitado a running pode atribuir ao cliente a “criação” do nó, embora ele não tenha originado a configuração efetiva. No sentido contrário, um nó imutável do sistema talvez não apareça em running antes de ser repetido explicitamente. Inventário que ignora intended corre o risco de omitir a configuração que realmente governa o equipamento.

Procedência temporal exige dois eventos: o ato do cliente e a decisão do servidor. A plataforma pode saber que o valor veio de detecção de hardware, perfil de inicialização ou política do produto. A anotação não carrega essa resposta. Se a fonte não estiver disponível, “origem do servidor desconhecida” é melhor do que uma inferência apresentada como fato.

A autorização é julgada antes

Quando NACM está presente, o acesso é avaliado antes da imutabilidade. Uma identidade sem permissão recebe acesso negado; o servidor não precisa revelar primeiro que o nó também seria imutável. Isso protege informação e define a ordem correta da análise.

Nem toda edição recusada é sucesso da política imutável. O registro deve conter identidade autenticada, operação, rota, decisão NACM, eventual teste de imutabilidade e o error-tag retornado. Uma métrica que mistura permissão, validação e imutabilidade não ajuda a corrigir a automação.

A própria distribuição das marcas pode revelar quais partes da configuração são rígidas. O texto reconhece que esse conhecimento pode servir de pista para um ataque. Só clientes com direito de leitura do nó devem recebê-lo, e transporte seguro e autenticação mútua continuam essenciais. Uma exportação analítica não deve perder o contexto dessa autorização.

Um recibo temporal ao lado do padrão

O padrão pode continuar pequeno. O recibo operacional identifica servidor ou elemento lógico, versão, datastore, revisão do módulo, descoberta de capacidade e protocolo. Guarda subárvore, rota, valor, estado resolvido e fonte explícita ou herdada. Acrescenta horário e, quando houver, versão, ID ou digest do instantâneo.

Depois vêm os fatos locais comprováveis: origem da configuração de sistema, autoridade decisória, última mudança do servidor e motivo. Campos desconhecidos permanecem desconhecidos. Uma edição tentada adiciona papel, intenção, decisão NACM, resultado de imutabilidade e erro.

Por fim, o recibo recebe uma data de nova observação. Assim, “observado como imutável” não se converte em “certificado para sempre”. Uma mudança posterior do servidor cria outro recibo e preserva o anterior. A sequência mostra o tempo sem negar o limite que existia para o cliente.

Não se propõe carregar toda essa história no booleano YANG. Misturar identidades e workflow local na anotação prejudicaria a interoperabilidade. A governança deve manter a fronteira comum no padrão e juntar a ela apenas os fatos que a operação realmente observa.

Adoção é um percurso, não um selo

Na data de pesquisa, a revisão 14 havia sido aprovada pelo IESG e estava na fila do RFC Editor, embora ainda fosse um Internet-Draft ativo. A validação YANG mostrava zero erros e avisos. Isso não estabelece implementação em qualquer frota.

Servidores com e sem capacidade coexistirão com clientes que pedem ou não a anotação. Combinações novas e antigas podem rejeitar ou ignorar o parâmetro. Estados herdados podem não aparecer explicitamente. Tratar tudo como uma taxa única de suporte apaga essas combinações.

A unidade útil de acompanhamento é o caminho completo: capacidade descoberta, requisição válida, resposta recebida, estado resolvido e, se houve edição, resultado classificado depois do acesso. O ponto onde o caminho para indica se falta atualização, política ou observabilidade.

Fontes