Кратко

  • В draft-ietf-procon-2418bis-04, опубликованном 17 августа 2026 года, впервые появилась фраза о том, что рабочая группа может вернуть Internet-Draft в непринятое состояние, например из-за ослабления интереса. В версии -03 её не было.
  • Сейчас документ остаётся WG Document со статусом IESG I-D Exists. Он ещё не стал утверждённой Best Current Practice и не заменил RFC 2418.
  • Принятие выбирает основу для коллективной работы и передаёт группе контроль изменений; оно не одобряет всё содержание и не гарантирует публикацию RFC. Обратный переход меняет прежде всего хранителя документа, а не выносит технический вердикт.
  • Надёжная запись выхода должна связать исходное принятие, последнюю версию под контролем WG, причины, оценку консенсуса, новый статус, передачу редакторских полномочий, преемников и внешние зависимости. Непринятый, отложенный, заброшенный, истёкший и выведенный из эксплуатации — разные состояния.

Фраза, добавившая обратный ход

Новое положение находится в разделе 8.2 версии -04. Сначала там сказано, что группа может официально принять Internet-Draft как основу одного из своих рабочих пунктов. Затем смысл принятия ограничивается: содержание ещё не получает консенсус, а редакторы должны фиксировать результаты дальнейшего обсуждения. Последнее предложение разрешает группе вернуть документ в непринятое состояние и приводит ослабление интереса как пример.

Версия -03 уже отделяла принятие от согласия со всем текстом, но явного выхода не содержала. Журнал -04 отмечает очередное изменение формулировки о принятии. Следовательно, новизна подтверждается сравнением последовательных первичных документов, а не догадкой о направлении реформы.

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

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

Пока проект, а не новая норма

Страница документов PROCON показывает draft-ietf-procon-2418bis-04 как новый WG Document от 17 августа 2026 года. Его карточка Datatracker указывает предполагаемый статус Best Current Practice и перечисляет RFC, которые текст отменит или обновит, если будет утверждён.

На 27 августа состояние IESG было лишь I-D Exists. У проекта не было document shepherd, ответственного Area Director и даты telechat; срок действия истекал 18 февраля 2027 года, если документ не обновят или не продвинут. Соседний 2026bis-11 находился в Working Group Last Call, а 2418bis — нет. Статус одной строки не распространяется на другую.

Устав PROCON разрешает группе объединять накопившиеся процессуальные документы и отдельно допускает содержательный пересмотр правил принятия черновиков. Это подтверждает полномочие обсуждать вопрос, но не означает согласия с текущей редакцией.

Пока применимая процедура не создаст преемника, опубликованный RFC 2418 остаётся частью BCP 25. Реестр управления должен одновременно показывать действующий документ и предложенную замену с отдельными версиями и статусами. Называть -04 несущественной заметкой — значит терять институциональный контекст; применять как правило — значит придумывать результат.

Принятие передаёт контроль, а не подтверждает истину

RFC 7221 описывает обычную последовательность принятия. Владельцев исходного текста предупреждают о передаче контроля изменений IETF. Chairs проверяют раскрытие прав интеллектуальной собственности, устанавливают rough consensus, выбирают редакторов, разрешают публикацию WG-версии и сохраняют связь замены между индивидуальным и групповым документом.

Критерий состоит в том, пригоден ли текст как платформа для продолжения работы. RFC 7221 называет принятие начальным, а не окончательным, и именно принятием, а не одобрением. Полное решение ещё не обязательно, а публикация RFC не гарантирована. После перехода документ принадлежит WG и может меняться в пределах устава и процедур IETF. Без отдельного решения группа не считается согласившейся с каждым элементом исходного текста.

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

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

В старой модели уже существовали боковые пути

RFC 6174 описывает состояния WG-документов не как лестницу только вверх. Вызов на принятие означает, что черновик рассматривается, но ещё не выбран. При отказе от принятия он возвращается к отсутствию stream-специфичного состояния, однако история хранит сам вызов. Adopted by a WG фиксирует промежуток до публикации версии draft-ietf, а WG Document — принятый документ в активной разработке.

Есть и боковые состояния. Parked WG Document подходит при отсутствии редактора, ожидании другого документа или проверки, либо иной остановке; аннотация может указать условие возобновления. Dead WG Document обозначает заброшенную работу, но не обязательно навсегда: документ можно оживить или до истечения срока передать другой группе с нужными согласиями. RFC также предупреждает, что отсутствие стрелки на диаграмме не запрещает уместный переход.

Различия важны. Parked — пауза при сохраняющейся опеке. Dead — прекращение работы в этой группе при сохранённой истории. Expired — событие календаря репозитория, а не коллективное решение. Non-adopted сообщает, что текст больше не служит основой рабочего пункта; нового владельца изменений нужно указывать отдельно.

2418bis-04 пока не объясняет исчерпывающе, как новая формула соотносится с каждой меткой Datatracker. Это открытый вопрос для следующих версий, инструментов или руководства chairs. Нельзя решать его заранее, объявляя разные понятия синонимами.

RFC 7221 добавляет возможный маршрут после выхода. WG не обязана сохранять однажды принятый документ. Если группа его оставляет, любой участник может продолжить работу как Individual Submission или Independent Submission с учётом авторских ограничений. Конец групповой опеки может быть сменой форума и полномочий, а не исчезновением идеи.

Непринятое не означает технически отвергнутое

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

RFC 7282 объясняет, что rough consensus не сводится к подсчёту голосов. Существенны причины возражений и ответы на них. Для выхода нужна та же дисциплина. Малое число сообщений не доказывает отсутствие интереса само по себе, а объявление chairs неполно без вопроса, периода обсуждения, аргументов и основания оценки.

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

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

Что сохраняет корректный выход

Сначала нужна цепочка идентичности. Следует связать индивидуальный черновик, заменивший его draft-ietf, важные версии и хеши, а также вызов и объявление о принятии. Без этих связей индивидуальное продолжение может показаться случайной копией, а неофициальная версия — официальным продолжением WG.

Затем фиксируется решение о выходе: кто предложил его, сколько длилось обсуждение, какие доводы были за продолжение и завершение, какие возражения остались, как chairs установили консенсус. Если указано падение интереса, его лучше подкрепить поиском редактора, неотвеченными запросами на review или явной работой-преемником.

Нужно точно назвать результат: отсутствие stream-статуса, Parked, Dead, замена, передача, истечение срока или индивидуальное продолжение. Отдельно отмечаются последняя версия под контролем WG, момент прекращения редакторских полномочий и новый держатель контроля.

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

Запись о возврате

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

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

Источники