Кратко

  • В revision 07 получатель не должен отвечать 2xx, пока не обеспечил безопасную обработку: постоянное хранение или передачу следующей системе, которая сама подтвердила приём. Поэтому 204 No Content может служить содержательной квитанцией.
  • Каждая тревога передаётся отдельным POST, но проект не определяет идемпотентность повтора, срок памяти о дубликате и итог расследования. Альянсу нужен собственный реестр на основе личности отправителя и обязательного Alert ID.

Ответ может пропасть уже после успешной записи

Analyzer отправляет тревогу. Manager завершает commit в базе и начинает возвращать 204. Если соединение оборвётся до получения строки состояния, отправитель не узнает, применён ли запрос. Повтор способен создать две корреляции и две автоматические реакции; отказ от повтора рискует потерять сообщение, если commit не состоялся.

Transport of IDMEFv2 Messages over HTTPS датирован 27 сентября 2026 года. Это индивидуальный Internet-Draft без stream и формального места в процессе стандартизации IETF, что прямо показывает Datatracker. Revision 07 нацелена на Standards Track и заменила бы RFC 4767 лишь после одобрения. Пока это изменяемое предложение, а не стандарт или факт внедрения.

Точный текст revision 07 требует отдельный POST для каждой IDMEFv2 message и разрешает параллельные запросы. Некорректное сообщение получает 4xx; внутренняя неспособность получателя обработать его — 5xx. Главное правило называет HTTP code подтверждением: 2xx следует выдавать только после записи на диск или в базу либо после передачи системе, которая подтвердила дальнейший приём.

Поэтому 204 в примере говорит больше, чем успешный перенос байтов через TLS. RFC 9110 в общем случае означает этим кодом успешное выполнение без дополнительного содержимого ответа. Проект IDMEFv2 добавляет прикладную нижнюю границу безопасного результата.

Обязательный UUID ещё не создаёт политику дедупликации

Сопутствующий проект модели данных IDMEFv2 требует верхнеуровневые UUID ID и CreateTime. Вместе с сертификатной личностью отправителя ID подходит для устойчивого ключа. Однако транспортный документ не говорит, как долго помнить ключ, что отвечать на точную копию и как трактовать тот же ID с иным хэшем.

HTTP сам не делает POST идемпотентным. RFC 9110 не рекомендует автоматически повторять неидемпотентный метод, если клиент не знает, что прикладная семантика идемпотентна, или не способен установить, что первый запрос не был применён. RFC 9205 именно поэтому требует от протоколов поверх HTTP явно описывать собственные эффекты.

Взаимная аутентификация отвечает за допуск, а не за истинность. Проект опирается на RFC 5280 и RFC 6125, требуя X.509 у обеих сторон, полную проверку цепочки, DNS-ID без wildcard и явный список разрешённых сертификатов. Это показывает, какой уполномоченный участник говорил. Это не доказывает новизну тревоги, достоверность наблюдения или завершение расследования.

Общий контроль разумно разделить на три записи. Квитанция приёма связывает peer, Alert ID, хэш и время постоянной записи. Решение о дубликате хранит первое и последнее появление, точный повтор или конфликт и выбранное действие. Позднейшая disposition сообщает о корреляции, проверке, эскалации, отклонении или закрытии. Такая совместимость не требует единого SIEM.

Running-Code Primacy помещает доказательство в реально исполненную цепочку получения, записи и решения. Minimum Initial Specification, Localized Future Decision допускает узкую общую квитанцию при сохранении местной власти над реакцией. On Authority, Belief, and the Internet’s Addressing System разделяет источники авторитета: сертификат называет участника, 204 подтверждает приём, аналитик оценивает инцидент.