Resumen

  • La revisión 07 pide que el receptor no confirme con 2xx hasta haber guardado la alerta de forma segura o haberla entregado a otro sistema que la confirmó; un 204 puede ser un recibo de custodia real.
  • Como cada alerta viaja en un POST y el borrador no especifica idempotencia, ventana de duplicados ni disposición final, los miembros necesitan un libro común basado en la identidad del emisor y el ID obligatorio de la alerta.

La ambigüedad aparece cuando falta la respuesta

Un analizador envía una alerta. El gestor la escribe en su base y prepara 204 No Content. La sesión se corta antes de que el emisor reciba ese resultado. Reintentar parece prudente, pero puede duplicar una señal ya aceptada y disparar dos automatizaciones. No reintentar puede dejar una alerta sin entregar si la escritura nunca ocurrió.

El borrador individual Transport of IDMEFv2 Messages over HTTPS lleva fecha de 27 de septiembre de 2026. El Datatracker lo muestra sin stream ni posición formal en el proceso de la IETF. Su encabezado aspira a Standards Track y sólo reemplazaría RFC 4767 si fuese aprobado. Esta propuesta no es todavía norma ni evidencia de uso.

La revisión 07 exacta manda enviar un mensaje por solicitud POST y permite hacerlo en paralelo. Un mensaje impropio recibe 4xx; un fallo propio del receptor, 5xx. La frase decisiva convierte el código HTTP en acuse: no se debería emitir 2xx sin haber tratado el mensaje de forma segura, por almacenamiento duradero o por un relevo que también lo haya reconocido.

Por eso el ejemplo 204 dice más que “los bytes cruzaron TLS”. RFC 9110 define 204 como cumplimiento exitoso sin contenido adicional. El borrador añade el compromiso de aplicación que delimita qué debe haberse cumplido.

Un UUID no crea por sí solo una política de repetición

El modelo de datos IDMEFv2 exige un ID UUID y un CreateTime para la alerta. Ese ID permite construir una clave estable. Pero el transporte no ordena cuánto tiempo conservarla, si un duplicado idéntico merece otro 2xx ni qué hacer cuando el mismo ID llega con otro hash.

POST tampoco hereda idempotencia del canal. RFC 9110 aconseja no repetir automáticamente métodos no idempotentes salvo que el cliente conozca la semántica o pueda probar que el intento original no se aplicó. RFC 9205 exige que los protocolos montados sobre HTTP definan con cuidado su comportamiento de aplicación.

La autenticación mutua cubre la admisión, no la verdad. El borrador requiere certificados X.509 en ambos extremos, validación completa, DNS-ID sin comodines y una lista explícita de pares aprobados, con apoyo de RFC 5280 y RFC 6125. Así se sabe qué par autorizado habló. No se sabe si la observación es correcta, si se repitió ni si acabó en una respuesta operativa.

La alianza debería separar recibo, deduplicación y disposición. El recibo liga identidad, ID, hash y hora de persistencia. La deduplicación registra primera y última aparición, coincidencia exacta o conflicto. La disposición posterior añade correlación, investigación, escalado o cierre. Compartir esos estados no obliga a centralizar cada SIEM.

Running-Code Primacy centra la prueba en lo que realmente se almacenó y decidió. Minimum Initial Specification, Localized Future Decision permite un recibo interoperable mínimo sin quitar autonomía de respuesta. On Authority, Belief, and the Internet’s Addressing System evita la última confusión: el certificado, el acuse y el juicio del incidente tienen autores y autoridad distintos.