Resumo

  • with-immutability pede ao servidor que inclua a anotação immutable ao ler <system>, <intended> ou <operational>. O mecanismo descreve um comportamento preexistente; não o cria.
  • A anotação pertence à instância, pode ser herdada de um nó pai e redefinida por um descendente. Um inventário achatado não preserva necessariamente o alcance da regra.
  • A resposta invalid-value comprova uma recusa delimitada. Consistência entre identidades e protocolos, permanência após mudanças, estado efetivo e recuperação continuam sendo testes separados.

Dois recibos parecem fechar o caso. No primeiro, uma consulta retorna immutable=true. No segundo, a tentativa de gravar outro valor recebe invalid-value. Eles confirmam que o servidor declarou uma restrição e classificou aquela edição como inválida. Não confirmam que os bytes nunca mudarão.

Essa distinção vem do próprio rascunho na revisão 14. O indicador é descritivo, não prescritivo. Ele documenta um tratamento que servidores YANG já aplicam a determinados dados de configuração fornecidos pelo sistema. O metadado ajuda o cliente a evitar uma solicitação destinada ao fracasso, sem legislar sobre a lógica interna do servidor.

O Datatracker registra o texto de 2 de julho de 2026 como Internet-Draft ativo do NETMOD, destinado ao Standards Track. Andamento editorial, revisões e validação do módulo são evidência sobre o documento. Não medem conformidade de produto, adoção ou resultado em produção.

A consulta delimita a resposta

A anotação não aparece por padrão. Em NETCONF, with-immutability amplia <get-data>; em RESTCONF, é um parâmetro GET sem valor. A consulta é válida apenas nos datastores de leitura <system>, <intended> e <operational>. Em outro datastore, o rascunho requer unknown-element. Um valor inesperado no parâmetro RESTCONF deve gerar HTTP 400 e invalid-value.

O anúncio de suporte é outro registro. O cliente NETCONF consulta YANG Library em busca de ietf-immutable-annotation; o RESTCONF procura a URI de capability. Esse anúncio comprova que o servidor declara entender a interface. Não comprova que marcou cada instância corretamente, aplicou a herança ou cobriu toda rota de escrita.

Servidores legados podem rejeitar ou simplesmente ignorar o parâmetro. Assim, ausência de anotações não significa automaticamente mutabilidade. Sem capability, requisição exata e datastore, o silêncio não tem interpretação única.

A árvore carrega a política

Duas entradas da mesma list podem ter estados diferentes. Um filho sem anotação herda o pai; um nó superior sem marca usa false. Um descendente pode redefinir o estado, e outro abaixo dele pode alterá-lo novamente.

Guardar apenas folhas true perde a origem herdada. Guardar apenas o pai perde exceções mutáveis. RFC 7952 ainda limita a anotação: entradas individuais de list e leaf-list podem recebê-la, mas a coleção inteira só fica immutable por herança.

Quando a list inteira herda imutabilidade, entradas não podem ser adicionadas, removidas ou reordenadas pelo usuário. Se apenas uma entrada é immutable, a regra protege essa entrada e seus descendentes, salvo redefinição, sem atingir todas as irmãs. O cliente pode copiar para running o mesmo valor fornecido pelo servidor e depois apagar a cópia sem mudar o valor merged em intended.

O servidor também deve ignorar anotações immutable enviadas pelo cliente. A marca é relato do servidor, não um bit de controle que o solicitante possa conceder a si mesmo. Assinatura da requisição prova origem dos bytes, não autoridade para criar a propriedade.

O primeiro controle pode ser de acesso

Os exemplos NETCONF e RESTCONF preservam caminho, tipo de erro, severidade e explicação. Isso torna o recibo auditável. Mesmo assim, a conclusão pertence à identidade, à operação, ao valor proposto e ao instante observados.

Com NACM, a autorização vem antes do teste de imutabilidade. Um usuário sem permissão recebe access-denied; o servidor pode não ter avaliado immutable. Respostas diferentes entre usuários não demonstram, por si, uma propriedade variável. Mostram que a ordem de decisão precisa ser reconstruída.

Uma via de administração também não cobre as demais. Uma recusa NETCONF não testa RESTCONF, console local, ferramenta do fornecedor, boot, upgrade ou processo interno. A independência de protocolo e usuário exigida pelo rascunho é uma condição de conformidade a ser verificada, não um certificado prévio.

Controle do servidor não é congelamento no tempo

O cliente não pode impor um valor diferente, mas o servidor continua controlando sua própria configuração. Versão de software, descoberta de hardware, licença, feature habilitada e recursos disponíveis podem mudar o que é fornecido ou considerado immutable.

A propriedade pode existir sem <system>, e nem toda configuração de sistema é immutable. O ponto aqui não é recontar a arquitetura completa de origem e merge, mas reconhecer que visibilidade em running e autoridade sobre o valor efetivo são coisas distintas.

RFC 8342 separa intended de operational. Uma leitura coordenada com o mesmo valor nos três datastores oferece uma fotografia forte daquele momento. Ela não comprova que uma atualização preservará o quadro, que o recurso continuará presente, que o dispositivo aplicou a intenção, que o tráfego passou ou que a recuperação funciona.

Transformar o selo em uma cadeia de oito provas

O registro útil inclui: consulta e datastore; capability e schema efetivo; subtree com marca explícita, herança e redefinições; edição autenticada e erro integral; vistas relevantes; evento de software, hardware, licença, feature ou recurso; telemetria e canário de serviço; recuperação executada e resultado.

O conjunto primário fechado reúne a revisão 14, registro e histórico do Datatracker, RFCs 7952, 7950, 8342, 8525, 8526, 8527, 6241, 8040, 8341 e 9907, além de system-configuration 20: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-immutable-flag-14; https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/; https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/history/; https://www.rfc-editor.org/rfc/rfc7952.html; https://www.rfc-editor.org/rfc/rfc7950.html; https://www.rfc-editor.org/rfc/rfc8342.html; https://www.rfc-editor.org/rfc/rfc8525.html; https://www.rfc-editor.org/rfc/rfc8526.html; https://www.rfc-editor.org/rfc/rfc8527.html; https://www.rfc-editor.org/rfc/rfc6241.html; https://www.rfc-editor.org/rfc/rfc8040.html; https://www.rfc-editor.org/rfc/rfc8341.html; https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-20; https://www.rfc-editor.org/rfc/rfc9907.html.

Essas fontes sustentam a semântica proposta, não conformidade de fornecedor, prevalência, incidente evitado, rollback ou resultado de cliente. A lista de implementações no apêndice é uma afirmação do rascunho, não um teste independente.