Кратко

  • RFC 9945 опубликован в феврале 2026 года как BCP 245 и учреждает общую политику модерации публичных онлайн-площадок IETF. Но изменения вступают в силу лишь после утверждения IESG процедур из раздела 4; пока процедуры и критерии не установлены, продолжают действовать прежние процессы.
  • Библиографическая пометка об отмене, назначение команды, наличие открытого SOP и выполненное действие подтверждают разные факты. Нужна компактная запись, связывающая неизменяемую редакцию, решение и момент утверждения, дату действия, заменённые нормы, область, роли и перенос незавершённых дел без раскрытия жалоб.

Переход состоит не из одной даты

Февральская дата на RFC 9945 удостоверяет публикацию. Документ прошёл публичное рассмотрение, получил одобрение IESG на выпуск, выражает консенсус IETF и стал BCP 245. Он объявляет устаревшими RFC 3683 и RFC 3934, заменяет части RFC 9245 и обновляет RFC 2418.

Для библиотеки стандартов этого достаточно, чтобы выстроить преемственность. Для решения по конкретному случаю требуется ещё одна дата.

В конце введения RFC 9945 прямо указано: описанные изменения начинают действовать после утверждения IESG процедур из раздела 4. Команда модераторов разрабатывает процедуры и критерии с участием сообщества. IESG утверждает их до вступления в силу; документы публикуются, хотя включать их в серию RFC необязательно. Пока работа не завершена, сохраняются процессы, перечисленные в разделе 1.

Так построен двухуровневый режим. BCP фиксирует назначение, границы, распределение полномочий, прозрачность и апелляцию. Операционные инструкции можно менять быстрее, не выпуская новый RFC при каждом уточнении. Гибкость полезна. Но она выносит переключатель в отдельный публичный акт, который нужно уметь найти и датировать.

«Obsoleted» — отношение документов, а не полный журнал полномочий

Страница RFC 3934 верно направляет читателя к RFC 9945 как к заменяющему документу. Без этого указателя старый текст легко принять за последнее слово. Однако такое отношение не содержит номера редакции операционной процедуры, её хеша, решения IESG и времени начала действия.

Поэтому две фразы могут быть истинны одновременно. RFC 3934 формально устарел в корпусе. Его процесс временно продолжает действовать по переходной норме документа, который его заменил. Первая фраза описывает статус текста; вторая — допустимое действие в заданный период.

Если оставить одну метку, возникнут противоположные ошибки. Читатель решит, что всё прежнее исчезло в день публикации. Или, наоборот, объявит новый BCP несуществующим до смены процедур. RFC 9945 уже опубликован и учреждает новый каркас. Его операционный слой подчинён отдельному условию.

Хорошая запись не выбирает между слоями. Она связывает их по времени.

Июльская апелляция проверила условие на практике

30 июня 2026 года Andrew Lee подал апелляцию в связи с модерацией во время Last Call рабочей группы TLS. Одно из возражений сводилось к тому, что RFC 3934 больше не может давать полномочия: RFC Editor показывает его как отменённый RFC 9945.

IESG ответила 9 июля и отклонила апелляцию после рассмотрения по существу. В части источника полномочий она сочла довод ошибочным. Согласно разделу 4 RFC 9945, прежние процессы остаются в силе, пока новые процедуры и критерии не установлены; значит, RFC 3934 продолжал применяться. IESG отдельно отметила, что BCP 9 сам по себе не предоставляет полномочия модерации, но дополнительная ссылка не лишила действие основания.

Из этого не следует обвинение кого-либо в цензуре, предвзятости, нарушении закона или недобросовестности. Решение не превращает всякую модерацию в справедливую. В апелляции были и другие вопросы — о технической позиции, отводе, избирательном применении и мнении меньшинства. IESG на них ответила; настоящая статья не пересматривает итог.

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

Ответ фиксирует состояние, признанное 9 июля. Он ничего не гарантирует на более поздний момент. К 11 сентября в изученных официальных материалах не удалось найти более позднее решение IESG, утверждающее конкретную редакцию новых процедур. Отрицательный результат поиска не доказывает отсутствия решения. Он показывает, что обязательный публичный переход нуждается в едином указателе, иначе его доказательство зависит от навыка поиска по разрозненным архивам.

Назначенная команда отвечает на вопрос «кто»

Datatracker показывает активную IETF Moderator Team из шести участников. Описание воспроизводит широкий контур RFC 9945: разработка процедур для публичных форумов IETF, помощь сообществу, администрирование пленарных и оставшихся без администратора пространств, назначение IESG и ответственность перед ней.

Это важная институциональная запись. Она удостоверяет роль и состав. Но в ней не названа неизменяемая редакция процедур, решение об её утверждении и момент вступления в силу.

Открытый репозиторий ietf/Moderators на зафиксированном коммите b907805e15… выглядит иначе. README описывает модерацию общей дискуссионной рассылки IETF на основании RFC 9245. SOP перечисляет трёх участников, требует согласия минимум двух для действия и задаёт уровни 0, 1 и 2. Таблица статистики считает действия по этим уровням.

Расхождение не является доказательством ошибки. Репозиторий может относиться к старой узкой команде, которую сменяют поэтапно. Новая команда может готовить документы в другом месте. Список имён мог просто отстать. Старый SOP мог законно продолжать действовать на переходе.

Тем более нельзя наугад выбирать одну из версий как авторитетную. Страница команды доказывает назначение. Коммит — содержание текста. Статистика — применение категорий при подсчёте. Для активации требуется четвёртый факт: IESG утвердила именно эту редакцию для указанной области с такого-то момента.

Централизованная команда не отменяет местное управление

Администраторы по-прежнему первыми отвечают за свои форумы. В рабочей группе эту функцию обычно выполняют chairs. Они вправе делегировать техническую работу, но обязаны принимать, подтверждать и учитывать жалобы. После консультации с командой они могут изменить или отменить действие, включая действие модератора.

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

Area Directors разрешают первичные конфликты. IESG утверждает процедуры, назначает и отзывает модераторов, оценивает работу и участвует в апелляции. Следующей инстанцией может стать IAB по RFC 2026. Ombudsteam сохраняет отдельную роль по противодействию домогательствам. IETF Administration LLC имеет редкое чрезвычайное полномочие при серьёзном юридическом риске и соответствующей консультации.

IRTF, IAB, RSWG, RSAB и Independent Submission stream не попадают под политику автоматически без явного согласия. Это разумное разделение. Но при множестве ролей особенно опасно утратить версию: каждый проверяющий должен видеть норму на момент первоначального действия, а не последний текст по сегодняшней ссылке.

Прежний порядок тоже был множественным

RFC 3934 описывал меры chairs в рассылке рабочей группы. RFC 3683 предусматривал снятие права публикации с участием сообщества и IESG. RFC 9245 регулировал общую дискуссионную рассылку. RFC 2418 закреплял более широкие обязанности руководителей групп. RFC 2026 давал процедуру апелляции.

BCP 245 появился не на пустом месте. Разные администраторы использовали разные критерии. Старые шаги могли быть медленными. Повторяющееся поведение на нескольких площадках ускользало от владельца одной рассылки. Работа перешла в чаты, wiki, репозитории и трекеры задач, для которых почтовые правила были недостаточны.

Временное сохранение прежних процессов не расширяет их границы. Обычная модерация RFC 9945 касается ограничений нарушающей порядок коммуникации в публичных онлайн-форумах IETF. Удаление учётной записи Datatracker, запрет участия во встрече, удаление содержания, частные и внешние разговоры не входят в полномочие.

Старые дела также сохраняют историю. Бессрочное ограничение, принятое до нового процесса, пересматривается по порядку, действовавшему в момент первоначального решения. Значит, сам RFC требует различать исторические версии, а не переписывать прошлое после переключения.

Что должно быть в свидетельстве активации

Первый блок называет процедуру: неизменяемая редакция, криптографический хеш, публичный адрес и классы охваченных форумов. Ветка main удобна для текущего чтения, но не подтверждает прошлое, если её содержимое меняется.

Второй блок фиксирует полномочие: период общественного обсуждения, индекс учёта замечаний, ссылка на решение IESG, время решения и отдельное время вступления в силу. Если внедрение происходит поэтапно, нужен график.

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

Четвёртый блок охватывает переходящие объекты: ожидающие жалобы, активные ограничения, открытые апелляции и сроки запросов о восстановлении. В публичной части достаточно количества и класса версии. Имена, содержание сообщения и внутреннее обсуждение остаются в защищённой записи.

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

Открытость нормы не требует открытости жалобы

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

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

Нельзя требовать от одного артефакта невозможного. Утверждённая процедура не доказывает справедливость каждого решения. Уведомление не доказывает обвинение. Агрегированная статистика не устанавливает одинаковое обращение. Команда не доказывает активацию. Связность не означает смешение.

Тексты Heng Lu дают здесь способ различать уровни, но не факты об IETF. Символический статус документа, исполнимое решение и наблюдаемый результат — разные утверждения. Минимальная спецификация должна сохранить их связь и оставить последующие изменения уполномоченному субъекту.

RFC 9945 обещает более широкий охват, быстрый ответ, границы полномочий, пересмотр и апелляцию. Эта архитектура не станет слабее от точной даты. Команда показывает исполнителя. Процедура — способ действия. Решение IESG — источник полномочия. Время вступления в силу соединяет их с реальным событием.

Источники

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://www.rfc-editor.org/info/rfc9945/
  5. https://www.rfc-editor.org/rfc/rfc9945.html
  6. https://www.rfc-editor.org/rfc/rfc3934.html
  7. https://www.rfc-editor.org/rfc/rfc3683.html
  8. https://www.rfc-editor.org/rfc/rfc9245.html
  9. https://www.rfc-editor.org/rfc/rfc2418.html
  10. https://www.rfc-editor.org/rfc/rfc2026.html
  11. https://datatracker.ietf.org/group/iesg/appeals/artifact/314
  12. https://datatracker.ietf.org/group/iesg/appeals/artifact/315
  13. https://datatracker.ietf.org/group/ietfmoderators/about/
  14. https://github.com/ietf/Moderators/blob/b907805e15f5b902d5d728a9c2c6601962ca625d/README.md
  15. https://github.com/ietf/Moderators/blob/b907805e15f5b902d5d728a9c2c6601962ca625d/sop.md
  16. https://github.com/ietf/Moderators/blob/b907805e15f5b902d5d728a9c2c6601962ca625d/stats.md