Resumen

  • El borrador draft-ietf-nmop-network-incident-yang-14 mantiene separados el ciclo de la instancia de red y el ciclo del operador, y permite que una RPC incident-resolve incluya varios números de incidente.
  • El éxito aparece más tarde en una notificación independiente. La revisión oficial de YANG Doctors advirtió que no se puede correlacionar qué notificación procede de qué RPC.
  • Un recibo de la orden al estado cleared debe enlazar petición, autorización, objetivos, ejecución, evento, ticket y prueba de servicio, sin exponer topología sensible. Es una propuesta editorial.

El identificador correcto puede responder a la pregunta equivocada

Un número de incidente cumple una función esencial: mantiene reconocible una instancia mientras recibe actualizaciones. El borrador de NMOP también usa el trío nombre, tipo y calificador como clave de lista, y permite que las RPC y las notificaciones se refieran al incident-no.

Esa identidad indica qué registro recibió el cambio. No identifica la invocación que lo ocasionó. Si dos controladores piden una resolución, si el servidor se cura por sí mismo o si una actualización de topología altera la causa probable, la siguiente notificación puede ser auténtica y seguir sin contestar cuál de esos caminos produjo el estado.

La diferencia es pequeña en una maqueta y decisiva en producción. Una auditoría no pregunta únicamente si el incidente 57 acabó en verde. Pregunta quién tenía autoridad, qué operación se autorizó, qué alternativa se descartó, cuál fue el resultado por objetivo y qué observación confirmó la restauración.

Dos relojes internos y un tercero en el OSS

La revisión 14 define dos ciclos. La instancia de incidente pasa por raised, updated y cleared. La actuación del operador pasa por acknowledged, diagnosed y resolved. Esa separación evita afirmar que un cambio de señal y una decisión humana son el mismo hecho.

El texto añade un tercer reloj al exigir integración con el sistema de tickets. Recomienda una capa de traducción determinista entre los estados YANG y estados como Open, Assigned, In-Progress y Resolved. Sin ella puede aparecer una vista dividida: el plano de red cierra mientras el ticket sigue abierto, o al revés.

Sin embargo, sincronizar nombres no establece causalidad. Si la regla convierte siempre cleared en Resolved, el tablero será consistente, aunque no se sepa qué orden produjo el estado original ni si el servicio que importa al cliente volvió realmente.

Una respuesta diferida necesita su propio vínculo

incident-resolve acepta una lista de números. El servidor puede recibir el pedido y comunicar el resultado posteriormente mediante una notificación separada. El borrador deja fuera de alcance el método concreto de resolución. También reconoce que la acción puede afectar servicios en funcionamiento y que el cliente puede no ejecutarla si el impacto no es trivial.

La revisión temprana de YANG Doctors fue precisa: los resultados de las RPC se envían por notificaciones, pero no hay forma de correlacionar cuáles nacen de cada RPC. La revisión, calificada Almost Ready, pide además claridad sobre máquinas de estados, identificadores, listas vacías, errores y dirección de la notificación. Señala que una iteración aún no publicada tendría que revisarse.

Por eso no cabe convertir el comentario en una acusación a implementaciones inexistentes. No hay en las fuentes una caída, una acción indebida ni un operador afectado. Lo que sí existe es un límite comprobable en la interfaz publicada y una pregunta abierta dentro del proceso de revisión.

El control de acceso protege el verbo, no la historia completa

El modelo se usa sobre NETCONF o RESTCONF con transporte seguro y autenticación mutua. NACM permite restringir usuarios, operaciones y contenido. El borrador enumera errores de resolución: causa probable sin resolver, permiso denegado, tiempo agotado y recursos no disponibles.

Esa combinación puede demostrar que un principal autenticado tenía permiso para invocar el verbo y que la frontera síncrona aceptó o rechazó la petición. No demuestra que una notificación posterior sea su consecuencia. Tampoco muestra quién aprobó el impacto, qué cambio concreto ejecutó el servidor o qué prueba de servicio justificó cerrar el ticket.

La confidencialidad importa. Los datos de incidentes pueden revelar el estado roto de la red, y una avalancha de llamadas de diagnóstico o resolución puede consumir recursos. El remedio no debe publicar comandos ni mapas internos. Debe conservarlos bajo acceso controlado y exponer sólo un resumen mínimo de autoridad, tiempo, clase de acción y calidad de correlación.

Los lotes convierten una laguna técnica en una decisión de reparto

Cuando una RPC apunta a varios incidentes, la respuesta puede fragmentarse. Un objetivo se despeja por la acción prevista; otro por conmutación automática; otro falla por falta de recursos; un cuarto queda en estado updated. Atribuir todos los verdes al mismo pedido favorece al componente que emitió la orden y borra el trabajo de protección local o del equipo humano.

También puede perjudicar a quien actuó con prudencia. Si un cliente decide no remediar porque el impacto no es trivial, el incidente podría desaparecer después por otra ruta. Sin un vínculo, el sistema puede presentar como éxito de automatización lo que fue una renuncia deliberada o una recuperación independiente.

El borrador advierte además que la topología obsoleta degrada el análisis de causa e impacto. Una nueva vista de dependencias puede reclasificar el incidente. El estado cambia, pero no necesariamente porque la orden reparó la red.

El expediente de estándares sigue abierto

La llamada final del grupo NMOP comenzó el 19 de agosto y terminó el 3 de septiembre. En la fotografía del 9 de septiembre, Datatracker aún mostraba In WG Last Call, sin AD responsable ni fecha de telechat. La revisión 14 es un Internet-Draft de Standards Track, no un RFC ni una decisión final del IETF.

La validación YANG del 7 de septiembre informó cero errores y cero advertencias. Es buena evidencia sobre la forma del módulo. No es una prueba de interoperabilidad o de trazabilidad causal. Las actas de IETF 126 registran preguntas sobre la clave, el número y el identificador del incidente, pero no autorizan a inventar una conclusión posterior.

Diseñar un recibo que no fuerce el relato

El recibo de la orden al estado cleared asigna una identidad única a cada invocación. Captura los incidentes y revisiones vistos al decidir, el principal y su rol, las versiones de NACM y de política de cambio, el impacto previsto, la aprobación y la alternativa elegida.

Después conserva aceptación o error por incidente, versión de servidor y modelo, reintentos y particiones del lote. Cada notificación se vincula a la invocación o se clasifica honestamente como cambio independiente o correlación desconocida. El ticket añade su regla de traducción, actor y tiempo; la validación de servicio añade el resultado para usuarios, el residuo, el retorno y las correcciones.

La propuesta no modifica el protocolo. Es un registro de control que puede vivir fuera del dispositivo. The Policy Mirror separa dónde se escribe permiso, solicitud, observación y cierre. Running-Code Primacy exige probar la unión ejecutada. Reality, Not Advocacy permite una respuesta incómoda pero correcta: el incidente se despejó y no sabemos qué orden lo hizo.

Fuentes