Resumo

  • draft-ietf-netconf-yang-notifications-versioning-16 permite restringir um módulo por revisão exata ou versão semântica compatível e devolver suas coordenadas nos eventos de estado da subscrição.
  • O content-id da YANG Library alcança o conjunto mais amplo do servidor: pode denunciar a troca de uma dependência importada sem dizer qual foi, se afeta o caminho ou se quebra o consumidor.
  • A continuidade segura liga o recibo do evento a uma nova biblioteca, ao fechamento de dependências e ao decodificador aprovado; manter o fluxo não é o mesmo que preservar seu significado.

O custo mais visível de uma mudança de esquema é o fluxo parar. O custo mais sério pode ser o fluxo não parar: mensagens novas atravessam um decodificador antigo e parecem plausíveis o bastante para alimentar decisões.

A revisão 16 de YANG-Push Notification Versioning trata dessa zona cinzenta. O YANG-Push existente cria subscrições e entrega atualizações, mas não inclui no mecanismo a revisão do módulo subscrito. Uma atualização do nó pode mudar o contrato sem que o Receiver saiba que precisa rever sua interpretação.

O módulo ietf-yang-push-revision introduz restrições explícitas. A solicitação escolhe uma data de revisão YANG ou a versão mais recente compatível com uma versão semântica indicada. Se o Publisher não puder atender, responde invalid-value com revision-unsupported, version-unsupported ou incompatible-revision-and-version. A rejeição passa a trazer uma causa operacional, em vez de esconder a fronteira da política.

Nos eventos de estado, subscription-started e subscription-modified carregam módulo, revisão, versão opcional e yang-library-content-id. Se a revisão ou versão de um módulo acompanhado mudar durante a subscrição, o texto considera isso uma alteração de política e exige subscription-modified. Depois de uma reinicialização, se a YANG Library já não satisfizer a condição de uma subscrição configurada, o Publisher deve enviar subscription-terminated.

Esse recibo, porém, enxerga primeiro o módulo direto. O exemplo essencial assina /ietf-interfaces:interfaces e reporta a coordenada de ietf-interfaces. Uma alteração nesse módulo pode mover a coordenada e o content ID. Já uma alteração apenas no ietf-yang-types importado deixa a revisão direta intacta. O Receiver percebe que algo no estado de esquema do equipamento mudou somente pelo content ID.

O alcance maior não torna o identificador mais conclusivo. Na YANG Library, ele representa de forma específica à implementação as informações atuais da biblioteca em um servidor. Não é um digest portátil entre fornecedores ou aparelhos. Sua mudança não localiza a dependência, não prova que o caminho subscrito foi afetado e não antecipa se um decodificador conseguirá lidar com a diferença.

O valor também pode mudar por um módulo que nada tem a ver com aquela subscrição. Suspender tudo a cada alteração cria indisponibilidade desnecessária. Ignorar o alerta porque a revisão visível ficou igual mantém um grafo de dependências antigo em serviço. O problema não se resolve escolhendo um dos sinais: eles respondem a perguntas distintas.

A coordenada registra a linhagem que o Publisher declara para o módulo relevante ao caminho. O content ID detecta se o recibo do conjunto de biblioteca continua igual. Nenhum deles valida sozinho consultas persistidas, armazenamento, painéis ou automações que recebem os valores depois.

Uma trilha operacional começa pela identidade do Publisher e pela capacidade anunciada. Guarda o ID local da subscrição, filtro ou caminho, restrições aceitas, coordenadas iniciais e content ID inicial. Ao receber um evento de estado, o Receiver compara os dois escopos. Se o identificador mudou, busca a YANG Library atual, calcula os imports e includes relevantes, escolhe ou testa o decodificador e só então libera o processamento.

Dados já armazenados em buffer permanecem ligados ao recibo vigente quando foram produzidos. Uma biblioteca posterior não deve reinterpretar silenciosamente bytes antigos. Teste do decodificador, compatibilidade do armazenamento, confirmação do consumidor e autorização da automação são recibos próprios, posteriores à sinalização do Publisher.

Também importa quem pode escrever as restrições. Elas podem ser criadas, alteradas e removidas; o documento exige controle de acesso adequado. O RFC 8341 define o NACM para essa superfície. Afrouxar uma condição de versão muda qual contrato de interpretação a organização aceita — uma prerrogativa de controle, não um ajuste banal de telemetria.

A revisão 16 tem data de 17 de setembro de 2026. O histórico no Datatracker a coloca em IETF Last Call até 29 de setembro, sem telechat na captura congelada. A validação YANG de 27 de setembro informa zero erros e avisos, evidência sobre o módulo enviado e aquelas ferramentas, não sobre implementações reais. O texto da revisão continua sendo um Internet-Draft sujeito a mudança.

O RFC 8639 define notificações subscritas, o RFC 8641 estende-as para YANG-Push, e o RFC 7950 estabelece revisões e imports em YANG. Os textos de versionamento de módulos e versionamento semântico ainda são drafts. O RFC 9196 fornece outro contexto de seleção. Compatibilidade declarada não comprova a sobrevivência de um consumidor específico.

Fontes