Resumen

  • RFC 1224 aplicó un límite agregado por agente mediante maxAlertsPerTime, windowTime y alertsEnabled.
  • Al superar el límite enviaba un alertsDisabled y suspendía los avisos, aunque ese último mensaje también podía perderse.
  • El registro consultable retenía alertId y alertData; recuperar o borrar una fila no demostraba que el fallo hubiese sido atendido.

Dos formas opuestas de perder visibilidad

RFC 1224 se publicó en mayo de 1991. El registro del RFC Editor lo clasifica como Experimental y el IETF Datatracker conserva su procedencia del grupo Alert-Man. No definía qué medir ni qué debía decir una alarma. Su objeto era el flujo posterior a la generación.

Una entidad averiada podía ser incapaz de comunicar su propia avería. Pero una entidad que sí hablaba podía inundar al gestor con oscilaciones y consumir la capacidad necesaria para controlarla. Por eso el memorando exigía dos cosas a la vez: limitar el exceso y conservar una forma de detectar o reconstruir lo que no llegara.

El SNMP de RFC 1157 funcionaba sobre datagramas no fiables, y la selección de destinos para Trap-PDU dependía de la implementación. RFC 1215 normalizaba la forma de definir traps, pero desaconsejaba con fuerza crear más. La sintaxis de una notificación no era un comprobante de entrega.

El límite fabricaba silencio de manera intencional

El “pin” de RFC 1224 observaba una ventana móvil. maxAlertsPerTime fijaba el número y windowTime el intervalo. La cuenta sumaba todos los tipos de alerta producidos por un agente.

Al arrancar, alertsEnabled estaba activo. Cada alerta generada consultaba ese estado. Si era falso, no se enviaba. Si era verdadero, se transmitía y su hora entraba en el cálculo. Cuando el número configurado quedaba comprimido dentro de la ventana, el agente enviaba una sola alertsDisabled y desactivaba la salida.

La paradoja estaba en el último mensaje: la notificación de que las notificaciones se detenían podía perderse. El gestor debía consultar periódicamente el estado, volver a activarlo cuando procediera y anotar que durante la pausa podían faltar traps. Un periodo sin tráfico dejaba de ser evidencia de que nada ocurría.

La tabla daba custodia temporal

Las alertas consultadas y registradas ofrecían otra ruta. Cada evento local añadía un alertId creciente y una copia OPAQUE en alertData. El gestor podía pedir la fila siguiente o una concreta y, si la implementación lo permitía, retirarla mediante una operación de escritura o borrado. RFC 1189 proporciona el contexto CMOT/CMIP de esas operaciones paralelas.

La tabla ayudaba después de una partición: una condición ya extinguida podía seguir disponible. Sin embargo, la capacidad tenía límite. Al llenarse, la entrada nueva reemplazaba la más antigua. Priorizar la fila más vieja era una defensa contra la pérdida, no una garantía de archivo completo.

alertId demostraba que el agente había asignado un lugar a una copia. No demostraba que la alerta espontánea saliera, llegara, fuese recuperada antes del reemplazo o describiera bien el estado. Borrar una fila tampoco equivalía a reconocerla, abrir una incidencia, reparar el equipo ni verificar el servicio.

La multiplicidad de gestores añadía otra frontera. Distintas comunidades podían ver umbrales, interruptores y copias independientes. La acción de un gestor no era una autoridad universal sobre los demás.

La alarma era una secuencia, no un hecho único

Condición, evaluación, generación, estado del interruptor, cálculo de ventana, intento de envío, entrega, recepción, inserción local, consulta, devolución, borrado, decisión humana y resultado operativo necesitaban evidencias diferentes. RFC 1224 tampoco discutía seguridad; sus SET y DELETE no autenticaban por sí mismos a un actor.

Fuentes