Resumo

  • O diretório inventariava protocolos que a sonda já sabia decodificar e contar; não era uma biblioteca de parsers para download.
  • A “extensibilidade limitada” acrescentava um discriminador filho somente quando o código já conhecia o campo de demultiplexação do protocolo pai.

O exemplo do UDP 123 começa depois de quase todo o trabalho difícil. O código da sonda já entende encapsulamentos Ethernet, IP, o campo de protocolo do IP, UDP e os campos de porta. Sua tabela conhece 161 como SNMP, 53 como DNS e 69 como TFTP. Um gerente pode então cadastrar 123 como NTP e contar correspondências.

Essa linha não instala um decodificador de NTP. As fronteiras até a porta UDP foram escritas no software durante a implementação. A configuração oferece apenas mais um valor numa bifurcação já preparada para consulta em tabela. A RFC chamou isso de extensibilidade limitada porque dependia dessa preparação e não avançava além de um nível.

Inventário antes de configuração

A seção 5.2 define o diretório como inventário dos tipos que a sonda pode monitorar. A protocolDirTable lista protocolos que o agente tem capacidade de decodificar e contar. Ele inicia com os protocolos que conhece e escolhe acompanhar; não precisa enumerar todo EtherType possível nem criar uma entrada ao simplesmente observar um valor.

Se o gerente envia um protocolDirID que o agente não compreende direta ou algoritmicamente, o SET deve ser rejeitado. A tabela é mutável dentro do reconhecimento implementado; não cria reconhecimento novo.

protocolDirID representa o caminho hierárquico de encapsulamento. protocolDirParameters fornece um byte por nó, na mesma ordem, para qualificar esse caminho. protocolDirLocalIndex é uma referência local atribuída pelo agente às tabelas seguintes: única apenas naquela entidade SNMP e não reutilizável após exclusão até a reinicialização. Não é identidade global.

protocolDirType também descreve capacidade. O bit extensível permite filhos, mas um filho sem suporte embutido não pode continuar crescendo. Reconhecer endereços exige lógica além de contar o protocolo; por isso extensões criadas pelo gerente devem marcar o mapa de endereços como notSupported.

O limite chega aos contadores

A distribuição acumulava pacotes e octetos pelo protocolo mais alto detectado. Tabelas de hosts e matrizes usavam índices locais para identificar formato de endereço e protocolo reconhecido. Elas dependiam das capacidades e opções anteriores.

Um contador prova uma correspondência num caminho implementado. Não prova interpretação completa da carga, processo, transação, entrega, responsabilidade ou segurança. “Application Level” tampouco significava necessariamente camada 7 do modelo OSI; abrangia protocolos além das camadas MAC e de rede.

A RFC 2074 publicou algoritmos e exemplos. A RFC 2895 a substituiu em 2000 como referência normativa, enquanto a RFC 2896 separou macros não normativas, disse que elas não eram necessárias para conformidade e registrou o fim de sua manutenção. Mais nomes não viraram mais código.

A RFC 3796 identificou dependência de IPv4 na representação de endereços da RFC 2021. A RFC 4502 tornou a RFC 2021 obsoleta em maio de 2006, preservou o modelo de extensibilidade limitada e revisou relatórios de alta capacidade e limites de tamanho. O único errata verificado corrige números trocados nas ações de download para RAM e PROM, sem alterar o diretório.

O diretório tinha utilidade real: mostrava e configurava distinções que já existiam no agente. Seu nome não herdava a capacidade do código em execução.

Fontes