Resumo

  • A RFC 6020 dizia que todos os nomes de módulos e submódulos e todos os namespaces XML no registro deveriam ser únicos. A seção 3 da RFC 9890 registra que essa redação não correspondia à prática da IANA para revisões.
  • Pela regra atualizada, os nomes das versões iniciais de módulos e submódulos continuam únicos, enquanto as revisões preservam o nome da versão inicial. O namespace XML inicial continua único, e cada revisão do módulo mantém o mesmo namespace XML da versão inicial.
  • A IANA lista a RFC 9890 como referência adicional porque o procedimento nela descrito é autoritativo para atribuir nomes no registro YANG Module Names. Essa identidade do registro não é o mesmo que um inventário operacional sensível à revisão.

O mecanismo operacional vem primeiro

Para um operador, duas revisões podem apresentar exatamente o mesmo nome de módulo e o mesmo namespace XML. Essa continuidade protege a identidade inicial registrada; não promete que cada revisão terá um nome globalmente distinto. Para responder qual revisão um sistema validou, implantou ou guardou para rollback, é necessário registrar a revisão e uma evidência capaz de reconstruir a entrada usada, como o texto original e seu hash.

A redação antiga da RFC 6020 pode ser lida como uma exigência de que nenhum nome ou namespace se repita entre todas as versões. A RFC 9890 esclarece que a prática da IANA já reutilizava o nome e o namespace iniciais nas revisões e alinha a política a essa prática existente. Ela não transforma o nome em número de revisão e não cria novas operações ou requisitos de gerenciabilidade.

O que a autoridade da IANA significa

A autoridade aqui é sobre o procedimento de atribuição e registro. A IANA mantém a entrada do nome e do namespace do módulo ou submódulo inicial e aponta a RFC 9890 como referência adicional. Um snapshot congelado demonstra apenas o estado do registro no momento observado. Ele não demonstra qualidade de implementação, adoção por operadores, compatibilidade de ferramentas ou correção semântica de uma revisão específica, nem substitui o inventário de implantação.

Identidade do registro versus inventário por revisão

Esta é uma análise de Theo March, não um requisito da RFC 9890: tratar um nome estável como prova direta de compatibilidade cria ambiguidade de identidade. Uma automação que armazena schema apenas pelo nome pode reutilizar uma revisão que nunca foi validada para aquele contexto, produzindo deriva de automação. Se o pacote de rollback retém somente nome e namespace, não há como provar depois qual versão semântica foi restaurada. Uma prática mais defensável é guardar, no mesmo registro orientado à revisão, nome, namespace XML, data ou identificador equivalente da revisão, origem do módulo, hash, resultado da validação e horário da implantação.

Fixtures concretas de verificação

As verificações abaixo são recomendações operacionais, não requisitos novos da RFC:

  1. Separe duas revisões sucessivas com o mesmo nome inicial e o mesmo namespace XML. Preserve o texto de cada uma e seu SHA-256; confirme que a consulta ao registro encontra uma identidade estável, enquanto o inventário diferencia as revisões.
  2. Faça o validador receber explicitamente identificador de revisão e hash, e não apenas o nome. Registre entrada, resultado, versão da ferramenta e horário.
  3. Em uma implantação simulada, troque intencionalmente os dois arquivos e verifique se a divergência de revisão ou hash é recusada. No rollback, confirme que o arquivo correto pode ser recuperado de forma única a partir do registro.
  4. Mantenha o snapshot congelado da IANA separado de uma consulta atual, com o horário de observação. Não use o snapshot como prova de correção da implementação.

Os limites da evidência precisam permanecer explícitos. O conjunto não mede quantas ferramentas presumiram nomes globalmente únicos entre todas as revisões. Nenhum incidente operacional, falha de interoperabilidade ou custo de migração foi estabelecido. A RFC não valida a compatibilidade semântica de revisões sucessivas. O snapshot da IANA pode mudar depois da observação e representa o estado do registro, não a correção de uma implementação. Suporte de fornecedores e prevalência de implantação estão fora das fontes.

Fontes