Resumo

  • udpSafeOptions e udpUnsafeOptions marcam cada tipo visto ao menos uma vez nos pacotes reunidos em um Flow; não contam ocorrências.
  • As listas de ExID preservam quais experimentos foram observados e prevalecem sobre os bits genéricos EXP e UEXP, sem virar uma linha do tempo.
  • O registro só é interpretável com ponto de observação, limites do Flow, seleção, Template, estado do Exporter e recebimento pelo Collector. Observação não é execução no destino.

Uma fotografia de conjunto

RFC 9870 descreve opções UDP como ocorrências por pacote que podem surgir a qualquer momento de um Flow. Na exportação, essas ocorrências entram em dois mapas. O ElementID 525 cobre os Kinds SAFE de 0 a 191; o 526 cobre os Kinds UNSAFE de 192 a 255.

O bit liga na primeira observação. Depois disso, mais dez mil ocorrências não mudam o campo. O mapa também não diferencia uma opção que apareceu no primeiro pacote de outra que só surgiu no fim, nem informa se duas opções viajaram juntas.

Para descoberta e inventário, a síntese é eficiente. Para inferir comportamento, é insuficiente. Um sistema de alerta não pode converter presença em taxa, permanência ou causalidade só porque o formato parece preciso. A precisão do número pertence à pergunta estreita que o padrão definiu.

O caso experimental muda de coluna

RFC 9868 reservou EXP no espaço SAFE e UEXP no UNSAFE. Como um único marcador não identifica experiências concorrentes, RFC 9870 cria udpExID e duas listas: uma para ExIDs SAFE observados e outra para UNSAFE.

Quando a lista SAFE aparece, ela própria comprova que EXP foi observado e o Exporter não deve também marcar o bit EXP naquele Flow. A lista UNSAFE aplica a mesma precedência ao UEXP. Um consumidor que lê apenas o mapa genérico pode perder justamente a evidência mais específica.

A lista responde “quais identificadores”. Ela não responde “quantas vezes”, “em qual pacote”, “em que ordem” ou “com qual retorno”. Mesmo dois ExIDs preservados podem ter coexistido ou surgido em períodos separados; o campo não escolhe entre essas histórias.

Ausência local não é ausência universal

No IPFIX, um Flow reúne pacotes que passam por um Observation Point durante um intervalo e compartilham propriedades definidas. Assim, zero quer dizer que o Kind não foi observado nesse universo representado, desde que o processo pudesse reconhecê-lo e o registro chegasse completo.

Sem saber o ponto, as chaves, timeouts, seleção ou amostragem e capacidade do medidor, zero não prova que a opção faltou em outra interface, outro período ou nos pacotes não escolhidos. A formulação auditável é “não observado aqui sob estas condições”.

Um também não prova processamento. O medidor viu bytes compatíveis com um tipo. O destino ainda pode ignorar, rejeitar ou nem receber a opção. Proteção do transporte IPFIX, recibo do Collector, interpretação do endpoint e efeito na aplicação precisam de seus próprios registros.

O Template viaja com o significado

O campo SAFE usa o unsigned256 de RFC 9740, porém pode ser transmitido com tamanho reduzido quando os octetos superiores são zero. As listas de ExID usam o basicList de RFC 6313. Guardar o valor sem Template, comprimento, ElementID e revisão semântica separa os bytes de seu contrato de leitura.

Os registros da IANA mantêm os IEs 525 a 529, os Kinds UDP e os ExIDs. Isso torna nomes e números interoperáveis. Não é uma lista de produtos compatíveis, implantações, observações ou decisões corretas.

Fontes