2. Предпосылки и спецификация
После изменений 1992 года, задокументированных в [RFC1396], IETF
использует два механизма для изменений процесса.
1. IESG по собственной инициативе приняла ряд процедурных изменений
и неформально документировала их, используя широкую свободу
усмотрения, неявно предоставленную ей [RFC2026]. Это обеспечивало
облегчённый механизм изменений, но эта облегчённость имела свою
цену: иногда согласованность с более широким сообществом IETF была
недостаточной.
2. IETF также использовала процесс разработки стандартов протоколов
[RFC2026], чтобы определить заинтересованное сообщество, провести
один или несколько BoF, сформулировать устав рабочей группы,
обсудить предлагаемые изменения в сообществе, выработать
обще-IETF-консенсус по изменениям и опубликовать (обычно)
спецификации Best Current Practice. Это обеспечивало полное
участие сообщества, но также имело свою цену в гибкости. IETF не
часто изменяет свои формальные процессы (уточнения IPR в
[RFC3667, RFC3668] являются первыми документированными изменениями
[RFC2026] с 1996 года), и сообщество по понятным причинам неохотно
постоянно изменяет или расширяет формально принятые процессы
непроверенными новыми процедурами.
Между обновлениями процесса BCP и неформальными соглашениями
существует промежуточный вариант. Этот документ определяет
упорядочивание и формализацию неформальных механизмов IESG,
перечисленных выше в пункте 1, как средство продвижения процедурных
изменений, которые могут оказаться ценными.
Описанные здесь механизмы расширяют набор инструментов IESG для
постоянного решения вопросов процесса. Они дополняют существующие
инструменты, а не пытаются заменить их единственной «серебряной
пулей». Выбор использования процедуры, изложенной в этом документе,
или других механизмов, доступных IESG и сообществу — нынешних или
будущих — остаётся в руках IESG. Если IESG не будет разумно
пользоваться этим усмотрением, этот документ не предоставляет
дополнительных средств правовой защиты.
Некоторые истолковывали текущие процедуры как предоставляющие IESG
все возможности, изложенные здесь. Если это верно, данный документ
лишь поощряет IESG использовать этот тип механизма чаще, отдавая ему
предпочтение перед менее упорядоченными механизмами, и более явно
документировать свои действия и решения.
Эта спецификация разрешает и поощряет IESG принимать и вводить
«эксперименты с процессами» посредством следующей процедуры:
1. Составляется I-D с описанием предлагаемой новой или изменённой
процедуры. Желательно, но не обязательно, заявление о проблеме,
которую, как ожидается, удастся решить (намерение состоит в том,
чтобы сохранить твёрдые требования к такому эксперименту настолько
облегчёнными, насколько возможно). Аналогично, конкретные
экспериментальные или оценочные критерии, хотя и крайне желательны,
не обязательны — для некоторых ожидаемых нами изменений процесса
будет как адекватно, так и достаточно, чтобы IESG по окончании
периода sunset пришла к выводу, что сообщество в целом считает
положение дел лучшим (или худшим). I-D должен указывать явный срок
истечения действия («sunset»), который, как правило, не превышает
одного года после принятия.
2. Если IESG считает предложение правдоподобным и правдоподобно
полезным, инициируется четырёхнедельный IETF Last Call. IESG может
устанавливать любые процедуры, которые сочтёт нужными для принятия
такого решения и для предотвращения атак отказа в обслуживании,
исходящих от большого числа ложных или несущественных предложений.
В частности, она может установить процедуру, требующую определённого
числа одобрений или одобрений определённого типа, прежде чем IESG
рассмотрит предложение. Однако от IESG ожидается понимание того,
что процедуры или процессы рецензирования, действующие как механизм
существенных задержек, не соответствуют намерению этой
спецификации.
3. По завершении Last Call IESG повторно оценивает правдоподобность и
уместность предложения. Если она заключает, что предлагаемый
эксперимент уместен, создаётся второй I-D (либо IESG, либо
первоначальными авторами по рекомендации IESG), который устраняет
любые вопросы определений, выявленные в ходе Last Call, и который
явно определяет вопросы, поднятые в ходе Last Call, и отвечает на
них.
4. Затем объявляются документ и эксперимент, эксперимент начинается,
а документ направляется для публикации как Experimental RFC.
IESG прямо уполномочена использовать этот механизм (основанный на
Experimental RFC) для получения опыта применения предлагаемых
изменений в спецификациях BCP. Нет требования утверждать спецификацию
BCP для эксперимента до того, как будет установлена ценность
эксперимента.
Разумеется, IESG могла бы прийти к выводу «плохая идея» на любой
стадии этого процесса и отказаться от эксперимента. Она могла бы
рекомендовать публикацию экспериментального документа с обсуждением
того, почему это была плохая идея, но не обязана это делать. В
приведённом выше списке намеренно не уточняется, откуда берутся I-D:
на первом и/или третьем этапах могли бы использоваться WG, группа
проектирования, индивидуальный вклад, редакционная группа или иной
механизм, но никаких конкретных механизмов не требуется, и IESG прямо
разрешено формировать такие предложения внутри себя.
В каждом случае ожидается, что решение IESG продолжать (или не
продолжать) процедурный эксперимент либо предпринимать ведущие к нему
шаги будет отражать её суждение о наличии приблизительного консенсуса
в сообществе. Это суждение может быть обжаловано обычными процедурами,
но IESG и сообществу напоминают, что экспериментальная попытка
опробовать что-либо в течение фиксированного периода обычно является
лучшим инженерным подходом, чем продолжительное философское
обсуждение без какого-либо опыта, который его подтверждает.
Ничто из вышесказанного не следует истолковывать как требование
обще-IETF-попытки для какого-либо конкретного эксперимента с процессом.
Предложение такого эксперимента может определять выбранные области,
выбранные рабочие группы, рабочие группы, соответствующие некоторым
конкретным критериям (например, созданные после определённого времени
или имеющие установленный возраст), либо может быть конкретным иными
способами.
К окончанию срока истечения действия («sunset») или до него IESG либо
пересмотрела бы (либо обеспечила бы пересмотр) документ в BCP RFC,
либо процедура прекратила бы действие и, предположительно, не была бы
снова опробована, если только что-либо радикально не изменилось бы.
Документ, описывающий, почему эксперимент оказался успешным или
неудачным, был бы желателен, но реалистично не мог бы быть требованием.
Если процедура переходила в BCP, BCP отражал бы то, что мы назвали бы
«опытом эксплуатации» в реальном мире.
Мы отмечаем, что если процедуры, которые IESG приняла (и процедурные
исключения, которые она сделала) за последнее десятилетие, являются
законными, то IESG имеет полномочия ввести указанные здесь изменения,
самозапустив этот процесс.