Resumo

  • Quando o startTime pedido antecede as notificações ainda disponíveis, a RFC 5277 permite iniciar o replay no primeiro evento conservado. O marcador replayComplete pode ser verdadeiro mesmo com o começo solicitado ausente.
  • A completude pertence à interseção entre retenção, associação ao stream, filtro e autorização da sessão. Aceite da assinatura, entrega, relógio, persistência e efeito na aplicação pedem recibos distintos.

Um marcador correto pode sustentar uma conclusão errada

O risco não está numa ambiguidade secreta da RFC 5277. O texto dá ao marcador um objeto preciso: todas as notificações de replay aplicáveis àquela assinatura foram enviadas. O erro aparece quando outra camada remove “aplicáveis” e “àquela assinatura” da frase.

Se a investigação pede a partir do instante A, mas a retenção só alcança o instante B, o servidor começa em B. Ele não recompõe A–B, não afirma que nada ocorreu nesse intervalo e não invalida a operação por não conseguir voltar além do próprio log. Ao terminar o conjunto disponível, envia replayComplete.

Por isso, o recibo de uma consulta histórica precisa carregar dois inícios: o solicitado e o efetivo. A diferença entre eles é uma lacuna conhecida. Converter essa lacuna em sucesso por causa de um indicador verde é uma decisão de governança, não uma propriedade técnica.

O ecossistema também evoluiu. A RFC 8639 atualiza o modelo de subscribed notifications e a RFC 8641 converte o esquema de gerenciamento de notificações da RFC 5277 para YANG. A análise aqui delimita a semântica da RFC 5277; não apresenta a arquitetura de 2008 como única prática atual.

A retenção escreve a primeira linha que ainda pode ser lida

Replay é uma capacidade opcional e depende de registro de notificações. A quantidade armazenada e as regras de retenção são escolhas de implementação. É possível anunciar suporte e expor replayLogCreationTime e replayLogAgedTime sem preservar tudo desde a criação do log.

O próprio nome replayLogCreationTime induz atalhos. A data de criação pode ser anterior à notificação mais antiga ainda disponível. O contêiner persiste enquanto seu conteúdo envelhece e sai. Logo, idade do log e profundidade histórica não são a mesma medida.

Uma operação auditável registra geração ou reinício do log, política de retenção, limite de envelhecimento e os primeiro e último eventos realmente observados. Quando o início efetivo avança, esse movimento deve aparecer como redução de cobertura e de capacidade investigativa.

O stream já é uma seleção da realidade

Um stream de eventos é um conjunto de notificações que satisfaz critérios de encaminhamento. O stream padrão NETCONF reúne notificações de eventos NETCONF XML suportadas pelo servidor. Não promete representar cada mudança interna do sistema gerenciado.

Como fontes não padrão são montadas e como eventos internos viram notificações ficam além do escopo da RFC. Um fornecedor pode publicar determinada classe em um stream, em vários ou em nenhum que interesse àquele consumidor. Ausência no stream não equivale a ausência no mundo operacional.

Essa distinção também exige versionar a definição do stream. Atualizações e configurações podem mudar sua composição sem mudar seu nome. Uma comparação histórica que conserva só o rótulo coloca superfícies de observação diferentes sob uma identidade fictícia.

Filtro e acesso produzem passados específicos por sessão

O cliente pode fornecer um filtro em create-subscription. Depois que o elemento de notificação é gerado, o controle de acesso ainda decide se aquela sessão pode recebê-lo. Uma notificação não autorizada é descartada para a sessão.

Dois clientes legítimos podem, portanto, obter históricos diferentes para o mesmo período. Nenhum precisa estar corrompido. Cada resultado é uma projeção do stream, do filtro e da política de acesso vigentes.

O marcador encerra a visão que ficou disponível. Ele não certifica o que o filtro excluiu nem o que a política ocultou. Para reconstruir diferenças, preserve o filtro exato, a identidade autenticada, a geração da política e, quando existirem, as contagens antes e depois de cada fronteira.

Aceitar a assinatura não é acusar o recebimento de cada evento

Uma resposta RPC positiva a create-subscription prova que o servidor aceitou o pedido. As notificações seguintes são unidirecionais; a RFC 5277 não define uma resposta individual para cada uma. Da mesma forma, anunciar a capability comprova suporte ao mecanismo, não geração, entrega ou processamento de um evento específico.

Uma sessão pode cair, uma fila pode perder itens, o decodificador pode rejeitar conteúdo e o armazenamento do cliente pode falhar. O servidor ainda pode ter emitido corretamente o replay e o marcador. Para alegar completude ponta a ponta, o consumidor precisa de checkpoints duráveis, identificadores ou sequência e evidência de persistência.

Também não se deve confundir replayComplete com notificationComplete. O primeiro separa a parte histórica; o segundo encerra uma assinatura com horário de parada. Um painel que reduz ambos a “concluído” apaga justamente a fronteira que permitiria interpretar o estado.

A passagem ao vivo é uma emenda, não um milagre

Sem stopTime, depois de replayComplete o servidor envia as notificações geradas desde a criação da assinatura e então segue com novos eventos. Essa ordem cria uma ponte entre armazenamento histórico e publicação ao vivo.

O marcador localiza a ponte, mas não demonstra sozinho que ela ficou sem perda, duplicação ou reordenação. Quem depende de continuidade deve conservar época do produtor, identificadores, números de sequência quando disponíveis e tempos de envio, recepção e persistência.

eventTime designa quando a fonte gerou o evento. Não é o horário de chegada ao cliente nem um atestado de sincronização do relógio. Ordenar uma lista por esse campo pode ajudar a análise; não converte relógios imperfeitos em causalidade confiável.

O recibo que sustenta uma afirmação limitada

Uma investigação de alto impacto deve reunir:

  • servidor autenticado, sessão NETCONF e identidade do cliente;
  • capability anunciada e resposta de descoberta dos streams;
  • nome, versão da definição e suporte a replay do stream;
  • início e parada solicitados, além do início efetivo;
  • criação, envelhecimento, reinício ou geração do log;
  • primeira e última notificações realmente recebidas;
  • filtro literal e geração da política de autorização;
  • resultado RPC e identidade da assinatura no servidor;
  • replayComplete e notificationComplete com horário de recepção;
  • transição para o fluxo ao vivo e lacunas ou duplicações detectadas;
  • eventTime, envio, recepção, decodificação e persistência; e
  • estado autoritativo ou resultado da aplicação usado na validação.

A frase defensável é: “o replay terminou para os eventos retidos, aplicáveis e autorizados entre B e C”. Tirar esses qualificadores não resume o mesmo fato. Produz uma alegação maior do que a evidência.

Sources