RFC3933 · Модель для экспериментов с процессами IETF
A Model for IETF Process Experiments
RFC 3933 определяет промежуточный подход к изменению процессов IETF между неформальными решениями IESG и полным процессом разработки стандартов. Сначала подготавливается Internet-Draft с явно указанным сроком прекращения действия, обычно не превышающим одного года после принятия; если IESG считает предложение правдоподобным и потенциально полезным, инициируется четырёхнедельный IETF Last Call. После Last Call IESG повторно оценивает предложение и, если признаёт эксперимент уместным, подготавливается второй I-D; затем документ и эксперимент объявляются, эксперимент начинается, а документ направляется на публикацию как Experimental RFC. К окончанию или до окончания срока IESG либо перерабатывает документ в BCP RFC на основе практического опыта, либо процедура прекращает действие. Эксперименты могут ограничиваться отдельными областями или рабочими группами; IESG СЛЕДУЕТ проявлять должную осторожность, чтобы изменения не снижали качество рассмотрения безопасности протоколов, либо обеспечивать, чтобы предложения экспериментов содержали механизмы раннего обнаружения и исправления такого ухудшения.
IETF · RFC
Назначение
Предоставить IESG формализованный, но облегчённый способ проверять изменения процедур IETF до их возможного закрепления в качестве Best Current Practice.
Применение
Применять при предложении изменений в процессах IETF, когда требуется ограниченный по времени эксперимент с обсуждением сообщества, оценкой результатов и возможным последующим оформлением в BCP RFC.
Это BCP 93, опубликованный в ноябре 2004 года; документ не заменяет другие механизмы IESG и оставляет выбор процедуры на усмотрение IESG. Он не обновляет и не отменяет другие RFC; связан с BCP 93. Для эксперимента не требуется утверждать BCP-спецификацию, пока эксперимент не будет признан ценным; IESG может на любой стадии счесть эксперимент неудачной идеей и отказаться от него.
Официальная английская аннотация
The IETF has designed process changes over the last ten years in one of two ways: announcement by the IESG, sometimes based on informal agreements with limited community involvement and awareness, and formal use of the same mechanism used for protocol specification. The first mechanism has often proven to be too lightweight, the second too heavyweight. This document specifies a middle-ground approach to the system of making changes to IETF process, one that relies heavily on a "propose and carry out an experiment, evaluate the experiment, and then establish permanent procedures based on operational experience" model rather than those previously attempted. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
{
"id": "RFC3933",
"number": 3933,
"title_en": "A Model for IETF Process Experiments",
"title_ru": "Модель для экспериментов с процессами IETF",
"summary_ru": "RFC 3933 определяет промежуточный подход к изменению процессов IETF между неформальными решениями IESG и полным процессом разработки стандартов. Сначала подготавливается Internet-Draft с явно указанным сроком прекращения действия, обычно не превышающим одного года после принятия; если IESG считает предложение правдоподобным и потенциально полезным, инициируется четырёхнедельный IETF Last Call. После Last Call IESG повторно оценивает предложение и, если признаёт эксперимент уместным, подготавливается второй I-D; затем документ и эксперимент объявляются, эксперимент начинается, а документ направляется на публикацию как Experimental RFC. К окончанию или до окончания срока IESG либо перерабатывает документ в BCP RFC на основе практического опыта, либо процедура прекращает действие. Эксперименты могут ограничиваться отдельными областями или рабочими группами; IESG СЛЕДУЕТ проявлять должную осторожность, чтобы изменения не снижали качество рассмотрения безопасности протоколов, либо обеспечивать, чтобы предложения экспериментов содержали механизмы раннего обнаружения и исправления такого ухудшения.",
"purpose_ru": "Предоставить IESG формализованный, но облегчённый способ проверять изменения процедур IETF до их возможного закрепления в качестве Best Current Practice.",
"use_ru": "Применять при предложении изменений в процессах IETF, когда требуется ограниченный по времени эксперимент с обсуждением сообщества, оценкой результатов и возможным последующим оформлением в BCP RFC.",
"full_translation_path": "translations/rfc3933.html",
"full_translation_checked_at": "2026-10-04",
"full_translation_source_sha256": "122cec199516cd92641812d68d1937ff544fdea6d8ff86085ca4ba94de52266b",
"architect_note_ru": "Это BCP 93, опубликованный в ноябре 2004 года; документ не заменяет другие механизмы IESG и оставляет выбор процедуры на усмотрение IESG. Он не обновляет и не отменяет другие RFC; связан с BCP 93. Для эксперимента не требуется утверждать BCP-спецификацию, пока эксперимент не будет признан ценным; IESG может на любой стадии счесть эксперимент неудачной идеей и отказаться от него.",
"topics_ru": [],
"translation_state": "reviewed",
"verification_level": "primary_source_reviewed",
"verification_level_ru": "Проверено по первичному тексту и реестру RFC Editor",
"verification_note_ru": "Полный текст и карточка независимо сверены с первоисточником. 2026-10-04",
"abstract_en": "The IETF has designed process changes over the last ten years in one of two ways: announcement by the IESG, sometimes based on informal agreements with limited community involvement and awareness, and formal use of the same mechanism used for protocol specification. The first mechanism has often proven to be too lightweight, the second too heavyweight. This document specifies a middle-ground approach to the system of making changes to IETF process, one that relies heavily on a \"propose and carry out an experiment, evaluate the experiment, and then establish permanent procedures based on operational experience\" model rather than those previously attempted. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.",
"authors": [
"J. Klensin",
"S. Dawkins"
],
"organizations": [],
"publication_date": "2004-11-01",
"current_status": "BEST CURRENT PRACTICE",
"current_status_ru": "Лучшая современная практика",
"publication_status": "BEST CURRENT PRACTICE",
"publication_status_ru": "Лучшая современная практика",
"lifecycle": "active",
"lifecycle_ru": "Действующий",
"stream": "IETF",
"stream_ru": "IETF",
"area": "",
"area_ru": "",
"working_group": "NON WORKING GROUP",
"source_draft": "draft-klensin-process-july14-02",
"page_count": 7,
"doi": "10.17487/RFC3933",
"keywords": [
"Experiments"
],
"formats": [
"TXT",
"HTML"
],
"relations": {
"obsoletes": [],
"obsoleted_by": [],
"updates": [],
"updated_by": [],
"is_also": [
"BCP93"
],
"see_also": []
},
"links": {
"info": "https://www.rfc-editor.org/info/rfc3933/",
"html": "https://www.rfc-editor.org/rfc/rfc3933.html",
"txt": "https://www.rfc-editor.org/rfc/rfc3933.txt",
"datatracker": "https://datatracker.ietf.org/doc/rfc3933/"
}
}