Resumo

  • Um Internet-Draft ativo do grupo NETCONF permite restringir uma assinatura YANG-Push por revisão exata ou pela versão semântica compatível mais recente, além de incluir versão do módulo e content-id da YANG Library nos eventos do ciclo de vida.
  • A sinalização ajuda a rejeitar ou detectar mudanças de esquema. Ela não prova a compatibilidade dos módulos importados, o artefato carregado pelo receptor, a preservação do significado, a autoridade para agir nem o resultado observado na rede.

Disponibilidade e continuidade semântica são métricas diferentes. A primeira pergunta se mensagens chegam. A segunda pergunta se publicador e consumidor ainda atribuem o mesmo significado a elas. Uma assinatura persistente pode responder “sim” à primeira e “não se sabe” à segunda.

No YANG-Push, a configuração da assinatura define seleção e política de envio. O significado dos dados depende da biblioteca YANG que o equipamento executa: módulos, revisões, imports, identities e deviations. A assinatura configurada pode sobreviver a reinicializações e upgrades. A biblioteca pode mudar nesse intervalo. A continuidade do identificador não congela o contrato.

O draft-ietf-netconf-yang-notifications-versioning-16, de 17 de setembro de 2026, procura tornar esse risco observável. O Datatracker o registra como documento ativo do grupo NETCONF, submetido ao IESG para Proposed Standard e em IETF Last Call até 29 de setembro. Ainda é um Internet-Draft, não um RFC definitivo nem comprovação de comportamento de produto.

A proposta acrescenta dois controles e um conjunto de recibos. O cliente pode pedir uma revisão específica ou uma versão semanticamente compatível. O publicador pode recusar uma condição impossível. Ao iniciar ou modificar a assinatura, comunica o estado de versão e o identificador da biblioteca. O que antes era suposição passa a deixar rastro.

Revisão fixa e compatibilidade declarada resolvem problemas distintos

A condição revision nomeia uma data exata do módulo. Ela favorece reprodução. Se o publicador não possui a revisão, responde revision-unsupported. A operação falha de maneira explicável em vez de trocar o artefato silenciosamente.

A condição version pede a versão semântica compatível mais recente. Ela aceita evolução dentro de uma fronteira declarada. Quando não existe versão aceitável, a resposta é version-unsupported. Quando revision e version entram em conflito, incompatible-revision-and-version registra a contradição. Os três são erros RPC de aplicação invalid-value.

Fixar revisão pode transformar uma atualização em interrupção planejada; aceitar compatibilidade reduz coordenação, mas depende da qualidade da classificação e dos testes do consumidor. Um processo que recomenda capacidade pode tolerar degradação que uma automação de roteamento não pode. A escolha é política de risco, não detalhe de sintaxe.

As assinaturas configuradas exigem nova decisão após reiniciar. O publicador compara a condição persistida com a YANG Library corrente. Se não houver correspondência, o draft exige subscription-terminated. Uma configuração antiga não ganha autoridade para obrigar um sistema novo a fingir que é compatível.

Quando a assinatura começa ou continua, subscription-started e subscription-modified carregam nome do módulo, revision, version opcional e yang-library-content-id. Mudança de revision ou version durante a vida da assinatura conta como alteração de política e deve gerar subscription-modified. O receptor recebe uma oportunidade de pausar antes de interpretar o novo estado como se fosse o antigo.

O publicador informa uma versão; o receptor ainda precisa executá-la

O recibo de revision prova apenas uma afirmação do publicador sobre o módulo restrito. Ele não baixa o arquivo no coletor, não recompila bindings, não reinicia processos e não limpa caches. É perfeitamente possível registrar a versão correta enquanto o worker ativo usa um artefato anterior.

Outras divisões aparecem depois. O parser aceita uma identity nova, mas o banco grava unknown. A transformação muda o nome de uma coluna, mas a regra de alerta consulta a anterior. Um processo recebe a atualização e outro permanece com o estado antigo. Todos passam no health check, e ainda assim o significado se rompe.

Por isso, o recibo operacional deve reunir build do publicador e do receptor, ID da assinatura, condição solicitada, conjunto efetivo de módulos, snapshot e hash da YANG Library, hash do esquema carregado, versão do decoder e das transformações e resultado de replay. A versão anunciada é uma peça, não a conclusão.

O princípio da primazia do código em execução coloca a pergunta correta: o que rodou para este dado? Em 28 de setembro, a validação YANG do Datatracker para o módulo ietf-yang-push-revision registrou zero erros e zero alertas. Isso valida o artefato contra aquelas ferramentas. Não valida um roteador, um coletor ou uma decisão automatizada.

Compatível no módulo não significa compatível em todo consumidor

Os trabalhos de YANG Module Versioning e YANG Semantic Versioning fornecem linguagem para declarar mudanças retrocompatíveis e incompatíveis. Essa linguagem permite uma condição útil. Não conhece, porém, cada dependência acidental de cada aplicação.

Um nó opcional pode acionar defeito em gerador de código. Uma enumeração nova pode cair em um ramo padrão perigoso. Uma faixa ampliada pode exceder o armazenamento. Uma alteração compatível pode mudar volume e cardinalidade até quebrar uma etapa. A promessa do módulo pode estar correta enquanto um consumidor concreto falha.

“Versão compatível mais recente” deve abrir o teste. O receptor segue imports e identities usados pelos caminhos assinados, carrega os artefatos candidatos e reproduz dados comuns, limites e valores desconhecidos. Se o resultado de uma ação de alto impacto não puder ser demonstrado, a fila é isolada ou a ação é suspensa.

Isso não exige derrubar tudo diante de qualquer diferença. Se o diff de dependências mostra que a mudança não alcança a seleção e o replay é estável, a operação pode continuar. A especificação comum oferece um sinal mínimo; a decisão futura permanece local, explícita e revisável.

A dependência importada é o ponto cego mais importante

Módulos YANG reutilizam typedefs, groupings e identities de outros módulos. O módulo citado diretamente pode manter revision e version, enquanto um import muda sob ele. O controle direto não observa sozinho toda a árvore de significado.

O content-id da YANG Library, definido pelo RFC 8525 como identificador específico da implementação para o conteúdo atual da biblioteca, amplia a detecção. Quando muda, o receptor sabe que o inventário de esquemas do dispositivo mudou.

O sinal não identifica o módulo responsável. Pode mudar por uma função sem relação com a assinatura. Não é um hash universal comparável entre equipamentos. A diferença significa “obtenha a biblioteca e investigue”, não “a assinatura está quebrada”. A igualdade apoia continuidade dentro da prática do publicador, mas também não prova toda equivalência semântica.

O fluxo seguro é detectar, recuperar snapshots, calcular diff sensível a dependências e testar o consumidor afetado. Encerrar todas as assinaturas por qualquer variação gera indisponibilidade desnecessária. Ignorar a variação mantém a dependência importada invisível.

Essa divisão é saudável. O protocolo não precisa carregar a política de risco de cada organização. Ele oferece a condição direta e um alarme amplo. O consumidor decide continuar, degradar, revisar ou parar, e deixa um recibo dessa escolha.

O evento de mudança não torna a migração atômica

Quando subscription-modified chega, dados produzidos sob o esquema anterior podem estar em trânsito ou na fila. Workers paralelos podem observar o evento em ordens diferentes. O catálogo pode receber o novo hash antes de todos os processos carregarem o novo binding.

É necessário marcar a fronteira: último item processado com o artefato antigo, posição do evento e primeiro item aceito com o novo. Itens ambíguos vão para quarentena e são reproduzidos. Cada saída que alimenta uma decisão mantém referência ao esquema, decoder e transformação que a produziram.

subscription-terminated também tem alcance limitado. Prova que o publicador não retomou uma condição incompatível após reiniciar. Não prova que filas antigas foram drenadas, caches deixaram de dirigir ações ou tarefas derivadas foram canceladas. A terminação precisa acionar controles locais de contenção.

A capability yang-push-module-revision-supported anuncia suporte à exportação de revision/version nos eventos. É útil para selecionar um procedimento. Somente testes de upgrade, reinício, perda, duplicação e reordenação mostram o comportamento no fluxo real.

Manter separadas as camadas de realidade

Uma cadeia defensável começa pelo conjunto de módulos do publicador. Depois vêm aceitação da condição, metadados de lifecycle, ordem de entrega, esquema carregado, decodificação, transformação, política, autorização, tentativa de operação e efeito observado.

Cada estágio responde a uma pergunta. Entrega contínua não prova interpretação correta. Interpretação correta não concede poder para agir. Autorização não prova que o commit ocorreu. Um efeito observado não prova sozinho que o gatilho foi a causa.

Separar essas camadas não é burocracia. É o que permite fechar uma mudança de content-id sem impacto depois de diff e replay, encaminhar uma divergência com revision estável ao time do consumidor e classificar uma ação correta feita por identidade indevida como falha de autorização.

Os recibos podem compartilhar ID e tempo para formar uma trilha. Não devem compartilhar automaticamente a mesma conclusão. Cada dono declara o fato que observou e a incerteza que resta.

Alterar a condição de versão é alterar política sensível

Quem pode mudar revision ou version pode fixar um modelo antigo, causar terminação no próximo boot ou ampliar a faixa além dos testes. A condição não é preferência de visualização.

NETCONF e RESTCONF continuam exigindo transporte seguro e autenticação mútua apropriada. NACM controla acesso à configuração e ao estado. A auditoria deve registrar principal, método, valor anterior, valor novo, assinatura, biblioteca ativa e aprovação. O mecanismo que tenta recuperar disponibilidade não deve relaxar sua própria condição apenas para fazer o painel ficar verde.

Também é preciso separar a permissão de assinar dados da permissão de agir com base neles. Política e autorização são verificadas no ponto da decisão, mesmo quando o esquema está correto.

Alegações de implementação precisam virar ensaio

O draft relata, segundo seus autores, implementações parciais em Huawei VRP, 6WIND VSR e Cisco IOS XR. Isso ajuda a avaliar interesse e viabilidade. Não constitui verificação independente nem prova interoperabilidade completa.

A qualificação testa revisão suportada e não suportada, version sem alternativa, conflito de condições, seleção compatível, terminação após reboot, modificação em serviço, mudança direta, mudança apenas em import e alteração irrelevante de biblioteca. Em seguida injeta perda, repetição, desordem e rollback.

Os resultados ficam associados ao build, captura de mensagens e estado persistente do receptor. A presença de dois nomes numa seção não demonstra que duas execuções independentes concordam sobre a fronteira da migração.

Tornar o upgrade reconstruível e reversível

Antes da mudança, arquivar YANG Library, módulos, bindings gerados, imagem do decoder e corpus de replay. Fazer diff transitivo do candidato. Testar aceitação e rejeição, incluindo a primeira versão incompatível e dependências indiretas.

Durante a mudança, registrar a posição dos eventos de lifecycle. Se o content-id variar, buscar o inventário em vez de adivinhar a causa. Pausar ações irreversíveis até o replay local. Se a condição não puder ser satisfeita, falhar visivelmente e preservar a razão.

Depois, comparar objetos decodificados, transformações, decisões e efeitos. Verificar filas e caches antigos e ensaiar rollback coordenado de publicador e receptor. Sucesso não é a assinatura permanecer ativa; é conseguir provar a continuidade relevante e nomear o que ainda não se sabe.

O versionamento de notificações fecha uma lacuna valiosa: torna o movimento do esquema visível para uma assinatura de longa duração. A organização ainda precisa converter a sinalização em artefatos testados, autoridade explícita e efeito observado. Tráfego contínuo nunca deve falar em nome dessas etapas.

Fontes