Resumo

  • O rascunho transporta horário de geração, hostname, contador de 32 bits por processo publicador e semântica de observação; cada campo continua sendo uma alegação delimitada por esquema e contexto.
  • Automação precisa de recibos separados para esquema, identidade autenticada, época do processo, relógios, assinatura da subscrição, conteúdo, caminho posterior e resultado autoritativo.

O coletor recebe um objeto impecável. A raiz é envelope; o horário é válido; o hostname parece correto; o número segue o anterior; a atualização dentro de contents decodifica. Há uma conclusão segura: aquela instância pôde ser lida. Todo o resto exige prova própria.

A revisão 05, de 18 de maio de 2026, enfrenta uma perda prática de contexto. O cabeçalho da RFC 5277 tem apenas eventTime obrigatório e não pode ser estendido. Quando um receptor encaminha a mensagem a um broker ou banco de séries temporais, a origem do transporte pode desaparecer. O rascunho usa uma estrutura YANG comum, serializável em XML, JSON ou CBOR, para manter metadados junto da carga.

O Datatracker registra um Internet-Draft ativo do grupo NETCONF, pretendido como Proposed Standard e aguardando avanço da coordenação do grupo. Não é RFC. A utilidade está em explicitar alegações menores, não em transformá-las numa garantia total.

Forma válida não é fato válido

Com o recurso habilitado, envelope contém event-time obrigatório, hostname e sequence-number opcionais e contents como anydata. A RFC 8791 define a estrutura; RFC 7951 e RFC 9254 cobrem JSON e CBOR.

Validação pode demonstrar nós, tipos, namespaces e codificação contra os esquemas carregados. Não prova que o inventário era o esperado, que o interior de contents foi examinado ou que os valores correspondem ao equipamento. Em 10 de setembro de 2026, o Datatracker exibia quatro erros e dois avisos YANG. O histórico também registra, numa data anterior, execuções limpas de yanglint e pyang, explicando que o anydata dos exemplos ficou fora do escopo. As verificações têm datas e escopos diferentes; nenhuma certifica runtime.

O recibo de esquema lista revisão, features, serialização, namespaces ou SID, versão do validador, modelos carregados e profundidade real.

Hostname é rótulo, não autenticador

O texto chama hostname de nome do nó que publicou e diz que ele identifica o nó na rede. O modelo esclarece que o valor costuma ser configurado por administrador. Sob uma autoridade de nomes, é ótimo para correlação. Ele não comprova a si mesmo.

A seção de segurança exige transporte seguro e autenticação mútua para NETCONF ou RESTCONF e alerta que o nome pode ajudar no mapeamento da rede ou em notificações falsificadas. Receber edge-17.example por um caminho não autenticado prova apenas a presença da string.

Identidade requer vínculo com peer ou chave autenticada, certificado e época, dispositivo, processo, autoridade de nomes e autorização da subscrição. A RFC 8341 mantém permissões como controle separado e permite filtrar ou descartar conteúdo.

Continuidade só existe dentro da época do processo

sequence-number é counter32: começa em 1, cresce a cada notificação do processo e, após 4294967295, retorna a 0. Um salto ou inversão detecta descontinuidade numa época conhecida.

O rascunho não fornece identificador durável de época nem política de persistência após reinício. Um receptor que começa no 914 não conhece o passado. Outro processo pode surgir com o mesmo hostname. Relay pode perder, duplicar ou reordenar. Há wrap legítimo. “Sem lacunas” significa apenas nenhuma lacuna observada no intervalo retido, sob identidade e época declaradas.

O recibo amarra contador, processo autenticado, boot, primeiro valor, interpretação do zero, início de recepção, relays e confirmação de persistência.

Os horários respondem a perguntas diferentes

event-time registra a geração, que o rascunho explica como criação e envio da mensagem. A extensão adiciona timestamp para a medição periódica ou mudança observada, e point-in-time distingue current-accounting, initial-state e state-changed.

Isso evita jogar no bucket errado uma medição feita antes da fronteira e enviada depois. Mas formato não certifica relógio. A RFC 6991 define date-and-time, inclusive -00:00 para fuso desconhecido. Precisão decimal não prova sincronização NTP/PTP, rastreabilidade UTC, desvio limitado ou monotonicidade.

Observação, evento, anchor-time, chegada e gravação precisam ficar separados com fonte e incerteza do relógio.

Capability é declaração, não recibo de instância

A RFC 9196 publica capacidades em implementação ou runtime. A revisão 05 acrescenta suporte a envelope, hostname/sequência e observation time. Isso orienta negociação.

Um valor verdadeiro declara suporte. Não prova que a chave global está ligada, que o campo opcional apareceu nessa mensagem, que está correto ou que intermediários o preservam. Suporte, configuração, emissão e custódia são estados distintos.

A chave é global no servidor. Alterá-la encerra todas as subscrições existentes e usa o cabeçalho antigo nas notificações de término. Formatos podem coexistir na rede. O recibo de migração precisa registrar transação, subscrições encerradas, compatibilidade dos receptores e novas épocas.

contents herda as condições da subscrição

A RFC 8639 vincula entrega a filtros, receptores, permissões e ciclo de vida. A RFC 8641 diferencia periodic e on-change, datastore, filtro, anchor, dampening e sincronização. push-update é completa apenas sob os termos da subscrição; push-change-update pode condensar mudanças intermediárias.

O envelope não repete o contrato inteiro. Subscription ID é chave de consulta, não prova da versão efetiva na geração. Filtro, datastore, permissão, trigger ou receptor podem mudar com hostname e sequência ainda suaves. Guarde fingerprint criptográfico da configuração e os eventos que a alteraram.

A RFC 8342 separa intended, running e operational state. Serializar corretamente uma visão não prova encaminhamento, impacto no serviço ou resultado para o usuário.

Custódia posterior exige identidade do conteúdo

O rascunho base diz que contents leva valores inalterados, mas não os assina. NETCONF ou RESTCONF seguro protege uma associação. Depois de decodificar, recodificar, encaminhar, agregar ou armazenar, essa garantia não acompanha automaticamente o payload.

O rascunho de proveniência YANG propõe assinatura COSE calculada exatamente sobre contents. Seus limites são decisivos: a assinatura protege origem e integridade ao assinar, mas não garante frescor, correção de dados de um signatário legítimo, chave não comprometida, assinatura em todos os intermediários ou vínculo confiável de Key ID com fonte autoritativa.

O recibo mantém digest, canonicalização, serialização, signatário, política de chave, verificação, contexto de frescor e transformações. A verdade da observação continua sendo outra pergunta.

Oito recibos sem certeza emprestada

São oito: esquema e escopo da validação; identidade autenticada; continuidade do processo; relógio e incerteza; subscrição e autorização; identidade e assinatura do conteúdo; transporte e custódia posterior; datastore autoritativo e resultado independente.

O envelope torna tudo isso mais fácil de carregar. Não pode deixar hostname tomar emprestada a autenticação, contador tomar histórico durável, timestamp tomar sincronização, capability tomar presença real ou bytes válidos tomarem verdade operacional.