Resumen

  • RFC 3434 exigía leer juntos la magnitud y HcValueStatus: cero con valueNotAvailable(1) registraba un fallo de recuperación, no una medición nula.
  • La fila sobrevivía, los intentos fallidos se contaban y el delta siguiente quedaba sin base; cruce de umbral, asociación de evento, entrega y respuesta seguían siendo hechos diferentes.

El cero que llegó sin observación

Un sistema de datos suele preferir un número a un vacío. Esa preferencia puede convertir una limitación de almacenamiento en una afirmación operacional. RFC 3434 evitó esa conversión mediante una pareja: hcAlarmAbsValue guardaba la magnitud absoluta y hcAlarmValueStatus explicaba si era positiva, negativa o no disponible.

Cuando el agente no podía obtener la variable durante el intervalo, guardaba cero en la magnitud y marcaba valueNotAvailable(1). El cero no describía al contador. Describía la representación utilizada mientras el estado conservaba la verdad. Separar ambos objetos era perder la lectura completa.

El texto plano, la ficha del RFC Editor, el documento del IETF, su historial y sus referencias fijan la procedencia. No prueban uso actual, un fabricante concreto ni una avería real.

La alarma de 32 bits ya no alcanzaba

RFC 2819 había establecido el modelo RMON de muestreo periódico, umbrales ascendentes y descendentes y eventos asociados. Pero su tabla de alarmas estaba ligada a objetos de 32 bits. RFC 2863 mostraba que, con más velocidad, los contadores de octetos se desbordaban demasiado rápido: en el ejemplo citado, unos 34 segundos a 1 Gbit/s.

RFC 3434 creó una tabla independiente para Counter64 y para CounterBasedGauge64, definido por RFC 2856. No cambió retroactivamente el significado de la tabla antigua. Reutilizó la tabla de eventos de RMON, pero mantuvo separado el mecanismo de alarma de alta capacidad.

La magnitud grande tampoco era un solo objeto en todos los casos. Cada umbral se construía con una palabra baja, otra alta y un estado de signo. El módulo era la palabra baja más la alta multiplicada por dos elevado a treinta y dos. La estructura permitía valores positivos o negativos sin confundir el signo con los bits.

Conservar la regla sin inventar la muestra

Una lectura fallida no destruía la fila de alarma. Ese cambio protegía la configuración ante una ausencia transitoria. Además, hcAlarmValueFailedAttempts acumulaba cuántas veces la variable no había estado disponible mientras la fila permanecía activa.

La fila persistente demostraba continuidad de configuración, no continuidad de datos. El contador de fallos demostraba intentos fallidos, no su causa. Podía intervenir una vista de acceso, un objeto inexistente, una condición interna o un problema de tiempo. RFC 3434 no autorizaba elegir una explicación.

En modo absoluto, una muestra válida se comparaba directamente con los umbrales. En modo delta, el valor anterior se restaba del actual. Si faltaba el anterior, el cálculo carecía de minuendo histórico. Una lectura actual correcta no podía reparar ese hueco. El estado del delta debía quedar no disponible.

Así, una sola ausencia tenía dos efectos: el intervalo fallido no aportaba una medición y el intervalo siguiente no podía aportar una variación válida. La continuidad temporal era parte del dato.

El cruce no era el desenlace

Los umbrales ascendente y descendente creaban histéresis. Un evento ascendente se generaba al pasar desde debajo hasta alcanzar o superar el límite superior. No se armaba otro hasta que el valor llegaba al límite inferior. La regla inversa evitaba repeticiones descendentes. La política inicial podía producir un evento único si la primera muestra válida ya estaba fuera del rango.

Sin embargo, el índice de evento podía ser cero, lo que significaba ausencia de asociación. También podía apuntar a un número sin fila real en la tabla. Incluso con asociación, el estándar no convertía el evento en recibo de entrega, lectura humana o reparación.

La secuencia correcta era más larga: recuperar, validar, calcular, comparar, detectar transición, resolver la fila de evento, ejecutar la acción configurada, transportar, recibir y actuar. Cada verbo necesitaba su propia evidencia.

Un puntero con alcance amplio

hcAlarmVariable podía señalar distintos objetos enteros de la MIB. RFC 3434 observó que las vistas SNMP controlaban el acceso, pero no podían limitar adecuadamente el valor del puntero a objetos de una vista concreta. Por eso recomendó escritura solo en vistas que también pudieran leer todos los objetos de la sonda.

RFC 3410 sitúa el marco; RFC 3414 define USM y RFC 3415 VACM. Citar esos controles no demuestra que una instalación los configuró bien. RFC 2578, RFC 2579, RFC 2580 y RFC 2119 explican el lenguaje normativo, no el estado de un dispositivo.

El registro SMI de IANA conserva la asignación, y la búsqueda de erratas acota correcciones conocidas. Ninguno es una medición de adopción.

La diferencia que una exportación puede borrar

La tentación moderna es exportar solo tiempo y valor. RFC 3434 muestra por qué esa pareja es insuficiente. Hacen falta estado, signo, modo, continuidad, identidad de fila y fallos acumulados. El coste de esos campos es pequeño frente al coste de reconstruir una decisión tomada sobre un cero ficticio.

El análisis de Heng Lu sobre capas de realidad ayuda a ver cómo la cifra visible desplaza la condición que la limita. Su defensa del código operativo recuerda que una distinción normativa solo importa si sobrevive en las implementaciones y exportaciones.

RFC 3434 no aseguró que cada alarma llegara a alguien. Sí hizo posible decir, sin contradicción, que la regla seguía allí, la observación faltaba y el cero no había sido medido.

Fuentes