Resumo

  • draft-ietf-netmod-yang-schema-comparison-09 compara as instruções analisadas e a árvore de dados efetivamente compilada, classificando mudanças como editoriais, retrocompatíveis ou não retrocompatíveis.
  • O relatório orienta revisão, versionamento semântico e planejamento de conversão. Não comprova identidade dos insumos, migração sem perda, interoperabilidade, estabilidade do NACM, ordem segura de rollout ou convergência operacional.

Um diff bem produzido reduz milhares de linhas a uma decisão aparentemente simples. É tentador traduzir “nenhuma mudança incompatível” por “seguro para produção”. Essa tradução acrescenta fatos que o comparador não observou. Entre esquema e produção há conversores, clientes, servidores, controles de acesso, janelas de versões mistas e o comportamento efetivo da rede.

A revisão 09 foi publicada em 3 de julho de 2026. O Datatracker da IETF a mantém como Internet-Draft ativo do grupo NETMOD, não como RFC. O quadro atual de validação mostra zero erro e zero aviso. Esse é o estado do documento e da verificação documental, não um indicador de adoção ou sucesso em campo.

Comparar exige duas formas do esquema

O rascunho distingue parsed schema e compiled schema. A forma analisada permanece próxima da árvore de instruções carregada, antes de todas as referências e transformações serem resolvidas. A forma compilada incorpora imports e submódulos, resolve uses e typedef, aplica augment, deviation e refine e considera os if-feature habilitados para formar a árvore efetiva.

As duas visões cobrem riscos diferentes. Uma alteração em typedef pode repercutir em muitas folhas. Um augment externo pode inserir nós. Uma deviation do fornecedor pode remover restrições sem alterar o módulo-alvo. Só o texto não mostra todo o efeito; só a árvore compilada não mostra todas as mudanças de instrução relevantes para autores e importadores.

A revisão 09 emite primeiro mudanças nos nós compilados e depois compara as demais instruções analisadas, evitando duplicação. A identidade de compilação registra nome e revisão dos módulos antigo e novo, submódulos incluídos, features habilitadas e imports recursivos.

Portanto, um diff vazio pertence àquele conjunto exato. Trocar uma feature, revisão importada, deviation ou submódulo cria outra experiência. Hashes das fontes e identidade completa de compilação são parte do recibo, não detalhes opcionais.

A classe também tem procedência

Cada mudança vira ED, BC ou NBC. A editorial não muda o espaço de valores válidos nem invalida importadores. A retrocompatível pode ampliar esse espaço sem quebrar quem importa. A não retrocompatível reduz o espaço ou pode invalidar um importador.

O resultado nem sempre acompanha a intuição de “tipo maior”. A passagem de uint32 para uint64 amplia a faixa numérica, mas a representação JSON definida no RFC 7951 muda de número para string. Um cliente pode quebrar, logo a mudança pode ser NBC.

Alterações em pattern, when e must começam como NBC. description, reference e presence começam como editoriais; uma instância de extensão, como BC. O autor pode substituir esses padrões por marcadores persistentes ed-change-at, bc-change-at ou nbc-change-at, ligados à versão semântica.

A substituição expõe uma decisão humana e deve carregar justificativa. O revisor precisa distinguir regra fixa, classificação padrão e override. Assim o rótulo de versão se torna uma declaração responsável, sem fingir que mediu a produção.

Retrocompatibilidade não congela comportamento

Adicionar uma folha opcional pode ser BC e ainda afetar o sistema: o servidor passa a preenchê-la, o cliente a serializa, uma política a examina, a interface a exibe. Defaults alterados mudam comportamento efetivo mesmo sem mexer na configuração persistida. when, must, features e deviations deslocam caminhos de validação e a superfície real de cada equipamento.

O comparador não executa RPCs, não reaplica todas as configurações e não observa clientes. O RFC 8525 identifica módulos, features e deviations declarados no YANG Library. Seu content-id identifica essa biblioteca, mas não comprova que o servidor executa cada regra corretamente.

O RFC 8341 coloca o NACM em outra camada. Grupos, regras e defaults de negação podem mudar o que um principal vê e edita sem qualquer diff de esquema. A conclusão operacional requer testes por papel e identidade.

Conversão válida pode ser conversão com perda

O rascunho prevê que a saída ajude ferramentas a transformar dados de instância antigos. A ferramenta ainda decide o que remover, mapear, normalizar, preencher, sintetizar ou rejeitar. Validar o resultado no novo esquema prova conformidade estrutural, não conservação de significado.

O RFC 9195 oferece um modelo útil de identidade e procedência. O recibo de conversão deve ligar hash e esquema da instância antiga à versão e às regras do conversor. Deve contar nós descartados, sintetizados, normalizados e rejeitados, hashear a saída, validá-la contra o esquema compilado novo e registrar testes de ida e volta ou invariantes semânticos.

Se dois estados antigos viram um só estado novo, a informação se perdeu mesmo com validação verde. A aceitação cabe ao dono dos dados.

As próximas portas são executáveis

Depois vêm testes de implementação: parsers ou servidores independentes quando houver requisito de interoperabilidade, configurações e RPCs representativos, tags de erro, defaults, codificações canônicas, negociação de feature e todos os papéis NACM afetados. Binários, módulos, opções e vetores precisam ficar registrados.

Também é necessário ensaiar o rollout. Atualização gradual mistura cliente antigo com servidor novo, cliente novo com servidor antigo e pares com features ou deviations divergentes. O diff não determina quem sobe primeiro, não garante telemetria contínua e não demonstra que a versão anterior consegue ler dados escritos pela nova para realizar rollback.

Por fim, o RFC 8342 separa running, intended e operational porque configuração, intenção aplicada e estado observado não são iguais. Apenas a implantação revela convergência, alarmes, desempenho e efeito externo.

A revisão 09 fortalece a governança ao produzir um recibo de esquema reproduzível. Mantê-lo como primeiro elo, sem promovê-lo ao resultado final, é o que preserva essa força.

Fontes

Fontes primárias: YANG Schema Comparison, revisão 09; registro no Datatracker; YANG 1.1, RFC 7950; YANG Library, RFC 8525; NMDA, RFC 8342; NACM, RFC 8341; YANG Instance Data, RFC 9195; YANG Semantic Versioning, revisão 28; YANG Module Versioning, revisão 16. Cronologia: histórico do Datatracker.