Resumo

  • Em 18 de agosto de 2026, o IESG anunciou a aprovação do draft-ietf-netmod-yang-module-versioning-17 para publicação como Proposed Standard. O texto admite evolução não retrocompatível documentada, acrescenta recommended-min-date ao import e torna visível como servidores tratam nós deprecated e obsolete.
  • O próprio exemplo com ramos delimita o alcance da data: a revisão 2019-05-01 satisfaz o mínimo 2019-04-01, mesmo podendo não conter o que nasceu no ramo de 2019-04-01. A data ordena artefatos; não prova descendência, esquema efetivo no destino ou poder para autorizar a mudança.

A porta cronológica admitiu o ramo irmão

A abertura é uma construção analítica baseada no exemplo do documento, não um incidente conhecido de equipamento, fornecedor ou rede. O resolvedor obedece à definição de recommended-min-date: escolhe uma revisão com data igual ou posterior à recomendada.

O histórico se divide após 2019-02-01. Um ramo passa por 2019-03-01 e chega a 2019-05-01; o outro passa por 2019-04-01 e chega a 2019-06-01. Quem depende de uma capacidade introduzida em 2019-04-01 pode usar essa data como piso. Pela aritmética, 2019-05-01 passa. Pela genealogia, está do outro lado da bifurcação.

O rascunho alerta expressamente que 2019-05-01 talvez não contenha o material desejado de 2019-04-01. Por isso, considera o campo inadequado a históricos ramificados e mais útil em desenvolvimento linear. “Depois de” é uma posição no calendário; “derivado de” é um caminho no grafo.

A aprovação melhora a prova sobre rupturas

O texto aprovado, “Updated YANG Module Revision Handling”, é produto do grupo NETMOD. Continua sendo um Internet-Draft na fila do RFC Editor e pode receber ajustes editoriais antes da publicação. O comunicado registra que a situação das implementações é desconhecida; não há base para afirmar suporte universal.

O RFC 7950 exigia atualizações estritamente retrocompatíveis. O novo trabalho reconhece situações em que uma correção precisa refletir o servidor real, um nó obsolete precisa ser removido, material instável precisa mudar ou uma reestruturação compatível custa mais do que entrega. Tais mudanças seguem desaconselhadas e devem ser reduzidas.

Uma revisão com alteração não retrocompatível em relação ao pai precisa declarar rev:non-backwards-compatible. O marcador transforma uma aresta antes silenciosa em evidência examinável. Porém ele qualifica só aquela aresta; não prova que o candidato pertence ao ramo de que o consumidor depende.

Identidade imutável não é linhagem

Dentro de um histórico, nome do módulo e data da revisão identificam uma definição imutável. Essa função de identidade é forte, mas distinta de uma função genealógica. Segundo o documento, datas ou identificadores de versão, isoladamente, não determinam a ancestralidade entre revisões; é necessário consultar o histórico.

Submódulos ampliam a lacuna. Quando include não fixa a revisão exata do submódulo, o módulo principal não basta para revelar o conteúdo efetivamente usado. revision-date, YANG Library ou um inventário de pacote precisa fechar essa informação.

O registro de admissão deve, portanto, conservar hash do artefato, relação parental ou caminho do ramo, revisões dos submódulos e conjunto de módulos resolvido no destino. Um identificador pode apontar para um arquivo imutável e ainda assim ser interpretado na árvore familiar errada.

O mínimo recomendado evita um acoplamento rígido

recommended-min-date é uma subdeclaração de import que pode aparecer zero ou uma vez. A revisão importada atende à recomendação se sua data for igual ou posterior; acrescentar, alterar ou retirar o valor é considerado retrocompatível. Um analisador que não reconheça a extensão segue as regras comuns do RFC 7950.

Quando um piso de dependência ajuda, o rascunho prefere essa recomendação a um revision-date exato no import, pois a fixação gera dependência excessivamente rígida. Isso permite incorporar trabalho compatível posterior sem congelar um único artefato.

A flexibilidade exige um teste separado de adequação. O campo não pergunta se o candidato descende da revisão necessária, mantém determinado nó, incorpora uma mudança do ramo ou cabe no cliente. A data pode abrir a busca; histórico, esquema efetivo e testes devem fechá-la.

O aviso de incompatibilidade pertence à aresta

rev:non-backwards-compatible pode indicar que um nó virou obsolete, uma restrição mudou ou ocorreu outra ruptura permitida. Ele não certifica a relação entre essa revisão e todos os pontos de um histórico ramificado.

Um painel que guarda apenas a data mais recente e um aviso comprime demais a prova. A capacidade exigida pode ter surgido no ramo vizinho; a ausência de alerta na linha selecionada não cria uma ligação ancestral.

O mantenedor também pode usar o aviso para uma mudança formalmente compatível que tenha impacto relevante no cliente, como ampliar o conjunto de valores de uma folha operacional. É um sinal conservador para investigar a diferença, não uma decisão automática. Comparação de esquema explica a alteração; testes no destino mostram o efeito real.

Podar histórico reduz o que ainda pode ser provado

Algumas declarações de revisão publicadas podem ser removidas para encurtar um histórico ou desestimular imports antigos. A entrada mais nova deve permanecer, e os marcadores preservados precisam continuar descrevendo corretamente as relações entre as entradas restantes.

O documento desencoraja a poda porque ela pode ocultar quando surgiu uma incompatibilidade. Não se pode retirar uma entrada se a operação fizer uma revisão posterior parecer compatível com uma antiga através de um passo incompatível escondido.

Histórico é evidência operacional. Quando o registro normativo não preserva a aresta necessária, repositórios de artefatos, hashes assinados, manifestos e registros de mudança ganham importância para reconstruir a cadeia. Simplificar a tela pode apagar a justificativa de uma futura admissão.

O estado dos nós pertence ao alvo

O novo ietf-yang-library-status amplia YANG Library com dois booleanos. deprecated-nodes-implemented verdadeiro informa que nós deprecated são implementados como current, salvo retirada explícita por deviation. obsolete-nodes-absent verdadeiro informa que o servidor não implementa nós obsolete.

Os dois valores têm false como padrão, mas false significa comportamento não especificado. O rascunho recomenda true em ambos para que o cliente determine o esquema exato. Sem a primeira confirmação, o cliente não deve depender apenas de marcadores de incompatibilidade.

Logo, até o ramo certo pode produzir um destino diferente: um nó deprecated pode ter sumido, um obsolete pode permanecer e uma deviation pode alterar o resultado. O ciclo recomendado passa de current para deprecated e então obsolete. Clientes devem planejar a saída de nós deprecated e parar de usar os obsolete. É uma transição operacional, não uma conclusão do calendário.

A admissão precisa do grafo e do alvo em execução

Um controlador defensável registra a capacidade requerida e sua revisão de origem, resolve o artefato exato, prova o caminho parental, preserva arestas incompatíveis e lacunas, fixa submódulos, captura YANG Library e os dois estados, aplica deviations, compila o esquema efetivo e valida dados representativos.

Depois, testa o cliente contra o software e a classe de configuração reais do servidor. Uma revisão incompatível pode expor valores fora dos limites supostos por um cliente antigo, mudar padrões ou exigir ajustes em regras NACM. A data não observa nenhuma dessas consequências.

As falhas devem permanecer separadas: ramo irmão é falha de linhagem; estado ausente é lacuna de descoberta; árvore diferente é falha de esquema; valor ou padrão inesperado é efeito de implementação; aprovação ausente é falha de governança. A cronologia seleciona candidatos. Descendência provada, estado exato do alvo, código em execução e responsável nominal decidem a entrada.

Fontes