Resumo

  • A revisão 03 propõe que módulos YANG normativos permaneçam prerelease na aprovação do IESG, sejam editados sob limites explícitos, recebam revision date e YANG Semver finais, sejam validados novamente e só então publicados quase juntos no RFC e pela IANA.
  • Retirar o sufixo, obter sucesso em pyang/yanglint e provar igualdade de bytes são recibos úteis, mas não demonstram isoladamente preservação semântica, escolha correta da versão, obtenção pelo cliente, carregamento ou compatibilidade operacional.
  • Módulos publicados pelo IETF e módulos mantidos pela IANA a partir de companion registries têm origens e ciclos diferentes.

Antes do mecanismo, vem o estado do próprio documento. Em 11 de setembro de 2026, o Datatracker mostra draft-ietf-netmod-iana-yang-guidance-03 como Internet-Draft ativo do WG NETMOD, WG Document, I-D Exists, com Intended RFC status Informational. A revisão 03 é datada de 6 de julho de 2026 e expira em 7 de janeiro de 2027. O “Last updated” de 27 de agosto registra mudanças do shepherding AD e do status pretendido; a revisão mais recente continua sendo a de 6 de julho. Não é RFC, nem evidência de processo aplicado ou implantação.

O prerelease protege o instante antes da imutabilidade

No cenário futuro descrito pelo draft, a aprovação do IESG normalmente encontra versões provisórias: major zero ou um sufixo ligado ao número do Internet-Draft. O marcador avisa que o módulo ainda pode mudar durante o trabalho do RFC Editor e ainda não merece a imutabilidade de uma revisão publicada.

O RFC Editor pode clarear uma descrição sem alterar sentido, trocar referências de draft pelo RFC definitivo, corrigir erros tipográficos e padronizar formato. Uma mudança substantiva precisa ser coordenada com os autores. Quando não está claro se a alteração é editorial, BC ou NBC, a proposta manda buscar orientação, não esconder a dúvida sob uma correção de estilo.

No fim, a revision date é atualizada, o indicador prerelease sai e o YANG Semver de release é decidido. Um módulo já publicado precisa ser comparado à edição anterior e pode exigir rev:non-backwards-compatible. Alterações posteriores reabrem a decisão. O número final é, portanto, um julgamento rastreável sobre bytes finais.

A validação herda todos os seus inputs

Depois da edição e formatação, o texto recomenda nova validação, em geral com pyang e yanglint. Dependências corretas não são detalhe. Um conjunto de módulos publicado em conjunto pode precisar ser extraído e testado no mesmo contexto.

O draft não apresenta a ferramenta como árbitro sem falhas. Mudanças em descriptions podem parecer editoriais para o parser e ainda mudar sentido. Comparadores cobrem classes conhecidas, não todo caso imaginável. Bugs podem gerar falsos positivos e negativos. Uma versão anterior ainda prerelease pode impedir a sugestão automática de um release. Resultado inesperado deve levar a revisão humana.

Assim, um run sem warning nem error prova somente que determinada versão do programa aceitou aqueles bytes, flags e dependências. Não prova equivalência de comportamento, escolha perfeita do Semver nem aceitação por todos os consumidores.

Duas publicações fecham uma divergência específica

A recomendação central é adiar a publicação na IANA até o RFC Editor finalizar o módulo. Depois, o RFC carrega o conteúdo final e a IANA publica a mesma versão em YANG Module Names aproximadamente no mesmo momento. A referência ao RFC também deve estar correta.

Um auditor pode extrair ambos os objetos, registrar URLs e horários, calcular hashes e conferir revision/version. A igualdade resultante é forte evidência de consistência editorial. Ainda não responde o que uma URL mutável entregou antes, qual arquivo ficou no cache, como um package resolveu versões, qual processo carregou o módulo, que features/deviations foram aplicadas, o que o YANG Library anunciou ou se dados e operações continuaram compatíveis.

As matérias BTW sobre filename, schema comparison, module versioning e packages preservam esses mecanismos. A revisão 03 ocupa outra passagem: a cadeia de custódia entre candidato editorial final e dois publicadores.

Um módulo mantido pela IANA começa no registro

Na segunda trilha, o módulo mantido pela IANA representa um companion registry, normalmente com enums ou identities. O novo valor entra primeiro no registro autoritativo. A IANA identifica o delta, faz a mudança equivalente no módulo, atualiza revision e version, verifica BC/NBC, valida e publica artefatos endereçáveis por data e versão.

Esse recibo liga uma alteração identificada do registro a uma edição do módulo. Não prova freshness contínua, tradução completa do registro, download, load ou uso em dispositivo. A questão de autoridade e atualização do RFC 9907 é relacionada, mas não substitui a mecânica de handoff desta proposta.

A operação precisa de recibos adicionais

Uma trilha defensável mantém separados: candidato prerelease aprovado; alterações e consultas editoriais; decisão final de versionamento; inputs e ambiente de validação; bytes extraídos do RFC; bytes e horário da IANA; recuperação e cache do cliente; carregamento e effective schema do equipamento; observação de datastore, protocolo, tráfego e serviço.

Running-Code Primacy, de Heng Lu, é a lente declarada deste artigo, não uma afirmação sobre a intenção do IETF: coordenação publicada não executa adoção. Minimum Initial Specification reforça a utilidade de regras comuns estreitas e verificáveis. Reality, Not Advocacy e Reality Layers impedem que o recibo de uma camada fale pela seguinte.

Esperar pelos bytes finais e publicar duas cópias iguais é boa engenharia editorial. A disciplina seguinte é não chamar isso de rede atualizada.

Fontes

  1. Texto da revisão 03
  2. Registro atual no Datatracker
  3. Histórico no Datatracker
  4. RFC 9907
  5. RFC 9890
  6. RFC 7950
  7. YANG Module Versioning, revisão 17
  8. YANG Semantic Versioning, revisão 26
  9. YANG Schema Comparison, revisão 09
  10. YANG module filename, revisão 14
  11. Parâmetros YANG da IANA
  12. Heng Lu — Running-Code Primacy
  13. Heng Lu — Minimum Initial Specification
  14. Heng Lu — Reality, Not Advocacy
  15. Heng Lu — Reality Layers