Resumo

  • O RFC 9890 restringe a unicidade ao nome inicial de módulos e submódulos YANG e ao namespace XML do módulo inicial. Revisões posteriores devem conservar esses identificadores, como a prática da IANA já fazia.
  • A identidade estável prova uma linhagem editorial, não uma versão exata. Uma decisão reproduzível depende da revisão, dos bytes da fonte, da YANG Library do servidor, de recursos, desvios, esquema, configuração e estado operacional.

O painel de mudança coloca duas capturas lado a lado. Antes e depois da atualização, o nome do módulo é idêntico. O namespace XML também. Uma regra superficial conclui que não houve alteração de esquema. O painel observou corretamente os rótulos e errou a natureza deles: foram feitos para permanecer. A revisão, os nós, as restrições, os recursos habilitados e os desvios do servidor poderiam ter mudado atrás da mesma identidade.

Esse é o problema pequeno e decisivo tratado pelo RFC 9890. Publicado na trilha de padrões em outubro de 2025, ele atualiza a orientação da IANA para o registro de nomes de módulos YANG. Não cria uma operação de rede, não altera mensagens YANG e não registra implantação real. Seu efeito é alinhar a regra escrita à prática existente de registrar módulos e suas revisões.

O RFC 6020 dizia que todos os nomes de módulos e submódulos no registro tinham de ser únicos, assim como todos os namespaces XML. Lida literalmente em cada linha histórica, a frase fazia uma revisão legítima parecer uma colisão. O RFC 9890 separa identidade inicial e continuidade: o primeiro nome e namespace precisam ser únicos; revisões do mesmo módulo conservam o nome e o namespace, e revisões de submódulos conservam o nome.

A repetição correta mantém a linhagem

Uma revisão só faz sentido se houver uma parte constante e uma parte variável. O nome responde qual é a linhagem. A data de revisão responde em que ponto da história se está. O arquivo mostra as definições. Um hash do arquivo permite confirmar que dois processos receberam os mesmos bytes.

O YANG 1.1, no RFC 7950, estrutura essa diferença. Declarações revision registram a história editorial, inclusive a revisão inicial. Um import com revision-date seleciona uma versão específica; sem essa indicação, fica indefinido de qual revisão vêm as definições. Revisões diferentes do mesmo módulo podem até ser importadas quando prefixos distintos separam as referências.

Logo, indexar ativos apenas pelo nome apaga uma coordenada necessária. O namespace também não é um digest do conteúdo. Em uma cadeia reprodutível, o registro mínimo inclui nome e revisão; o registro forte acrescenta origem, instante de obtenção, arquivo exato e hash criptográfico. Uma data editorial não garante, por si, que dois repositórios serviram bytes idênticos.

O registro YANG Parameters da IANA deixa a distinção visível. ietf-yang-types aparece em arquivos datados de 2010, 2013 e 2025. Não são três entidades disputando um nome. São revisões publicadas de uma mesma família. A IANA coordena essa história e suas referências, mas não observa o cache de um controlador ou a imagem carregada em um equipamento.

O RFC 9907 protege o outro lado da fronteira. Um nome já publicado não pode ser reutilizado por um módulo diferente, mesmo que o RFC original se torne Histórico. Alterar o nome cria um módulo novo. Quando o conteúdo publicado muda, acrescenta-se uma revisão posterior e preservam-se as declarações de revisões já publicadas. Nome estável e história íntegra são controles complementares.

O registro global não enxerga o servidor

Estar no registro prova coordenação pública, não implementação. A IANA não afirma que um pacote incluiu aquela revisão, que um um processo a carregou, que um recurso está ativo ou que uma configuração foi aceita. Para aproximar a evidência da execução, é preciso consultar a YANG Library definida no RFC 8525.

Um servidor pode declarar conjuntos de módulos, módulos implementados ou apenas importados, revisão, namespace, recursos habilitados, módulos de desvio, esquemas e datastores. Se um módulo é implementado em vários datastores do mesmo servidor, a revisão é a mesma; versões distintas podem coexistir como dependências somente de importação quando a data foi especificada.

Ainda assim, a YANG Library é uma declaração local. Pode divergir entre servidores e mudar em tempo de execução ou reinicialização. Seu content-id deve mudar quando a informação da Library muda, mas o padrão não exige que seja hash nem que conteúdo igual gere valor igual em servidores diferentes. É um sinal para invalidar cache, não uma impressão digital global.

Uma captura auditável une endpoint autenticado, identidade do servidor e horário ao content-id. Depois preserva module-set, schema, datastore, condição implementada ou import-only, revisão, namespace, recursos, desvios e localização da fonte. Para uma compilação controlada, guarda também o artefato recuperado e seu hash. Dizer apenas que o servidor “suporta o módulo” elimina justamente os dados que explicariam uma incompatibilidade futura.

O esquema efetivo ainda não é o efeito

O RFC 8342 define o esquema de um datastore como o conjunto combinado de nós dos módulos suportados, considerando recursos habilitados e desvios. Dois servidores podem compartilhar nome e revisão e, mesmo assim, oferecer esquemas efetivos diferentes.

Um nó disponível tampouco prova que uma configuração foi aplicada. <running> pode conter dados que ainda passarão por transformações. <intended> representa a configuração que o sistema tenta aplicar após essas transformações. <operational> reúne configuração aplicada e estado do sistema. Hardware, protocolos, outros dispositivos e tempo de propagação podem abrir diferenças entre essas camadas.

A cadeia correta mantém perguntas separadas. Qual identidade foi registrada? Qual revisão foi publicada? Quais bytes foram analisados? O que o servidor declara ter carregado? Quais recursos e desvios compõem o esquema? Quem autorizou a configuração? O que restou em <intended>? O que apareceu em <operational>? Qual resultado a rede mediu?

Nenhuma resposta herda a autoridade da anterior. Uma linha da IANA não atesta o servidor. A Library não autoriza configuração. A configuração não prova aplicação. O estado operacional não garante, isoladamente, o resultado comercial pretendido.

Um mínimo comum deixa a mudança perto das consequências

Preservar o nome reduz o custo de coordenação global. Autores e implementadores não precisam descobrir uma identidade nova a cada revisão. A decisão de adotar uma versão permanece, porém, com quem consegue observar seu impacto: autor do import, mantenedor de pacote, operador de frota e responsável pela automação.

Essa estrutura é compatível com o princípio de Heng Lu em Minimum Initial Specification and Localized Future Decision: o centro fixa apenas aquilo que precisa ser comum; decisões futuras são localizadas. O RFC 9890 fixa a identidade inicial e a continuidade da linhagem, não o calendário operacional.

Running Code as Primary Evidence recorda que uma norma correta não descreve automaticamente o processo em execução. Registro, fonte, pacote, Library e estado do datastore são evidências de proposições diferentes e precisam ser conectados.

Reality Layers and Symbolic Power ajuda a explicar a tentação do painel verde. Um símbolo familiar simplifica a coordenação, mas pode esconder relações ainda não provadas. O nome tem poder para preservar identidade; não tem poder para congelar conteúdo, implantação ou resultado.

Fontes