Resumo

  • A RFC 3055 criou uma visão de gestão no servidor para quatro serviços PINT, quatro janelas de tempo e quatro formas de agrupar a atividade.
  • “Bem-sucedida” era uma classificação mantida pelo agente, não prova independente de que alguém atendeu, ouviu o conteúdo ou recebeu um fax legível.

A Internet pedia; a rede telefônica executava

PINT conectava sistemas sem apagar a separação entre eles. Um pedido na Internet podia provocar uma chamada, enviar um fax, buscar por fax um documento da rede telefônica ou ler conteúdo por telefone. Boa parte da execução continuava invisível no PSTN.

O servidor podia aceitar uma solicitação que o gateway recusaria. O gateway podia aceitá-la sem concluir a ação telefônica. Uma chamada estabelecida não garantia audição humana, e o fim de uma sessão de fax não certificava uma folha legível.

Publicada em fevereiro de 2001 como Proposed Standard, a RFC 3055 definiu uma MIB SMIv2 registrada pela IANA como módulo 93 de mib-2. Seu escopo era estreito: desempenho específico de PINT, não gestão dos elementos nem desempenho geral do host e da rede. A limitação localizava o observador.

Quatro serviços, quatro perspectivas

Os serviços eram Request-to-Call, Request-to-Fax, Request-to-Fax-Back e Request-to-Hear-Content. Os períodos cobriam 30 segundos, 15 minutos, 24 horas e desde a reinicialização.

A tabela global contava recebidas, sucessos e desconexões, incluindo falhas atribuídas a autorização, servidor ou gateway. A tabela do cliente usava um endereço textual; a do usuário, UserIdName; a do gateway agrupava por nome registrado.

Não eram quatro testemunhas independentes. O agente rodava no servidor PINT, inclusive ao monitorar conexões com gateways. As perspectivas ajudavam a localizar uma anomalia, mas não criavam uma observação no PSTN ou no terminal final.

O significado situado de “sucesso”

Objetos SuccessfulCalls parecem uma sentença final. Porém a MIB padronizava a forma de uma implementação expor sua classificação; não colocava um observador ao lado de cada telefone e fax.

Aceitação no servidor, entrega ao gateway, execução telefônica, saída física e resultado útil são recibos diferentes. Sem a regra de incremento e evidência posterior, o contador só fala pela camada que o mantém. Essa disciplina não diminui seu valor; impede que o número finja ter visto o que não viu.

Counter32 precisa de continuidade

Os valores eram Counter32. A SMIv2 estabelece aumento até 2^32−1 e retorno a zero, e observa que uma amostra isolada geralmente não contém informação.

Um total não é taxa. A interpretação exige amostras anterior e posterior, horários e continuidade. A RFC 3055 atribuiu ao consumidor o tratamento do retorno a zero no período “desde a reinicialização”. Reinício, coleta perdida e janelas desalinhadas mudam o sentido de um delta.

Trabalhos posteriores da Application MIB tornaram descontinuidades mais explícitas, sem provar que agentes PINT históricos as ofereciam.

Linha ausente não era zero

Tabelas por cliente e usuário podiam consumir muitos recursos. O envelhecimento ficou a critério local e uma visão top-N foi apenas sugerida. Ausência podia significar inatividade, expiração, detalhe não implementado, limite de recursos ou identificador diferente.

UserIdName deveria ser único entre servidores e gateways relevantes. Combinar cliente e horário era uma opção. A chave incorporava política de identidade, não apenas tráfego.

Nenhum trap próprio

A RFC 3055 não definiu notificações. Encaminhou detecção de falhas repetidas e chamadas incômodas a limiares RMON. Mas uma alarme depende de variável, intervalo, modo de amostra, limiares e evento.

Silêncio pode significar ausência de cruzamento ou ausência de configuração, dado ou entrega. Não é recibo de saúde.

Leitura também expunha informação sensível

Somente o contato administrativo era gravável e não havia objetos read-create. Ainda assim, identificadores, relações com gateways, volume e falhas podiam revelar clientes e desempenho comercial. A RFC alertou que SNMPv1 não bastava e recomendou USM e VACM. Criptografia da rede não decide sozinha qual principal lê cada objeto.

RFC 3414 e RFC 3415 substituíram depois os textos citados; isso não prova adoção por uma instalação PINT.

Fontes

Lu Heng não escreveu nem endossou a RFC 3055. Seus ensaios são lentes declaradas. O H. Lu da RFC 2458 não é identificado como o mesmo autor sem prova independente.