Résumé

  • La révision 07 du transport HTTPS d’IDMEFv2 demande au récepteur de ne confirmer en 2xx qu’après avoir traité le message de manière sûre, par stockage durable ou relais lui-même acquitté.
  • Chaque alerte passe par un POST distinct, mais le projet ne fixe ni l’idempotence d’une reprise, ni la durée de mémoire d’un doublon, ni la décision finale sur l’incident. Ces trois questions exigent un registre commun au consortium.

Le cas difficile commence après l’écriture

La panne la plus révélatrice n’est pas un serveur indisponible. Le gestionnaire reçoit l’alerte, la consigne, commence à répondre 204 No Content, puis la connexion tombe. L’analyseur ne sait pas si l’opération a réussi. S’il recommence, le même signal peut être compté, corrélé ou escaladé deux fois.

Daté du 27 septembre 2026, Transport of IDMEFv2 Messages over HTTPS est un Internet-Draft individuel. Le Datatracker ne lui attribue aucun stream ni statut formel dans le processus IETF. La révision 07 vise le Standards Track et n’abrogerait la RFC 4767 qu’en cas d’approbation. Elle peut encore changer ou disparaître.

Le texte exact de la révision 07 impose un message IDMEFv2 par requête POST, tout en autorisant plusieurs requêtes parallèles. Un message incorrect appelle un 4xx; une incapacité interne de traitement, un 5xx. Surtout, le code HTTP fait office d’acquittement : le destinataire ne devrait répondre en 2xx qu’après sauvegarde sur disque ou en base, ou après un relais vers un système qui a lui-même acquitté.

Le 204 de l’exemple n’est donc pas un simple témoin de chiffrement. La RFC 9110 dit en général que 204 constate l’exécution réussie sans contenu de réponse. Le projet ajoute une convention d’application plus forte : l’alerte a franchi le seuil de traitement sûr.

L’identifiant existe, la politique du doublon non

Le projet du modèle IDMEFv2 exige déjà un ID UUID et un CreateTime au sommet de l’alerte. Un profil de consortium peut donc former une clé à partir de l’identité de l’émetteur et de cet ID. La révision 07 ne précise toutefois ni la fenêtre de déduplication, ni la réponse à un doublon exact, ni le traitement d’un UUID réutilisé avec un contenu différent.

HTTP ne rend pas POST idempotent par magie. La RFC 9110 déconseille la reprise automatique d’une méthode non idempotente, sauf connaissance des sémantiques applicatives ou preuve que la première demande n’a pas été appliquée. La RFC 9205 rappelle aux concepteurs qu’utiliser HTTP oblige précisément à définir ces sémantiques de service.

L’authentification mutuelle répond à une autre question. Le projet exige deux certificats X.509, la validation de chaîne, des DNS-ID sans joker et une liste explicite de pairs admis, dans le cadre de la RFC 5280 et de la RFC 6125. Cela établit l’identité autorisée du pair. Cela ne prouve ni la vérité de l’alerte, ni son unicité, ni sa résolution.

Le registre opérationnel devrait donc conserver trois étapes. Le reçu lie émetteur, UUID, empreinte du contenu et instant de stockage. La décision de déduplication distingue répétition identique, collision et correction. La disposition ultérieure documente corrélation, escalade, rejet ou clôture. Chaque membre peut garder son outil de réponse, tout en partageant la signification du reçu.

Running-Code Primacy place la preuve dans cette séquence observable, non dans la seule conformité déclarée. Minimum Initial Specification, Localized Future Decision justifie une enveloppe minimale commune et des décisions de réponse locales. Enfin, On Authority, Belief, and the Internet’s Addressing System aide à ne pas confondre les émetteurs d’autorité : le certificat nomme un pair, le 204 acquitte une prise en charge, l’analyste juge un incident.