Resumo

  • IDs de publicador e mensagem, números de segmento, marcador final e janela de aceitação comprovam o que um receptor montou; não revelam tudo que sumiu antes de existir uma sequência observável.
  • Uma conclusão confiável precisa de recibos distintos para associação, remontagem, continuidade, identidade, contexto da assinatura, tempo, segurança de carga e correspondência com estado operacional autorizado.

O segmento 2 chega antes do 1. Seu bit L informa que ele é o último; o receptor espera, ordena 0, 1 e 2, concatena e entrega uma notificação. É um êxito legítimo do mecanismo. Não é prova de que toda a telemetria existiu, chegou e manteve o mesmo significado.

A revisão 26, de 29 de julho de 2026, define uma associação UDP unidirecional para assinaturas configuradas em redes controladas. Cada datagrama sem fragmentação IP leva uma mensagem ou um segmento, sem retransmissão esperada. O Datatracker a registra como Internet-Draft ativo do grupo NETCONF, destinado a Proposed Standard; o histórico mostra sua evolução. Ainda não é RFC.

O objeto que a remontagem realmente prova

Segmentos da mesma mensagem compartilham Message Publisher ID e Message ID. Segment Number começa em zero e não dá volta; L marca o fim e declara a quantidade esperada. O receptor aceita desordem, elimina duplicatas, aguarda o conjunto e concatena em ordem. As demais opções só são obrigatórias no primeiro segmento.

Isso estabelece que um receptor construiu uma sequência de bytes sob certos cabeçalhos. Não demonstra que duplicatas do mesmo número eram idênticas, que o primeiro segmento não foi substituído nem que as chaves pertenciam ao mesmo período autêntico do processo. O recibo deve guardar hashes de segmentos aceitos e rejeitados, conjunto 0..L, opções iniciais, hash final, tempo e orçamento de memória.

O rascunho exige suporte a pelo menos 96 KB e 64 segmentos no receptor; recomenda menos de 64, remontagem em dez segundos e limite absoluto de vinte. Perder um fragmento invalida a mensagem inteira. A fragilidade da fragmentação IP em RFC 8900 é evitada, mas a amplificação da perda continua.

Continuidade depende de onde a observação começa

Message ID começa aleatório, cresce de um em um e retorna a zero depois do máximo de 32 bits. Uma lacuna pode revelar perda numa época estável. Uma mensagem perdida antes do primeiro ID visto não cria lacuna. O receptor pode estar desligado quando a assinatura entra em vigor. Reinício, reutilização de Publisher ID, relé, indisponibilidade, wrap e avanço da janela redefinem “contínuo”.

O coletor pode comparar entregas com sent-event-records de RFC 8639. A diferença sustenta uma inferência de perda somente com mesma assinatura e época. Duplicatas de uma mensagem completa e itens fora da janela não contam como falhas de entrega; exigem métricas diagnósticas separadas.

Uma chave de correlação não autentica autoridade

Message Publisher ID identifica um processo e só é localmente único no nó. Se a unicidade não atravessa o domínio de coleta, inclui-se IP de origem; relés devem preservá-la. Esses dados correlacionam, não autenticam. Sem proteção inferior, o rascunho exige transporte seguro e descreve DTLS. RFC 9147 protege a associação DTLS 1.3 contra alteração e replay e autentica seus pares.

Mesmo assim, o par pode não ter autoridade para aquela assinatura ou mudar após reinício. RFC 8341 mantém autorização de gestão separada. É preciso ligar dispositivo, processo, época de credencial, domínio de unicidade, tupla de rede, relé, decisão de janela e autoridade da assinatura.

O cabeçalho não carrega todo o contexto

O tipo de mídia distingue JSON, XML, CBOR e codificação privada. Alvo, filtro, gatilho, período, amortecimento, receptor e versão ficam na assinatura. RFC 8641 faz desses parâmetros o significado de YANG-Push. IDs podem continuar perfeitos enquanto uma alteração muda o que está sendo observado.

Também há vários tempos: evento, envio, chegada e fim da remontagem. A ordem de Message ID não prova relógio correto nem causalidade. O recibo temporal precisa incluir fonte do relógio, incerteza, marcas e versão da assinatura.

Checksum UDP e DTLS protegem bytes, não unidades, atualidade ou semântica YANG. RFC 8342 separa running, intended e operational. Uma notificação fiel ao publicador pode não ser a visão autorizada para a decisão. A última prova deve observar por outro caminho o dispositivo, rota, fila, interface ou serviço.

Integridade inclui o impacto no caminho

RFC 8085 limita usos volumosos de UDP. A revisão 26 exige capacidade reservada e QoS, recomenda CS2, pacing e taxas padrão limitadas. Um fluxo intacto que esgota memória do receptor ou prejudica tráfego de gestão falhou operacionalmente.

A cadeia exige oito recibos: associação; conjunto de segmentos; continuidade; fonte autenticada; assinatura e codificação; tempo; checksum, DTLS, taxa e QoS; estado autorizado e resultado independente.

Fontes e limite de revisão

O contexto inclui RFC 8639, RFC 8641, RFC 8342, RFC 8341, RFC 8085, RFC 8900 e RFC 9147. Revisões históricas deram Ready with nits à TSVART sobre -23, Has issues à OPSDIR sobre -21 e On the right track aos YANG Doctors sobre -20. Nenhuma julga novamente a revisão 26.