Resumo

  • A revisão 21 determina que o Publisher Parent decomponha uma Network Node Subscription em Component Subscriptions sem sobreposição e exige pelo menos um Message Publisher ID no estado da assinatura.
  • A lista anunciada pelo Parent é um recibo da decomposição declarada; não prova cobertura exaustiva nem entrega contínua de cada Agent.
  • A auditoria precisa unir contexto do nó, conjunto vigente de publicadores, identidade por processo, época de sequência, identidade da mensagem quando aplicável, horário de observação e histórico de estado.

O sujeito corrigido durante o Last Call

draft-ietf-netconf-distributed-notif-21 foi enviado em 6 de setembro de 2026. O documento do grupo NETCONF estava no IETF Last Call até 8 de setembro. Ele pretende seguir como Proposed Standard e foi submetido ao IESG, mas continua sendo Internet-Draft: não é RFC e não comprova adoção.

A revisão 20 havia recebido IANA - Not OK. A análise apontou um exemplo XML inválido e descreveu registros futuros. A versão 21 corrige aspas, texto de registro e caminhos YANG de segurança; o estado mudou para Version Changed - Review Needed. Isso pede nova revisão, não anuncia registros concluídos.

A alteração central troca quem pratica a decomposição. O Subscriber mantém a assinatura do nó junto ao Parent; o Publisher Parent a desmonta em assinaturas de componentes. O solicitante sabe o que quer. O Parent sabe quais Agents existem e quais capacidades possuem. Logo, a autoridade de escolher a cobertura está no nó e deve deixar uma trilha de responsabilidade.

O min-elements 1 acrescentado à lista message-publisher-id impede um conjunto de estado vazio. É uma garantia estrutural útil, mas uma lista com um nome ainda pode omitir componentes necessários.

O ID comum representa o contrato

O Collector pode separar Subscriber e Receivers. As solicitações vão apenas ao Parent. Ele expõe capacidades, cria Component Subscriptions sem sobreposição, repassa propriedades aos Agents e mantém o estado geral. Os Agents herdam o mesmo ID e ciclo de vida, coletam sua parcela e publicam diretamente aos Receivers.

Portanto, o ID da assinatura não identifica um único processo. Um gráfico agregado pode permanecer estável enquanto um Agent silencia. A mesma queda de volume pode significar demanda menor, nova divisão, reinício ou falha de transporte.

O rascunho deixa a coordenação Parent-Agent fora do escopo e torna específica da implementação a atribuição de subárvores YANG. Não sobrepor evita duplicação entre componentes declarados; não prova que todos os componentes em execução foram incluídos.

Declaração não é realidade em execução

Todos os avisos de ciclo de vida saem do Parent. subscription-started e subscription-modified apresentam a lista corrente, e uma mudança na decomposição deve gerar outra lista. Esses avisos são declarações com validade temporal.

Três conjuntos devem continuar separados: o que o Parent declarou, o que o Receiver observou e o que está em execução e deveria contribuir segundo inventário e configuração. Se os dois primeiros forem iguais, apenas todos os Agents declarados foram ouvidos. Uma placa omitida ou uma região YANG atribuída incorretamente pode jamais aparecer.

A clareza da camada simbólica não substitui a verificação operacional. A declaração ganha força quando confrontada com inventário, capacidades e configuração independentes. Divergências precisam de dono, não de uma média verde.

Continuidade é por processo

Cada push-update ou push-change-update pode trazer o Message Publisher ID local de quem publicou. O rascunho de envelope acrescenta nome de host e sequência opcionais por processo: 32 bits, início em 1, passagem visível por zero após 4.294.967.295. O horário de observação diz quando o valor foi visto, não necessariamente quando ocorreu, foi codificado ou entregue.

Identidade responde quem; sequência mostra lacunas numa época; Message ID ajuda com duplicatas; horário posiciona a medição; histórico diz quem era esperado. Um reinício abre nova época, mensagens antigas podem chegar tarde e IDs locais podem colidir entre nós. A chave defensável inclui nó, processo, época e intervalo de estado do Parent.

Um endereço, várias autoridades

Todos os Agents aparecem com o mesmo IP de origem. Em UDP eles podem compartilhar também a porta; em HTTPS, a arquitetura exige uma porta dedicada por processo. Cinco tuplas, terminação TLS e ID da assinatura são contexto de roteamento, não proveniência suficiente.

O transporte UDP combina Publisher ID e Message ID e pode precisar do IP quando identificadores locais se repetem. Também rejeita a dependência de fragmentação IP para notificações grandes. Reconhecer o Agent ausente não basta se sua maior mensagem some sem sinal.

Publicação direta distribui o perímetro de segurança

Publicar de processadores de rede ou placas evita que todo dado passe pelo processador central. Em troca, autenticação, autorização, chaves, limites de taxa e recursos se espalham. Transportes seguros de NETCONF ou RESTCONF e NACM continuam relevantes, mas identidades e pontos de aplicação são fatos de cada implantação. Uma regra no Parent não prova execução equivalente por todos os Agents.

Publisher IDs também revelam a disposição interna de processos. Mudanças podem expor reinício, expansão ou realocação. A mesma visibilidade que sustenta auditoria pode ajudar mapeamento hostil ou falsificação. Restrinja o acesso à topologia bruta sem apagar a identidade da cadeia de evidências.

A questão ainda aberta

A prosa exige identidade nas atualizações, mas a árvore YANG atual mostra o message-publisher-id por mensagem como opcional. O novo mínimo vale para a lista de estado, não automaticamente para cada atualização. Isso é uma pergunta de revisão, não um veredito: em qual condição um Receiver deve rejeitar ou isolar uma mensagem sem origem?

Teste separadamente lista não vazia, identidade presente, pertencimento ao conjunto vigente e resposta ao descumprimento.

Limites

As fontes estabelecem texto, histórico e estado da revisão. Não estabelecem adoção, conformidade, topologia real, perda, latência, incidente, exploração ou ganho de desempenho. Os rascunhos de envelope, UDP e HTTPS também podem mudar.

A conclusão durável é estreita: decompor, declarar, emitir, observar e reconciliar são atos diferentes. Um identificador não pode substituir os cinco sem eliminar responsabilidade.

Fontes