Resumo

  • A RFC 6020 exigia unicidade para todos os nomes de módulos e submódulos YANG no registro e para todos os namespaces XML. A prática da IANA, porém, preservava nome e namespace quando um módulo ganhava uma revisão.
  • A RFC 9890, assinada por Andy Bierman, Mohamed Boucadair e Qin Wu, restringiu a unicidade à versão inicial e tornou obrigatória a continuidade de identidade nas revisões.
  • Nome igual não congela conteúdo. Data, arquivo, seleção de importação, validação, pacote e observação em produção continuam sendo comprovantes separados.

No retrato do registro da IANA em 1º de setembro de 2026, ietf-yang-types aparecia em três linhas. Uma apontava para a revisão de 2010, outra para 2013 e outra para 2025. O nome e o namespace XML eram os mesmos; os arquivos datados e as RFCs de referência eram diferentes.

A antiga redação da RFC 6020 fazia esse histórico parecer uma violação. Ela dizia que todos os nomes presentes no registro deveriam ser únicos. Mas a IANA não estava atribuindo a mesma identidade inicial a três módulos concorrentes. Estava registrando três estados editoriais de uma única linhagem.

Publicada em outubro de 2025, a RFC 9890 trouxe a regra escrita de volta ao objeto real que precisava ser protegido. A mudança parece administrativa, mas resolve uma pergunta decisiva: o que o registro deve impedir e o que ele deve manter?

A primeira atribuição e a revisão não são o mesmo evento

Um sistema de deduplicação enxerga duas strings iguais. Um sistema de governança precisa saber como elas chegaram ali. Em uma nova atribuição, a repetição é colisão. Em uma revisão autorizada, a repetição é continuidade.

A nova regra separa as duas etapas. Nomes das versões iniciais de módulos e submódulos devem ser únicos. Namespaces XML de módulos iniciais também. Toda revisão de módulo ou submódulo conserva o nome inicial. Toda revisão de módulo conserva o namespace XML inicial.

Assim, o registro impede que uma linhagem independente ocupe um identificador existente sem obrigar a linhagem legítima a mudar de identidade a cada edição. Unicidade e continuidade deixam de competir.

Um alerta de duplicidade só é útil quando carrega tipo de evento, data, documento de origem, nome e namespace. Sem essa estrutura, uma limpeza pode excluir a revisão correta ou, no sentido inverso, aceitar uma nova atribuição conflitante como se fosse continuidade.

Continuidade de identidade não é equivalência semântica

Depois da correção, surge outra tentação: tratar qualquer arquivo com o mesmo nome e namespace como substituto perfeito. A RFC 7950 mantém a diferença visível.

Em YANG 1.1, as declarações revision registram o histórico editorial. Cada uma recebe uma data, e cada alteração publicada deve acrescentar uma nova entrada à frente da sequência. O formato recomendado do arquivo combina o nome estável com @data-da-revisão.

O nome responde “a qual módulo isto pertence?”. A data responde “qual estado editorial foi escolhido?”. A continuidade da primeira resposta não elimina a variação da segunda.

Isso aparece nas importações. Se revision-date estiver presente, as definições vêm da revisão especificada; uma data inexistente é erro. Se estiver ausente, a RFC 7950 considera indefinido qual estado foi importado. Revisões diferentes do mesmo módulo podem até coexistir quando recebem prefixos distintos.

Portanto, o namespace não aprova uma atualização. Ele não informa qual arquivo um fornecedor entregou nem demonstra que um operador testou a mudança. Apenas mantém o endereço público da linhagem.

Um inventário precisa de duas dimensões

As três linhas de ietf-yang-types mantêm a identidade em um eixo e a revisão no outro. A entrada de 2010 cita a RFC 6021; a de 2013, a RFC 6991; a de 2025, a RFC 9911. O nome é estável, a autoridade editorial muda.

Guardar apenas o nome comprime três estados em um. Rebatizar cada estado como v1, v2 ou v3 fabrica nomes que a IANA nunca atribuiu. O registro interno deve manter a identidade canônica e, ao lado dela, a revisão exata.

Para uso operacional, acrescente hash do arquivo, URL, RFC, versão do pacote, versão do parser, grafo de importação, validação, lote de implantação e resultado observado. A data informa a escolha pretendida; o hash fixa os bytes; o manifesto identifica o que foi entregue; o teste diz o que foi aceito; a telemetria mostra o comportamento real.

Esses recibos localizam a falha. Mesma data com hashes diferentes sugere problema de fornecimento. Mesma revisão interpretada de formas diferentes aponta para implementação. Artefato validado que não foi implantado não pode sustentar uma afirmação de produção.

O registro deve provar pouco, mas provar bem

A RFC 9890 tornou-se referência autoritativa do procedimento da IANA. Ao mesmo tempo, declarou que não criava novas operações, requisitos de gerenciamento ou riscos de segurança.

Essa limitação é saudável. A IANA pode rejeitar uma colisão na primeira atribuição e registrar que uma revisão pertence à mesma linhagem. Não pode certificar qualidade do modelo, conformidade do parser, compatibilidade do produto ou segurança da migração.

A ideia de Especificação Inicial Mínima, de Heng Lu, ajuda a desenhar a fronteira. Nome e namespace precisam de uma resposta comum, porque uma colisão quebraria referências compartilhadas. Escolha de versão, empacotamento, janela de mudança e risco de serviço continuam locais.

Uma revisão registrada torna-se disponível ao ecossistema; não vira uma ordem de adoção simultânea. A identidade pública sobrevive enquanto cada equipe toma a decisão futura no seu próprio domínio.

Qin Wu está na fonte, não no console de produção

A RFC 9890 inclui Qin Wu, da Huawei, no grupo de autores com Andy Bierman e Mohamed Boucadair. O IETF Datatracker oficial liga uma longa lista de RFCs à mesma identidade pública. Isso fornece contexto verificável para a participação no trabalho de YANG e gestão de redes.

Não concede propriedade exclusiva sobre a norma. O processo da IETF produz o consenso; a IANA mantém o registro; autores elaboram revisões; fornecedores implementam; operadores testam e implantam.

Separar os papéis evita atribuição falsa. Erro no cadastro pertence ao processo do cadastro. Divergência do parser pertence ao software. Uma mudança mal aprovada pertence à cadeia de decisão operacional. O crédito de autoria informa a origem do texto, não transfere responsabilidade por todas as redes que o utilizam.

A contribuição de Qin Wu deve ser lida no tamanho correto: corrigir uma fronteira normativa para que o registro possa representar a prática sem tomar as decisões que vêm depois.

Prática executável ainda precisa passar por um teste de finalidade

Primazia do código em execução não significa que toda rotina existente merece virar regra. Uma prática popular pode ser insegura ou prejudicar interoperabilidade. Ela só deve corrigir o texto comum quando preservar a propriedade que justificou a coordenação.

As revisões mantendo nome e namespace passam nesse teste. Elas não permitem uma segunda identidade inicial. Evitam apenas que a mesma linhagem se fragmente em aliases artificiais e conservam referências usadas por ferramentas e documentos.

A RFC 9890 também deixou a correção auditável. Mostrou a redação antiga, descreveu a diferença com a prática, publicou a nova redação e apontou para o registro afetado. Não transformou o problema em uma nota editorial invisível.

Uma especificação se fortalece quando admite que a prática delimitada revelou uma abstração errada. Fazer o sistema real mudar de nome só para manter a aparência do texto teria invertido a prioridade.

O recibo que atravessa a próxima revisão

O primeiro bloco registra nome, namespace, RFC de atribuição, data e a marca de versão inicial. É nessa camada que se aplica a verificação de unicidade.

Cada revisão repete a identidade e acrescenta data, URL, hash, documento de origem e antecessor. O sistema também registra se revision-date foi escolhido explicitamente ou se a seleção ficou indefinida.

A camada de software guarda parser, versão, imports, features, deviations, pacote, validação e bytes distribuídos. A camada operacional liga aprovação, teste, escopo de implantação, incidentes e rollback.

Os verbos do painel precisam ser exatos: a IANA registrou; a RFC especificou; o pacote incluiu; o parser aceitou; o fornecedor ofereceu suporte; o operador implantou; o serviço continuou ou falhou. Um status verde não pode responder por outro ator.

Fontes