Resumo

  • A RFC 1451 distribuía serviços de monitoramento entre estações SNMPv2 por meio de uma entidade que atuava como gerente e agente.
  • Amostra periódica, cruzamento de limiar, evento e notificação para um contexto remoto ocupavam linhas e tempos diferentes.
  • A linha de notificação expirava se não fosse atualizada; sua perda não significava que o alarme ou o evento haviam sido removidos.

Uma estação trabalhava para outra

A RFC 1451 queria repartir controle e observação em redes grandes ou divididas entre administrações. Uma estação recebia uma solicitação de serviço no papel de agente e executava consultas no papel de gerente.

O desenho usava três tabelas. Alarm configurava variável, intervalo, tipo de amostra e limiares. Event definia o evento e guardava contagem local. Notification associava um evento a um contexto de destino e aos parâmetros de InformRequest. Cada ligação tinha de existir por conta própria.

A leitura pertencia ao período encerrado

No modo absoluto, o valor no fim do intervalo era comparado aos dois limiares. No modo delta, usava-se a diferença entre os finais de dois períodos. snmpAlarmValue só representava o último período concluído; o período corrente não ficava disponível até terminar.

Portanto, a observação não era contínua. Uma variação entre dois instantes podia desaparecer antes da próxima leitura. A RFC sugeria um método mais preciso para certos deltas, mas não o transformava em garantia comum a todas as implementações.

O alarme aceitava apenas tipos inteiros específicos. Um resultado fora da faixa de 32 bits com sinal podia ser truncado de forma própria pela implementação. O número visível carregava limites de tempo, tipo e representação.

O serviço delegado não ampliava a autorização

A consulta usava um contexto e um par de partes com acesso permitido pelo modelo administrativo da RFC 1445. A tabela Alarm não podia servir de atalho para uma variável fora da visão autorizada. Configurar monitoramento e ter autoridade de leitura eram relações separadas.

Erro de autorização, objeto ausente ou sintaxe incompatível podia gerar um evento de indisponibilidade e destruir a linha de alarme. Falta de resposta permitia outra escolha: destruir a linha ou retirar apenas o último valor e continuar tentando. A ausência de dado não determinava sozinha o diagnóstico.

A histerese contava mudanças, não permanência

Depois de um evento de subida, outra subida só seria gerada após a amostra cruzar o limiar de descida; o inverso valia para uma queda. Isso impedia repetição contínua perto da fronteira.

Uma estatística continuar alta não era um novo evento. A contagem dependia da direção anterior e do estado de histerese. A primeira amostra após a ativação ainda podia seguir uma política própria de alarme inicial.

O cruzamento podia não ter evento

As condições de subida, queda e indisponibilidade apontavam para índices da tabela Event. Zero significava ausência de associação. Um índice sem linha correspondente também não gerava evento. O detector podia estar ativo, mas o próximo elo não estar montado.

A linha Event guardava OID de tipo, número de gerações e sysUpTime local da última. Esses campos descreviam o originador. Não contavam recebimentos em outros gerentes.

Repetir tinha limites locais

A Notification vinculava evento e contexto de destino. O solicitante indicava intervalo e número de retransmissões. A entidade podia elevar o intervalo ao mínimo que suportava e reduzir o total ao máximo disponível. Pedido e execução não eram a mesma coisa.

O InformRequest contemporâneo vinha da RFC 1448. A formulação posterior da RFC 3416 chama o Inform de mecanismo confirmado, mas sem garantia de entrega. Se recebido validamente, o conteúdo é entregue à aplicação apropriada e uma resposta é gerada. Isso não confirma o fato físico nem a correção do problema.

A relação tinha 86.400 segundos por padrão

snmpEventNotifyLifetime diminuía em segundos. Ao chegar a zero, o estado da linha mudava para destroy. A estação interessada precisava atualizar o valor periodicamente para preservar a entrega de eventos.

O prazo pertencia à ligação entre Event e destino. O texto não mandava apagar o Alarm ou o Event quando uma Notification expirasse. Uma estação podia continuar amostrando e somando eventos enquanto um leitor específico deixava de receber.

Historic não significa observação de uso

O registro da RFC 1451 hoje a classifica como Historic. O próprio documento diz que não discute segurança. Isso não permite afirmar adoção, proteção ou retirada de nenhum produto real.

A RFC 3413 organizou mais tarde originadores, receptores, alvos, filtros e proxies. Ela delimita a evolução, sem ser apresentada como substituição direta nem como parte do projeto de 1993.

Fontes