Resumen

  • La revisión 16 decidió mantener el modelo de incidencias independiente de la confianza; la revisión 17 conserva causas probables estructuradas sin incorporar puntuación, productor, versión o calibración.
  • Los borradores NMOP de anomalías sí transportan confianza, preocupación y procedencia del anotador. La pérdida ocurre si la incidencia sobrevive y el registro analítico que la calificaba no.
  • Prioridad, certeza y autorización son ejes distintos. Una reparación automática necesita enlazar evidencia, hipótesis, umbral, revisión de la incidencia, mandato de cambio y resultado observado.

Dos motores, una misma causa aparente

Dos centros de operaciones reciben la misma secuencia: caída de potencia óptica, pérdida de señal y degradación de una VPN. Ambos generan una incidencia con la misma causa probable. En el primero, una regla conocida lleva años acertando en ese tipo de puerto. En el segundo, un modelo recién desplegado aprendió con otra familia de transceptores. El objeto de incidencia puede ser idéntico; la fuerza del juicio no lo es.

Ese contraste explica una modificación pequeña y profunda de draft-ietf-nmop-network-incident-yang. La historia de la revisión 17 registra que el paso de la versión 15 a la 16 mantuvo el modelo independiente de la confianza. La versión 15 describía los documentos vecinos de anomalías como sistemas que puntuaban el resultado con confidence y concern. La versión 16 eliminó esa frase y dejó intacta la relación arquitectónica. La versión 17 continúa así.

El modelo común no afirma que los operadores deban olvidar la confianza. Afirma algo más limitado: la incidencia interoperable no depende de una escala analítica concreta. Esa austeridad evita convertir la métrica de un proveedor o un detector en semántica universal.

La gramática de la causa

El modelo permite crear una incidencia incluso cuando todavía no se conocen sus fuentes. Después del diagnóstico, la lista puede completarse. probable-causes asocia una hipótesis con red, nodo y, si procede, recurso. cause-name usa una identidad estructurada; detail aporta explicación; probable-events referencia eventos relacionados. Dominio, prioridad y categoría son obligatorios.

La ganancia es real. Una aplicación puede distinguir una pérdida de señal de una mala configuración de enrutamiento sin analizar prosa local. La causa tiene un objeto, una clase y vínculos hacia observaciones. Esto reduce ambigüedad sintáctica y facilita la coordinación entre equipos.

Lo que no reduce es la incertidumbre causal. La prioridad no es probabilidad. La categoría no es validación. Un evento relacionado no demuestra que baste para explicar la incidencia. Una identidad YANG garantiza una denominación compartida, no una verdad compartida.

La propia definición del borrador es exigente: la causa raíz probable sería la condición cuya eliminación completa detiene la incidencia y evita que se repita. Una condición contribuyente no basta. Sin embargo, el objeto de causa no registra el ensayo de eliminación, el intervalo sin recurrencia, el contrafactual ni el conjunto de alternativas. La definición fija la aspiración semántica; el dato no certifica por sí solo que se haya cumplido.

Lo que permanece en los registros de anomalías

draft-ietf-nmop-network-anomaly-lifecycle-07 conserva una envoltura distinta. Define confidence entre 0 y 100 para expresar cuán convencido está un detector de que algo es anómalo. Define concern, también de 0 a 100, para indicar cuánto debería preocupar la condición por su efecto potencial. Además registra versión y etapa de la anomalía, identidad y nombre del anotador, si es humano o algoritmo, y su versión.

El proceso se organiza como Detección, Validación y Refinamiento. No trata el primer resultado como sentencia final. draft-ietf-nmop-network-anomaly-semantics-06 lleva estrategia, confidence, concern, tipo y versión del anotador a la representación serializada. Algunos ejemplos permiten confidence nulo: incluso la envoltura puede reconocer que no dispone de una medida.

Cuando esos registros originan una incidencia, el operador necesita una unión durable. De lo contrario, la causa seleccionada atraviesa sistemas y años, mientras la versión del detector, la ventana de observación y las hipótesis descartadas quedan en un almacén efímero.

La normalización produce entonces una paradoja: cuanto más limpia y estable es la etiqueta, más fácil resulta olvidar que nació como hipótesis.

Una puntuación no debe gobernar tres decisiones

Confidence, concern y prioridad no son sinónimos. Un pico previsto puede ser detectado con mucha confianza y tener poca importancia. Una señal débil de fallo en un enlace crítico puede tener confianza baja y preocupación alta. La incidencia puede recibir prioridad crítica por el daño posible aunque la causa principal siga abierta.

Los valores tampoco son portátiles sin contexto. Un 85 de una regla física no equivale necesariamente a un 85 de un modelo estadístico. Cambian la población de referencia, el horizonte, el coste de falsos positivos, la calibración y el umbral de acción.

Por eso, añadir un solo número al núcleo no resolvería el problema. La independencia del modelo evita una falsa homogeneidad. La disciplina operativa consiste en conservar la semántica completa de cada valor fuera del núcleo y no reemplazarla por un color de panel.

Seguridad de acceso y calidad del diagnóstico

La revisión 17 sitúa el modelo detrás de protocolos YANG con transporte seguro y autenticación mutua. NACM limita qué usuarios pueden ver contenido o invocar operaciones. Es una defensa necesaria porque la incidencia puede revelar servicios de clientes, puntos afectados y la forma de una avería.

Pero un usuario autenticado no vuelve cierta una hipótesis. La autorización responde quién puede actuar y sobre qué. La confianza responde cuánta evidencia respalda una clasificación bajo un método. El resultado de servicio responde qué ocurrió después. Una plataforma madura guarda los tres recibos por separado.

Permitir que un score active directamente un cambio daría poder institucional a una métrica local. Permitir que una identidad de causa active el mismo cambio sin su envoltura sería aún peor: el sistema ya ni siquiera sabría qué duda acompañó la decisión.

Código declarado, prueba pendiente

El borrador menciona una implementación Huawei iMaster NCE con RESTCONF, ciclo de vida de incidencias, notificaciones y consulta de lista. La información importa: demuestra que el documento no vive sólo en diagramas.

La sección también limita la afirmación. Los datos fueron aportados por colaboradores, no verificados por el IETF; la inclusión no implica respaldo ni forma un catálogo completo. No hay en las fuentes congeladas una medición de exactitud, una prueba de calibración o una traza de interoperabilidad que demuestre la conservación de confidence y procedencia al crear la incidencia.

La pregunta para el código en ejecución es concreta: ¿puede un auditor reconstruir qué versión del analista eligió la causa, con qué evidencia, alternativas y umbral?

El tema que ya pertenece a otro artículo

A Cleared Incident Does Not Prove Which Command Cleared It cubre el hueco de la revisión 14 entre una solicitud incident-resolve y una notificación posterior cleared. Su problema es atribuir un estado a una orden.

Aquí el problema precede a la orden. Aunque cada acción tuviera un identificador perfecto, no se sabría por qué se creyó la causa si la envoltura analítica desapareció. Y aunque la causa estuviera bien calibrada, seguirían faltando autorización y verificación del resultado. Esta separación impide reutilizar el argumento anterior.

Fuentes