Кратко

  • 3 сентября 2026 года IESG не обнаружил конфликта между работой IETF и версией 12 независимого проекта Safe-IOC. Это решение не утверждало техническое содержание, не создавало консенсус IETF и не переводило документ на Standards Track.
  • Затем появились версии 13 и 14. Публичные различия показывают, что несколько замечаний из ballot отразились в тексте; история Datatracker фиксирует действия ISE, IANA и производства RFC. Но ни одна запись сама по себе не даёт постатейного разбора, связывающего каждый комментарий с ответственным решением и точными изменёнными байтами.
  • Квитанция версий и разбора комментариев должна сохранить хеш проверенной версии, ответ по RFC 5742, стабильные идентификаторы комментариев, решения ISE, реализующие diff, состояния IANA и RPC и итоговый boilerplate RFC — не превращая движение по очереди в одобрение или публикацию.

Решение относится к более раннему объекту

Объявление IESG точно называет объект: проверялся draft-grimminck-safe-ioc-sharing-12. IESG не нашёл конфликта с работой IETF и не увидел проблемы в публикации документа как Informational RFC. Затем следует отдельная просьба: Independent Submissions Editor должен рассмотреть комментарии в ballot и истории Datatracker и решить, заслуживают ли они включения.

Это разные состояния. Проверка конфликта версии 12 завершилась. Технические комментарии оставались на усмотрение ISE. Процесс публикации вне IETF мог продолжаться. Ни одна фраза не утверждает, что одобрено каждое техническое положение, принят каждый комментарий или уже опубликован RFC.

Текущая карточка Datatracker указывает уже на версию 14. Документ по-прежнему обозначен как активный индивидуальный Internet-Draft в потоке Independent Submission с предполагаемым статусом Informational. Идентичность проекта сохранилась, но байты и производственное состояние изменились.

RFC 5742 намеренно ограничивает роль IESG

RFC 5742 перечисляет пять возможных результатов проверки конфликта. Здесь использован первый и самый узкий: конфликта с работой IETF нет. Тот же RFC объясняет, что документы потоков вне IETF обычно не запрашивают консенсус IETF или одобрение IESG; после вывода об отсутствии конфликта техническую состоятельность и потенциальный вред для Интернета продолжает оценивать система RFC Editor.

Такое разделение предотвращает две противоположные ошибки. IESG не должен незаметно расширять проверку конфликта до полной технической экспертизы. ISE не должен считать отсутствие конфликта заменой редакционного и технического суждения. «Нет проблемы с публикацией» означает, что Independent stream не заблокирован по этому основанию, а не что IETF поддержал спецификацию.

Страница ballot подчёркивает эту границу. Вопрос состоит в том, верен ли предложенный ответ проверки конфликта. На момент среза там два Yes и восемь No Objection. Эти позиции отвечают на институциональный вопрос; они не являются десятью голосами за каждое правило преобразования, тестовый вектор или заявление о безопасности.

Видимый путь от комментариев к новому тексту

Один комментарий оставляет полезный след. Mohamed Boucadair согласился с ответом по конфликту и отдельно предложил четыре небольших технических изменения: сослаться на RFC 9424 как вводный материал об индикаторах компрометации; не называть формат «безопасным», если он лишь снижает риск; различать префиксы и адреса; охватить формы IPv6 со встроенным IPv4 по RFC 6052. Éric Vyncke оставил более лёгкое замечание об объёме материала по IPv6.

Версия 13 появилась после объявления. История версий и сравнение 12 с 14 показывают заметное соответствие. В abstract фраза “a safe obfuscation format” заменена на “an obfuscation format”. Добавлены RFC 9424, терминология префиксов вместо CIDR-адресов, RFC 6052 и два теста со встроенным IPv4. Boucadair включён в благодарности.

Эти свидетельства позволяют аккуратно сказать: последующий текст отражает предложения. Но они не доказывают формальный разбор каждого пункта. По diff нельзя узнать, принял ли ISE замечание ровно в исходной форме, принял ли его по другой причине, объединил с иным отзывом либо счёл, что более широкую проблему решил другой фрагмент.

Версия 14 добавила ещё один слой. В ней появился привычный термин “defanging”, уточнились грамматика host и ссылки на RFC 1035, два требования в верхнем регистре стали обычными рекомендациями, а в Security Considerations добавлен риск неоднозначности токенов в скобках внутри Path, Query или Fragment. Расширены и благодарности. Публичная запись не сопоставляет каждое изменение со стабильным пунктом проверки и атрибутированным решением «принято», «отклонено» или «принято частично».

Производственное движение ещё не публикация

9 сентября цепочка состояний продолжилась: загрузили версию 14, и ISE передал её RFC Editor. Работа IANA сначала стала активной, а затем перешла в “No IANA Actions”. Производство RFC двигалось от активного состояния к блокировке Author Input Required и обратно. К 16 сентября история RPC показывала переход от ожидания проверки ссылок и форматирования к ожиданию назначения редактора.

Официальный XML очереди RFC Editor по-прежнему содержит draft-grimminck-safe-ioc-sharing-14 в потоке ISE, с датой получения 9 сентября и назначением ref_checker. Datatracker и очередь дают разные проекции производственной работы, поэтому их нельзя свести к слову “approved”. На момент среза окончательного номера RFC нет.

Процесс Independent Submission прямо включает повторные проверки и обновления документа, предварительное решение о публикации, передачу RFC Production Center, AUTH48 и лишь затем выпуск. ISE может отказаться от публикации вплоть до выхода RFC. Запись в очереди доказывает передачу и работу, но не существование окончательного публичного объекта.

Недостающая квитанция

Первая строка квитанции версий и комментариев должна точным хешем и отметкой времени связать версию 12 с ответом RFC 5742. Каждый комментарий должен получить стабильный идентификатор, автора, хеш текста и исходную поверхность. Результат ISE следует записать явно: принят, отклонён или принят частично, с основанием. Для принятого пункта нужны первая реализующая версия и точный фрагмент diff.

Та же квитанция может пройти через IANA и RPC, не смешивая их роли. Она фиксирует наличие действий IANA, даты и причины производственных блокировок и освобождений, ответственного участника, окончательный номер RFC и boilerplate потока, а позже — errata или замену. Если комментарий лишь рекомендательный, это должно быть видно. Если изменение пришло из другого источника, его нельзя задним числом приписывать ballot.

Такая дисциплина защищает спецификацию и от преувеличенных заявлений о безопасности. Последовательная обратимая текстовая форма может снизить риск случайной активации, но не подтверждает, что индикатор вредоносен, актуален, верно атрибутирован или безопасен для обработки. Происхождение документа и происхождение индикатора угрозы — разные записи.

Источники