Кратко

  • На IETF 126 PROCON согласился предложить фразу о точном описании действующей политики. На момент завершения исследования Datatracker показывал утверждённой лишь хартию 2025 года; новая формула ещё не стала действующим полномочием.
  • Текущая хартия уже разрешает ограниченные не редакционные изменения, касающиеся этапов рабочих групп и принятия Internet-Draft. Отдельно разрешён BCP о делегировании и временном замещении председателя IETF. Для других задач требуется новая хартия.
  • В 2418bis удалены проценты 51/99, описаны вспомогательные роли и несколько типов публичных форумов, а принятие проекта отделено от согласия с содержанием и сделано обратимым. Эти изменения нельзя автоматически отнести к одной категории.
  • Наблюдаемая практика не становится нормой сама по себе. Но и новое предложение не обязательно выходит за рамки: некоторые содержательные изменения прямо допускаются действующей хартией.
  • Нужен компактный публичный реестр, связывающий значимый diff с исходным текстом, доказательствами практики, классификацией, пунктом хартии, возражениями, решением группы и последующими стадиями IETF и IESG.
  • Такой реестр не создаёт нового вето. Он также отделяет публикацию BCP от его внедрения в инструментах, обучении председателей и повседневной работе групп.

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

PROCON решает реальную проблему доступности процедуры. RFC 2026 и RFC 2418 по-прежнему лежат в основе стандартизации и работы групп, но последующие RFC, errata и новые способы взаимодействия разнесли применимые нормы по разным источникам.

Утверждённая хартия PROCON требует объединить RFC, обновляющие два базовых документа, а также проверенные или отложенные до обновления errata. При этом она разрешает не редакционные изменения в вопросах этапов группы и принятия проектов. Ещё один разрешённый результат — BCP о делегировании полномочий председателем IETF и временном замещении. Дополнительные темы требуют rechartering.

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

Слайды председателей на IETF 126 зафиксировали напряжение. Программу понимали как точное и ясное описание текущего процесса при отсрочке расширений и изменений политики. Но строгое чтение могло исключить даже редакционные исправления и приведение к изменившейся операционной реальности. Первоначально предлагалась длинная поправка со ссылками на RFC, заявления IESG и изменения инструментов.

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

К 2 сентября 2026 года утверждённой оставалась charter-ietf-procon-01, обновлённая 9 июля 2025 года. Следовательно, фраза IETF 126 — текст, который группа решила предложить IESG. Она ещё не является новой хартией и не может задним числом разрешить любой прежний diff.

Удаление процентов требует сохранить смысл удаления

draft-ietf-procon-2418bis-04 убирает абзац RFC 2418: 51% поддержки не обязательно означает rough consensus, а 99% может скрывать существенное возражение. Презентация 2418bis называет цифры сбивающими с толку практическими ориентирами. Группа сохранила удаление и не добавила предложенную ссылку на RFC 7282.

Такое решение может защищать ненумерическую природу консенсуса: запоминающиеся проценты слишком похожи на пороги голосования. Но обоснование должно храниться вместе с исходным абзацем, сохранённым принципом и решением группы. Иначе будущему читателю останется считать удаление корректным лишь потому, что оно дошло до конца.

У вспомогательных ролей другая структура. Редакция 04 разрешает председателям и Area Directors назначать и освобождать участников в таких ролях, одновременно запрещая менять через них принятие решений консенсусом или уменьшать основную ответственность председателей и Area Directors. Встреча потребовала переработать текст, сохранив это ограничение ответственности.

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

Публичность после эпохи одной рассылки

RFC 2418 описывает публичную работу прежде всего языком почтовых списков. Редакция 04 включает email, чаты и другие средства совместной работы, требуя суммировать и хорошо документировать результаты таких форумов.

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

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

Отозванный текст 2026bis не отменил спор о классификации

Слайды 2026bis разделяют редакционные изменения, отложенные вопросы и работу перед новым Working Group Last Call. На IETF 126 решили вернуть назад текст редакции 09 о непубличных обсуждениях апелляций и заменить Unicode на IEEE 802 Ethernet в качестве примера внешнего стандарта.

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

Замена “expired” на “inactive” была отложена. В публичном обсуждении отмечено, что новый термин может лучше соответствовать Datatracker, но не обязательно является чисто редакционным. Если меняется только метка интерфейса, это техническая коррекция; если меняется процессуальное состояние, это политика. Один короткий diff может иметь большой эффект.

Двенадцать полей вместо нового органа контроля

Реестр нужен как индекс, не параллельный процесс. Для различий, влияющих на роли, ответственность, консенсус, публичную запись, принятие или апелляцию, он содержит:

  1. неизменяемую редакцию и точный раздел;
  2. базовый RFC, erratum или заявление;
  3. публичное свидетельство текущей практики или состояния инструмента;
  4. классификацию: сведение, исправление механизма, кодификация практики, намеренный пересмотр;
  5. пункт хартии, проект новой хартии или объяснение ненужности дополнительного полномочия;
  6. редакторское обоснование;
  7. существенные возражения с указанием авторства;
  8. решение группы и дату;
  9. изменения после Working Group Last Call;
  10. решения IETF Last Call и IESG;
  11. опубликованный текст;
  12. отдельные данные об операционном внедрении.

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

Возражение в реестре не становится вето. Письмо остаётся позицией его автора; решение группы хранится отдельно. Если предложение удалено, запись показывает завершение и не переносит его в норму.

Заметка 64 Heng Lu предлагает различать минимальную исходную спецификацию, последующее локальное решение уполномоченного субъекта и добровольное внедрение. Она не содержит фактов о PROCON и не заменяет процедуру IETF. Здесь это лишь аналитическая рамка, не позволяющая смешать исходную норму, поздний выбор и применение.

Существующий обзор решает, но не всегда сохраняет объяснение

У IETF уже есть сильные проверки: консенсус группы, Working Group Last Call, IETF Last Call, Area Director и IESG. На IETF 126 Area Director счёл 2026bis входящим в scope при предлагаемом обновлении, но оговорил, что ещё не изучал глубоко все diffs 2418bis.

Список документов PROCON показывал 2026bis-11 в Working Group Last Call, а 2418bis-04 — документом группы. Ни один статус не означает утверждения IESG или публикации BCP. Поздний обзор способен изменить и текст, и классификацию.

Но последовательность решений не организует автоматически их основания. Причина может находиться в письме, контраргумент — в слайдах, решение — в протоколе, результат — в changelog. Успешное прохождение стадий само по себе не сообщает, была ли практика проверена или только заявлена.

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

Источники

  1. Утверждённая хартия PROCON
  2. Список документов PROCON
  3. Протокол PROCON на IETF 126
  4. Слайды председателей PROCON
  5. Обновление 2026bis
  6. Презентация 2418bis
  7. Заметка 64 Heng Lu
  8. Публичная дискуссия о scope
  9. Публичная дискуссия о практике Document Editor
  10. Публичная дискуссия об inactive и expired
  11. draft-ietf-procon-2026bis-11
  12. draft-ietf-procon-2418bis-04
  13. RFC 2026
  14. RFC 2418