Кратко

  • Редакция draft-ietf-procon-2026bis-11 опубликована 1 июля 2026 года и 27 августа всё ещё находилась на Working Group Last Call. Она сохраняет механизм variance из RFC 2026, но пока не стала утверждённой заменой BCP 9.
  • Ответственная рабочая группа, а при её отсутствии специально созданный комитет, может рекомендовать исключение для конкретной спецификации при тупике или отсутствии указаний в процессе. Рекомендация запускает рассмотрение, но не означает одобрения.
  • IESG обязан оценить технические достоинства, обычный путь, альтернативы, издержки, побочные и прецедентные эффекты и возможность сузить исключение. Предложение оформляется отдельным Internet-Draft, проходит Last Call не менее четырёх недель и при одобрении публикуется как BCP. Возможность апелляции сохраняется.
  • Нельзя отменить установленные сроки, открытость, справедливость, консенсус, ведение записей и ряд ключевых процедур. Поэтому variance — это версионированная квитанция одного исключения, а не скрытая поправка к общей норме, автоматическое разрешение для будущих дел или распоряжение операторам о внедрении.

Когда реестр перестаёт описывать решение

Реестр полезен, пока отвечает на вопрос «что произошло в этом деле». Он становится опасным, когда короткий ответ из одного дела начинает определять правила для всех последующих.

Представим спецификацию, которая обладает техническими достоинствами, но не может выполнить одно процедурное требование. Рабочая группа рекомендует узкое отступление. IESG рассматривает альтернативы и последствия. Сообщество получает время на публичные возражения. Исключение одобряют с условиями. Если в базе остаётся только поле «требование снято», исчезают именно те сведения, которые делали решение проверяемым.

Следующая спецификация получает этот статус без собственной рекомендации, обоснования, Last Call и решения. Формальный текст BCP никто не менял, однако операционная модель уже применяет другую норму. Описание превратилось в молчаливое нормотворчество.

Институциональная память проходит тот же путь. «В одном случае была variance» сокращается до «есть прецедент», затем до «IETF это разрешает». При каждом пересказе условия исчезают, а предполагаемый объём полномочий растёт.

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

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

Статус 2026bis нельзя опережать

Карточка Datatracker описывает draft-ietf-procon-2026bis-11 как действующий Internet-Draft рабочей группы PROCON. Поле Intended RFC status в карточке показывает None, тогда как заголовок текста проекта называет Best Current Practice предполагаемым статусом. Ни одно из этих обозначений не является уже принятым решением о статусе. Редакция -11 размещена 1 июля 2026 года и истекает 2 января 2027 года, если не будет обновлена или продвинута дальше. История документа фиксирует переход на Working Group Last Call 21 мая, когда действовала редакция -08.

На 27 августа состояние WG оставалось In WG Last Call, состояние IESG — I-D Exists, дата telechat отсутствовала. Это доказательство серьёзной рабочей проверки проекта. Это не одобрение IESG, не опубликованный RFC и не вступивший в действие новый BCP.

В случае принятия документ объединит и сделает устаревшими несколько процедурных RFC, включая RFC 2026, а также обновит RFC 7475. Устав PROCON объясняет задачу: базовые RFC 2026 и RFC 2418 были изменены более чем двадцатью RFC, поэтому правила оказались рассеяны по длинной цепочке. Группа должна собрать обновления и проверенные errata в понятные документы-преемники. Помимо редакционной работы названы только две дополнительные области изменения; другие темы требуют пересмотра устава.

Раздел 11 редакции -11 сохраняет архитектуру variance. Он не создаёт её в 2026 году. Опубликованный RFC 2026, входящий в BCP 9, уже содержал основной механизм в разделе 9 в 1996 году. Проект сводит тексты, обновляет термины и нумерацию; журнал изменений не называет variance новым политическим экспериментом.

Поэтому в реестре должны одновременно существовать три строки состояния. RFC 2026 — нынешняя опубликованная основа. 2026bis-11 — рассматриваемый проект консолидации. Будущий RFC-преемник, если его одобрят, станет основой только при атрибутируемом событии публикации. Использовать проект для объяснения направления работы допустимо; выдавать его за действующее решение — значит стереть незавершённые этапы.

Кто рекомендует и кто принимает решение

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

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

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

IESG вправе ограничить variance отдельными положениями и наложить дополнительные условия. Отступление от одного требования не останавливает остальной процесс. По мере продвижения дела границы должны становиться точнее, а не расплываться в общее усмотрение.

Публичная цепочка хранения решения

Предложение обязано назвать воспринимаемую проблему, точное затрудняющее положение и соображения IESG. Оно выпускается как отдельный Internet-Draft — публичный объект с идентификатором и историей версий.

Затем IESG объявляет расширенный Last Call продолжительностью не менее четырёх недель. После него принимается окончательное решение и публикуется объявление для IETF. Одобренная variance направляется на публикацию как BCP. Процедура апелляции продолжает действовать.

У каждого события собственная доказательная сила. Рекомендация показывает, кто попросил рассмотреть исключение. Internet-Draft фиксирует точный предмет. Last Call показывает наличие минимального окна публичной проверки, но не превращает молчание в согласие. Объявление IESG устанавливает автора решения и результат. Публикация стабилизирует одобренный текст. Апелляция, если она есть, образует отдельное дело со своим заявителем, вопросом и итогом.

RFC 7282 поясняет, почему количества сообщений недостаточно. Rough consensus зависит от содержания возражений и от того, как на них ответили, а не от процента голосов. Много коротких одобрений не закрывают одно существенное структурное возражение. Но и наличие возражения само по себе не даёт автоматического вето. Реестр должен сохранять аргумент и его рассмотрение.

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

Основание, которое нельзя исключить

RFC 2026 запрещает сокращать установленную продолжительность ожидания. Нельзя освобождать предложение от открытости, справедливости или консенсуса, а также от надлежащей фиксации заседаний и обсуждений в списках рассылки. Защищены и названные центральные положения о пересмотре BCP, начале действия, рассмотрении IESG, публикации, разрешении конфликтов, апелляциях и самой variance. 2026bis-11 переносит этот фундамент в новую нумерацию.

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

Четыре недели Last Call — не пустой таймер перед заранее известным итогом. Это минимальная возможность для участников вне WG проверить положение, причины, альтернативы и внешние эффекты. Если ссылка на срочность позволяет сократить время, предназначенное для проверки срочности, обоснование превращается в право уйти от контроля.

Фундамент не обещает единогласия и не устраняет усмотрение IESG. Он сохраняет более базовую гарантию: решение видимо, имеет автора, оставляет запись и не уничтожает путь обжалования.

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

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

Аналитическая часть хранит технические достоинства, баланс пользы и издержек, рассмотренные и отвергнутые альтернативы, побочные и прецедентные эффекты, точный объём и дополнительные условия. Публичная часть связывает Internet-Draft и его хеш, время открытия и закрытия Last Call, существенные возражения и их разрешение.

В конце записываются решение и объявление IESG, идентификатор BCP при одобрении, состояние и результаты апелляций, одноразовая граница и условие прекращения. Нужны также два явных отрицания: квитанция не разрешает последующие спецификации и не доказывает внедрение, закупку или эксплуатацию какой-либо стороной.

Публикация одобренной variance как BCP не делает её общей процедурной нормой. Формат обеспечивает публичность, стабильность и цитируемость решения. Содержание остаётся ограниченным названным случаем. Постоянное изменение повторно используемой нормы требует обычной открытой процедуры замены BCP.

Внутренний процесс и внешнее внедрение

Variance меняет путь одной спецификации внутри стандартного процесса IETF. Она не принимает решение за компанию, оператора связи, государственный орган или программный проект.

RFC 9281 описывает роли WG, IESG и других участников процесса. Распределение полномочий не позволяет внешнему субъекту выводить из исключения новые состояния документа. RFC 3935 указывает, что стандарт IETF описывает способ действия при заявленной совместимости; IETF не стремится повсеместно предписывать или контролировать использование.

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

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

Источники