Кратко

  • RFC 3933 создала промежуточный путь между неформальным изменением IESG и постоянной BCP: проект, четырёхнедельный Last Call, ограниченный охват, Experimental RFC и sunset.
  • Срок был обязателен, но постановка проблемы, критерии оценки и объяснение успеха либо неудачи оставались желательными, а не необходимыми.

Временное правило получило видимый контур

RFC 3933, записанная в карточке RFC Editor как BCP 93, отвечала на неудобный выбор. Гибкость RFC 2026 позволяла IESG быстро менять процедуры, но сообщество могло узнать о них поздно. Полный путь с группами и консенсусом, описанный в RFC 2418, был тяжёлым до появления опыта. После организационной истории RFC 1396 новый документ разрешил сначала провести ограниченную публичную пробу.

Проект описывал процедуру. IESG проверяла правдоподобие пользы. Четыре недели Last Call открывали обсуждение. Исправленный текст отвечал на возражения и публиковался как Experimental. Эксперимент можно было ограничить несколькими областями или WG; решение должно было отражать rough consensus и допускало обычную апелляцию.

Предложение обязано было назвать sunset, обычно не позже года после принятия. Erratum 209 исправляет запятую, а не это требование. К сроку процедура превращалась в BCP или истекала.

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

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

Эксперимент закончился раньше, чем очистился статус

RFC 4693 предложила IETF Operational Notes на двенадцать месяцев. Затем сообщество должно было выбрать постоянство, прекращение или продолжение. Автор не считал объективные метрики полезными, ожидая очевидного отношения сообщества.

IESG закрыла опыт в марте 2008 года. Лишь RFC 6393 в сентябре 2011 года перевела RFC 4693 в Historic и объявила устаревшей. Это не доказывает вред или провал. Это доказывает различие между прекращением практики и обновлением архивного статуса документа.

RFC 5111 могла быть строже: восемнадцать месяцев, не больше трёх Exploratory Groups, показатели по этапам, созданию WG и активности списка. RFC 4633 ограничила восемнадцатью месяцами расширенные приостановки права писать в списки, запретила их действие после опыта, потребовала публичности и сохранила апелляцию.

У NomCom появился обязательный отчётный мост

Очные критерии RFC 8713 потеряли смысл во время полностью дистанционных встреч. RFC 8989 запустила эксперимент на один, максимум два цикла NomCom. Она потребовала консультации с председателями, публичного отчёта и обсуждения размера и разнообразия пула, знания IETF и машинной проверяемости критериев.

RFC 9389 позже включила возникшие пути в BCP 10. Это свидетельство последующего нормативного решения, а не измерение каждого эффекта и не доказательство единственной причины. Но связь была проверяемее, потому что отчёт входил в конструкцию.

Тексты Heng Lu о минимальной начальной спецификации и добровольном принятии и приоритете работающего кода дают редакционную границу: публикация, решение, применение и эффект — разные доказательства. RFC 3933 сделала временную власть видимой во времени, но не гарантировала проверяемую память о её действии.