Resumo

  • A RFC 3433 exigia tipo, escala decimal e precisão para interpretar entPhySensorValue; estado operacional, timestamp e taxa de atualização delimitavam se o inteiro podia representar uma observação atual.
  • Taxa zero podia significar atualização sob demanda, orientada a evento ou taxa desconhecida. ok(1) dizia apenas que o agente conseguia obter o valor. Calibração, verdade física e processamento de alarmes continuavam fora desse recibo.

O banco tinha um inteiro, não uma temperatura

Uma plataforma recebe 315. Sem contexto, pode ser 31,5 graus Celsius, 315 RPM, 315 watts, uma grandeza relativa ou um valor antigo. O formato cabe numa coluna; o significado não.

A RFC 3433, de dezembro de 2002, definiu a Entity Sensor MIB. O texto, o registro do RFC Editor, a página IETF, o histórico, as referências e a busca de erratas descrevem um contrato Standards Track, não o estado de um equipamento atual.

A tabela ampliava de modo esparso as entidades físicas classificadas como sensor(8) e reutilizava o mesmo entPhysicalIndex. A base histórica era a Entity MIB da RFC 2737; a versão posterior da RFC 6933 manteve o modelo de identidade física. Antes de interpretar a medida, era preciso saber a qual componente o agente a atribuía.

Três campos davam semântica ao valor

O tipo distinguia tensão, corrente, potência, frequência, Celsius, umidade, RPM, fluxo de ar, verdade lógica, outro e desconhecido. A escala acrescentava uma potência de dez entre yocto e yotta. A precisão indicava casas decimais fixas ou dígitos corretos.

Num sensor de temperatura em décimos, tipo Celsius, escala units e precisão 1 faziam 315 significar 31,5 graus. Mudar qualquer parte criava outra afirmação.

Para tipos de ponto fixo, um bilhão negativo e um bilhão positivo eram sentinelas de subfluxo e sobrefluxo. Não eram medições extremas. A curva que descartava essa distinção convertia erro em observação.

O vocabulário vinha do SMIv2: RFC 2578 para estrutura, RFC 2579 para convenções textuais, RFC 2580 para conformidade e RFC 2119 para linguagem normativa.

A errata verificada 2008 corrigiu comentários invertidos: peta(14) equivale a 10^15 e exa(15) a 10^18. Copiar o comentário errado podia alterar uma interpretação em mil vezes.

Precisão de representação não era exatidão metrológica

Na RFC 3433, precision tratava da posição decimal ou de dígitos corretos no valor fixo. Não certificava calibração, incerteza, rastreabilidade nem classe regulatória.

A RFC 7460, sobre energia, tornou a fronteira explícita: as classes de exatidão ANSI/IEC não estavam no modelo da RFC 3433, então foi necessário um objeto separado. Mostrar uma casa decimal não prova erro máximo de um décimo.

entPhySensorUnitsDisplay era texto de apresentação. O software deveria usar tipo e escala, não inferir autoridade de uma legenda.

O status era uma fala do agente

ok(1) significava que o agente conseguia obter o valor. unavailable(2), que não conseguia naquele momento. nonoperational(3), que acreditava haver falha dura ou comportamento fora de faixa, instável ou errático.

Esses estados descreviam conhecimento do agente. Verde não provava calibração, instalação ou verdade física. A introdução de RFC 3410 situa a MIB como armazenamento virtual oferecido por software, não como acesso sem mediação ao fenômeno.

Zero escondia três políticas de atualização

O timestamp guardava o sysUpTime da última obtenção de valor ou status. Uma taxa positiva declarava o intervalo de polling, possivelmente estimado, em milissegundos.

Zero podia significar atualização ao receber a consulta, atualização quando o valor mudava ou desconhecimento da taxa. Duas opções podiam ser recentes; a terceira admitia ignorância. Rotular todas como “tempo real” apagava a incerteza.

Também uma taxa positiva não garantia frescor. Ela permitia comparar idade e intervalo, sem provar instante de conversão ou correção física.

O alarme era externo

A RFC 3433 não definiu limiar especializado. Recomendou mecanismos gerais como Alarm e Event da RMON MIB em RFC 2819.

Leitura, cruzamento de limiar, avaliação, entrega de alerta e ação eram eventos separados. A linha somente leitura não demonstrava regra configurada, notificação recebida, desligamento ou reparo.

Leitura não eliminava sensibilidade

O texto considerou entPhySensorValue potencialmente sensível. SNMPv1 não era seguro por si só; uma rede protegida por IPsec também não definia quem podia acessar cada objeto.

Foram recomendados o USM de SNMPv3 da RFC 3414 e o VACM da RFC 3415. Autenticação, privacidade e visão autorizada não eram prova de exatidão do sensor.

Fontes e limites

A distinção de Heng Lu entre camadas de realidade e código em execução como evidência primária ajuda a separar especificação, agente, resposta, grandeza física, alarme e resultado.

As vinte fontes definem o contrato histórico. Não provam implementação nomeada, adoção, calibração, incidente, violação, entrega de alarme, remediação ou resultado comercial. O mérito da RFC 3433 foi impedir que um inteiro nu se apresentasse como medição completa.