Resumen

  • RFC 9940 ordena una cadena de evidencia en la que Valor, Evento, Fallo, Problema, Síntoma, Causa, Alerta y Alarma conservan significados distintos.
  • Que una alarma se aclare o que un operador la cierre no prueba por sí mismo la causa, el comportamiento completo del servicio ni la autorización del siguiente cambio.

Un umbral se cruza y aparece una alarma. Ese hecho puede salvar minutos valiosos. Pero una organización pierde rigor cuando convierte en una sola afirmación cuatro preguntas diferentes: ¿qué se observó?, ¿qué estado se infirió?, ¿qué lo causó?, ¿quién autorizó la respuesta? El ahorro de tiempo no exige perder esas separaciones.

RFC 9940, documento informativo de la IETF publicado en abril de 2026, define términos para la gestión de fallos y problemas de red, con alcance en la capa de red y las inferiores. Busca que modelos de datos y protocolos de gestión hablen con precisión cuando informan o administran fallos. No establece un protocolo de remediación ni convierte una notificación en mandato sobre otro sistema.

El punto de partida es una Característica, aspecto observable o medible de un Recurso. Un Valor la mide. Un Cambio es la variación de ese valor durante un intervalo; un Evento es una variación en un instante distinguible. Una Condición interpreta valores, y un Estado es una condición de un recurso en un momento. Por eso una lectura no llega al tablero como verdad desnuda: ya carga con una frecuencia de muestreo, un contexto y una interpretación.

La Relevancia depende de política, perspectiva, intención y otros datos. Una Ocurrencia es un Evento o Cambio relevante. Un Fallo es una Ocurrencia indeseada que puede señalar un Estado actual o futuro no deseado. Un Problema es un Estado indeseable que puede requerir reparación y no tiene que corresponder a una Causa única. Un Síntoma indica un Problema; una Causa puede ser indicada o determinada a partir de varios fallos, problemas y síntomas. Una Alerta indica un Fallo. Una Alarma significa un Estado indeseable que requiere atención correctiva.

La diferencia persiste aun cuando el servicio parece normal. El ejemplo de pérdida de luz en RFC 9940 permite que los servicios se recuperen mientras el fallo reciente sigue sin explicación. Reparar una microcurvatura puede resolver una causa inmediata, pero no necesariamente el problema de impedir su repetición. La vuelta del tráfico es evidencia de una condición posterior; no borra el historial ni convierte una hipótesis en causa comprobada.

RFC 8632 formula una cautela práctica: sus recursos de causa raíz son candidatos, es decir, pistas para el cliente. Además distingue is-cleared, estado de la alarma, de closed, estado del operador. Que desaparezca la condición observada y que alguien considere exitoso el trabajo correctivo pueden coincidir, pero no son el mismo dato. Ninguno demuestra por sí solo cobertura de la medición, causalidad o experiencia de cada servicio dependiente.

También importa no llamar intención a la telemetría. RFC 9940 describe una cadena de telemetría, monitorización, analítica y observabilidad; los datos telemétricos no contienen por sí solos la definición del servicio. RFC 9315 trata la intención como metas y resultados declarativos que una red no conoce por instinto. RFC 9417 mantiene separados métrica, síntoma, puntuación de salud y métrica no disponible. Una puntuación puede ordenar una investigación; no autoriza automáticamente retirar rutas, facturar, cerrar un incidente o prometer un resultado.

Daniel Kade usa la distinción de capas de realidad de docs/heng-lu-note.md como lente editorial, no como una regla nueva de la IETF. El registro robusto preserva la lectura, el umbral, la política, la clasificación, la hipótesis causal, la decisión autorizada, el cambio y la observación posterior. Así, una alerta sigue siendo rápida sin pretender que ya contiene toda la verdad necesaria para actuar.

Fuentes