Resumo

  • A RFC 1444 distinguiu OBJECT-GROUP, MODULE-COMPLIANCE e AGENT-CAPABILITIES: vocabulário, contrato mínimo e alegação de uma versão de produto.
  • As três construções pertenciam ao momento de implementação, não eram uma atestação dinâmica do agente.
  • O objeto ainda precisava devolver valor razoavelmente exato, expor uma exceção honesta quando ausente e, se gravável, influenciar a entidade gerenciada.

Três sentidos para “suporta”

A RFC 1444 recusou a ideia de que uma MIB inteira pudesse caber em uma única caixa de seleção. OBJECT-GROUP reuniu objetos relacionados. MODULE-COMPLIANCE declarou o conjunto mínimo necessário para alegar conformidade. AGENT-CAPABILITIES descreveu o apoio preciso que o implementador atribuía a uma versão, inclusive variações.

Um grupo podia ser obrigatório, obrigatório somente sob uma condição ou opcional. Um objeto podia ter sintaxe de leitura restrita, sintaxe diferente para escrita ou um acesso mínimo específico. A ficha oficial registra abril de 1993, o status Proposed Standard e a posterior substituição pela RFC 1904.

O valor do desenho era tornar a afirmação divisível. Em vez de “o produto suporta SNMP”, surgiam perguntas testáveis: qual grupo, sob qual condição, com qual acesso e em qual versão?

O mínimo orientava a implementação

O documento afirma que a expansão das macros ocorria conceitualmente durante a implementação, não em tempo de execução. Elas diziam o que construir e o que a versão alegava conter. Consultar a declaração não consultava cada objeto vivo.

Nos MANDATORY-GROUPS, a obrigação era completa. Um agente que alegasse conformidade precisava implementar todos os objetos. Se um objeto obrigatório respondesse noSuchObject em todas as MIB views, o agente não seria uma implementação conforme. Cláusulas GROUP definiam condições, como a presença de determinado protocolo.

Essa precisão localiza o teste. Ainda é preciso observar se a condição existe, qual view o principal recebeu e se o serviço do objeto está operacional.

O identificador apontava para uma ficha

AGENT-CAPABILITIES podia associar a descrição da versão a sysObjectID ou a uma instância de snmpORID. A estação de gerenciamento lia o identificador, procurava uma entrada em sua base e otimizava o comportamento. Para agentes que aprendiam objetos dinamicamente, o identificador geral do sistema talvez não bastasse; identificadores de recursos operacionais ofereciam detalhe adicional.

Com isso, a aplicação evitava chamadas impossíveis, respeitava objetos somente de leitura, limitava valores à sintaxe anunciada e fornecia os campos exigidos na criação de linhas.

Mas o OID abria a ficha escrita pelo implementador. Não abria o estado interno do processo. Função desativada, view restrita, defeito de execução ou valor incorreto continuavam possíveis. A declaração diminuía o custo da investigação; não produzia o veredito.

A variação era parte da verdade

O exemplo da própria RFC registra um objeto não implementado, objetos de sintaxe restrita, um objeto apenas para leitura, conjuntos de valores diferentes para ler e escrever e uma célula exigida na criação. Assim, “parcial” ganhava conteúdo técnico em vez de virar evasão.

Mudanças semânticas também ganhavam identidade. Uma alteração não editorial em grupo, definição de conformidade ou capacidade exigia novo descritor e novo OID. Reutilizar o identificador permitiria que duas épocas lessem contratos diferentes sob o mesmo nome.

A execução encerrava a discussão

Para RFC 1444, implementar um objeto significava devolver um valor razoavelmente exato em uma leitura. Quando gravável, ele precisava influenciar razoavelmente a entidade subjacente após um set. Se não pudesse ser implementado, o agente deveria retornar exceção ou erro, jamais fabricar um valor.

Há, portanto, quatro provas. A ficha identifica o que uma versão alega. View e acesso identificam o que o solicitante pode alcançar. O protocolo entrega valor, exceção ou erro. Uma observação independente verifica exatidão, efeito e persistência.

Um número recebido não demonstra sozinho que o contador está certo. Uma resposta de sucesso a Set não demonstra sozinha que a interface mudou ou permaneceu após reiniciar. noSuchObject também não pode virar zero para manter o gráfico bonito. A ausência precisa continuar visível.

O sucessor não transformou alegação em telemetria

O registro da RFC 1904 mostra a substituição de 1996. O registro da RFC 2580 mostra a de 1999. A RFC 2580 preservou a arquitetura: um grupo alegado exigia todos os seus objetos ou notificações, e o conjunto de sysORID ajudava a estação a consultar declarações de capacidade sem virar atestado dinâmico.

Segurança era outra fronteira. A RFC 1444 não discutia o tema. A RFC 3410 registrou depois que o framework SNMPv2 anterior não cumprira metas de autenticação, privacidade, autorização, controle de acesso e administração, deficiências tratadas por SNMPv3.

A formulação de Lu Heng sobre a primazia do código em execução ordena os estados: publicar, implementar, validar, adotar e usar não são um só evento. A nota sobre camadas de realidade impede que força declaratória seja confundida com efeito executável.

RFC 1444 tornou as declarações mais úteis ao limitar o que elas podiam dizer. O cardápio orientava. O prato ainda tinha de chegar.

Fontes