О документе
Network Working Group S. Bradner
Request for Comments: 2418 Editor
Obsoletes: 1603 Harvard University
BCP: 25 September 1998
Category: Best Current Practice
Руководящие принципы и процедуры для рабочих групп IETF
1. Введение
Интернет — это слабо организованное международное сотрудничество
автономных взаимосвязанных сетей; он поддерживает связь между узлами
благодаря добровольному соблюдению открытых протоколов и процедур,
определённых интернет-стандартами. Существует также много изолированных
взаимосвязанных сетей, не подключённых к глобальному Интернету, но
использующих интернет-стандарты. Интернет-стандарты разрабатываются в
Internet Engineering Task Force (IETF). Этот документ определяет
руководящие принципы и процедуры для рабочих групп IETF. Процесс
стандартизации IETF определён в [1]. Организации, участвующие в
процессе стандартизации IETF, а также роли конкретных лиц описаны в [2].
IETF — это большое открытое сообщество разработчиков сетей, операторов,
поставщиков, пользователей и исследователей, занимающихся Интернетом и
применяемыми в нём технологиями. Основная деятельность IETF выполняется
комитетами, известными как рабочие группы. В настоящее время существует
более 100 рабочих групп. (Актуальный список рабочих групп IETF см. на
веб-странице IETF — http://www.ietf.org.) Рабочие группы, как правило,
имеют узкую направленность, а срок их существования ограничен завершением
конкретного набора задач, хотя имеются исключения.
В целях управления рабочие группы IETF объединены в области, каждая из
которых имеет отдельную направленность. Например, область безопасности
занимается разработкой технологий, связанных с безопасностью. Каждой
областью IETF управляют один или два директора области (AD). В настоящее
время в IETF имеется 8 областей, но их число время от времени меняется.
(Список текущих областей, директоров областей для каждой области и
перечень рабочих групп, назначенных каждой области, см. на веб-странице
IETF.)
Во многих областях директора областей сформировали консультативную группу
или директорат. В их состав входят опытные члены IETF и технического
сообщества, представленного данной областью. Конкретное название и детали
роли каждой группы различаются от области к области, но основное
назначение состоит в том, чтобы эти группы помогали директору(ам) области,
например при рассмотрении спецификаций, подготовленных в области.
Директора областей IETF выбираются комитетом по выдвижению кандидатур,
который также выбирает общего председателя IETF. Процесс выдвижения
кандидатур описан в [3].
Директора областей, действующие как коллегиальный орган, вместе с
председателем IETF составляют Internet Engineering Steering Group (IESG).
Исполнительный директор IETF является участником IESG по должности, как и
председатель IAB и назначенный связной Internet Architecture Board (IAB).
IESG утверждает интернет-стандарты IETF и публикацию других документов
IETF. (См. [1].)
Небольшой секретариат IETF обеспечивает кадровую и административную
поддержку работы IETF.
Формального членства в IETF нет. Участие открыто для всех. Участие может
осуществляться путём вкладов в онлайн-обсуждения, присутствия на очных
сессиях либо и того и другого. Любому представителю интернет-сообщества,
располагающему временем и интересом, предлагается участвовать во встречах
IETF и любых онлайн-обсуждениях её рабочих групп. Участие осуществляется
отдельными техническими участниками, а не формальными представителями
организаций.
Этот документ определяет процедуры и руководящие принципы формирования и
работы рабочих групп в IETF. Он определяет отношения рабочих групп с
другими органами внутри IETF. Также определены обязанности председателей
рабочих групп и директоров областей в отношении работы рабочей группы.
Если в этом документе используются ключевые слова «ДОЛЖЕН (MUST)», «НЕ
ДОЛЖЕН (MUST NOT)», «ТРЕБУЕТСЯ (REQUIRED)», «ДОЛЖЕН (SHALL)», «НЕ ДОЛЖЕН
(SHALL NOT)», «СЛЕДУЕТ (SHOULD)», «НЕ СЛЕДУЕТ (SHOULD NOT)»,
«РЕКОМЕНДУЕТСЯ (RECOMMENDED)», «МОЖЕТ (MAY)» и «НЕОБЯЗАТЕЛЬНО
(OPTIONAL)», они должны интерпретироваться так, как описано в RFC 2119
[6]. RFC 2119 определяет использование этих ключевых слов, чтобы
максимально прояснить намерение документов пути стандартизации. Те же
ключевые слова используются в этом документе, чтобы способствовать
бесперебойной работе WG и уменьшить вероятность путаницы в процессах.
1.1. Подход IETF к стандартизации
Знакомство с документом The Internet Standards Process [1] необходимо для
полного понимания философии, процедур и руководящих принципов, описанных
в этом документе.
1.2. Роли в рабочей группе
Документ «Organizations Involved in the IETF Standards Process» [2]
описывает роли ряда лиц в рабочей группе, включая председателя рабочей
группы и редактора документа. Далее в этом документе эти описания
расширяются.
2. Формирование рабочей группы
Рабочие группы IETF (WG) являются основным механизмом разработки
спецификаций и руководящих принципов IETF, многие из которых предназначены
быть стандартами или рекомендациями. Рабочая группа может быть учреждена
по инициативе директора области либо инициирована отдельным лицом или
группой лиц. Любой, кто заинтересован в создании рабочей группы IETF,
ДОЛЖЕН (MUST) получить совет и согласие директора(ов) области IETF, к
области которого относилась бы рабочая группа, и ДОЛЖЕН (MUST) пройти
формальные шаги, подробно изложенные в этом разделе.
Рабочие группы обычно создаются для решения конкретной проблемы либо для
подготовки одного или нескольких конкретных результатов работы
(руководства, спецификации стандарта и т. п.). Как правило, предполагается,
что рабочие группы будут кратковременными по своему характеру. По
завершении своих целей и достижении поставленных задач рабочая группа
прекращает работу. Рабочая группа может быть также прекращена по другим
причинам (см. раздел 4). В качестве альтернативы, при согласии IESG,
директора области, председателя WG и участников WG, цели или поручение
рабочей группы могут быть расширены путём изменения устава рабочей группы
посредством процесса изменения устава (см. раздел 5).
2.1. Критерии формирования
При определении того, уместно ли создавать рабочую группу, директор(а)
области и IESG рассмотрят несколько вопросов:
- Являются ли вопросы, которыми планирует заниматься рабочая группа,
ясными и значимыми для интернет-сообщества?
- Являются ли цели конкретными и разумно достижимыми, и могут ли они быть
достигнуты в разумные сроки?
- Каковы риски и срочность работы, определяющие требуемый уровень усилий?
- Пересекается ли деятельность рабочей группы с деятельностью другой
рабочей группы? Если да, создание рабочей группы всё ещё может быть
уместным, однако директора областей должны тщательно рассмотреть этот
вопрос, поскольку разделение усилий часто размывает доступную
техническую экспертизу.
- Имеется ли в IETF достаточный интерес к теме рабочей группы, причём
достаточно ли людей готовы приложить усилия для получения желаемого
результата (например, спецификации протокола)? Рабочие группы требуют
значительных усилий, включая управление процессом рабочей группы,
редактирование документов рабочей группы и вклад в текст документа.
Опыт IETF показывает, что обычно все эти роли не могут выполняться
одним человеком; помимо как минимум одного-двух десятков людей, которые
будут посещать встречи рабочей группы и вносить вклад в список рассылки,
как правило, требуется минимум четыре или пять активных участников на
управленческих позициях. ПРИМЕЧАНИЕ: интерес должен быть достаточно
широким, чтобы рабочая группа не воспринималась лишь как деятельность
одного поставщика.
- Имеется ли в IETF достаточная экспертиза по теме рабочей группы и
заинтересованы ли эти люди в участии в работе рабочей группы?
- Существует ли, по-видимому, база заинтересованных потребителей
(конечных пользователей) для планируемой работы? Интерес потребителей
может измеряться участием конечных пользователей в процессе IETF, а
также менее прямыми способами.
- Имеет ли IETF разумную роль в определении технологии? Существует много
связанных с Интернетом технологий, которые могут быть интересны членам
IETF, но в некоторых случаях IETF может быть не в состоянии повлиять на
развитие технологии в «реальном мире». Это может происходить, например,
если технология разрабатывается другим органом по стандартизации или
отраслевым консорциумом.
- Понятны ли все известные вопросы прав интеллектуальной собственности,
относящиеся к усилиям предлагаемой рабочей группы?
- Является ли предлагаемый план работ открытой деятельностью IETF или это
попытка «благословить» технологию, не относящуюся к IETF, при которой
влияние вклада участников IETF может быть ограничено?
- Имеется ли хорошее понимание любой существующей работы, относящейся к
темам, которыми будет заниматься предлагаемая рабочая группа? Сюда
входит работа как внутри IETF, так и за её пределами.
- Пересекаются ли цели рабочей группы с известной работой в другом органе
по стандартизации и, если да, налажено ли достаточное взаимодействие?
Учитывая приведённые выше критерии, директор(а) направления, руководствуясь своим наилучшим суждением, решит(ат), следует ли продолжить формирование группы посредством процесса утверждения устава.
2.2. Устав
Для формирования рабочей группы требуется устав, который главным образом согласовывается между предполагаемым председателем рабочей группы и соответствующим(и) директором(ами) направления, хотя окончательное утверждение осуществляет IESG по рекомендации Internet Architecture Board (IAB). Устав является договором между рабочей группой и IETF о выполнении набора задач. Устав:
1. Перечисляет относящуюся к рабочей группе административную информацию;
2. Устанавливает направление или цели рабочей группы и описывает подход, который будет применён для достижения целей; и
3. Перечисляет набор контрольных этапов вместе со сроками их завершения.
Когда предполагаемый(е) председатель(и), директор направления и Секретариат IETF удовлетворены формой и содержанием устава, он становится основой для формирования рабочей группы. Следует отметить, что директор направления МОЖЕТ (MAY) потребовать проведения исследовательской встречи Birds of a Feather (BOF), описанной ниже, чтобы оценить уровень поддержки рабочей группы до представления устава в IESG и IAB на утверждение.
Уставы могут периодически пересогласовываться, чтобы отражать текущее состояние, организацию или цели рабочей группы (см. раздел 5). Следовательно, устав является договором между IETF и рабочей группой, которая обязуется выполнить явно определённые контрольные этапы и предоставить конкретные «продукты».
В частности, каждый устав состоит из следующих разделов:
Наименование рабочей группы
Наименование рабочей группы следует делать достаточно описательным или идентифицируемым. Кроме того, группа должна определить акроним (максимум 8 печатаемых символов ASCII) для ссылки на группу в каталогах IETF, списках рассылки и общих документах.
Председатель(и)
Рабочая группа может иметь одного или нескольких председателей для выполнения административных функций группы. Должен быть указан адрес или адреса электронной почты председателя(ей). Как правило, число председателей рабочей группы ограничено двумя.
Направление и директор(а) направления
Наименование направления IETF, с которым связана рабочая группа, а также имя и адрес электронной почты соответствующего(их) директора(ов) направления.
Ответственный директор направления
Директор направления, выступающий основным контактным лицом IESG для рабочей группы.
Список рассылки
Рабочая группа IETF ДОЛЖНА (MUST) иметь общий интернет-список рассылки. Большая часть работы рабочей группы IETF будет проводиться в списке рассылки. Устав рабочей группы ДОЛЖЕН (MUST) включать:
1. Адрес, на который участник направляет запрос на подписку, и процедуры, которым следует следовать при подписке,
2. Адрес, на который участник направляет представления, а также специальные процедуры, если таковые имеются, и
3. Местонахождение архива списка рассылки. Архив сообщений ДОЛЖЕН (MUST) поддерживаться в общедоступном месте, доступном через FTP или через веб.
В качестве услуги сообществу Секретариат IETF ведёт архивы списков рассылки рабочих групп. Чтобы воспользоваться этой услугой, списки рассылки рабочих групп ДОЛЖНЫ (MUST) включать адрес "wg_acronym-archive@lists.ietf.org" (где "wg_acronym" — акроним рабочей группы) в список рассылки, чтобы копия всех сообщений списка рассылки записывалась в архиве Секретариата. Эти архивы находятся по адресу ftp://ftp.ietf.org/ietf-mail-archive. Для обеспечения устойчивости рабочим группам СЛЕДУЕТ (SHOULD) поддерживать дополнительный архив, отдельный от архива, поддерживаемого Секретариатом.
Описание рабочей группы
Направленность и назначение группы должны быть кратко изложены. Прочитав только этот раздел, человек сможет определить, относится ли эта группа к его собственной работе. Первый абзац должен содержать краткое описание проблемной области, оснований, цели или целей и подхода или подходов, запланированных для рабочей группы. Этот абзац можно использовать в качестве обзора работы рабочей группы.
Чтобы облегчить оценку предполагаемой работы и обеспечить постоянное руководство для рабочей группы, устав должен описывать решаемую проблему, а в нём следует обсудить цели и ожидаемое воздействие в отношении:
- Архитектуры
- Эксплуатации
- Безопасности
- Управления сетью
- Масштабирования
- Перехода (где применимо)
Цели и контрольные этапы
Устав рабочей группы ДОЛЖЕН (MUST) устанавливать график для конкретных рабочих элементов. Хотя он может пересогласовываться с течением времени, перечень контрольных этапов и дат облегчает директору направления отслеживание хода работ и состояния рабочей группы, а потенциальным участникам необходим для выявления критически важных моментов для внесения вклада. Контрольные этапы должны состоять из результатов поставки, которые можно квалифицировать как свидетельствующие о конкретном достижении; например, «Internet-Draft завершён» допустимо, но «обсудить по электронной почте» — нет. Полезно устанавливать контрольные этапы на каждые 3–6 месяцев, чтобы можно было легко оценивать прогресс. Ожидается, что этот перечень контрольных этапов будет периодически обновляться (см. раздел 5).
Пример устава WG включён в Приложение A.
2.3. Рассмотрение и утверждение устава
Предлагаемые рабочие группы часто состоят из технически компетентных участников, не знакомых с историей архитектуры Интернета или процессами IETF. Это, к сожалению, может привести к хорошему консенсусу рабочей группы относительно плохого проекта. Чтобы облегчить работу рабочей группы, директор направления может назначить консультанта из числа опытных участников IETF. (Консультанты описаны в разделе 6.) По усмотрению директора направления утверждение новой WG может не быть предоставлено при отсутствии достаточных ресурсов консультантов.
После того как директор направления (и руководство направления, если директор направления сочтёт это уместным) утвердил устав рабочей группы, устав представляется на рассмотрение IAB и утверждение IESG. После периода рассмотрения продолжительностью не менее недели предлагаемый устав размещается в списке рассылки IETF-announce в качестве публичного уведомления о том, что рассматривается формирование рабочей группы. Одновременно предлагаемый устав также размещается в списке рассылки "new-work".
Этот список рассылки был создан, чтобы информировать квалифицированных представителей других организаций по стандартизации о готовящихся рабочих группах IETF. После ещё одного периода рассмотрения продолжительностью не менее недели IESG МОЖЕТ (MAY) утвердить устав без изменений, МОЖЕТ (MAY) запросить внесение изменений в устав либо МОЖЕТ (MAY) отказать в утверждении формирования рабочей группы.
Если IESG утверждает формирование рабочей группы, она возвращает утверждённый устав Секретариату IETF, который регистрирует и вносит информацию в базу данных отслеживания IETF. Секретариат IETF объявляет о рабочей группе в IETF-announce.
2.4. Birds of a Feather (BOF)
Часто неясно, заслуживает ли вопрос формирования рабочей группы. Чтобы облегчить изучение вопросов, IETF предоставляет возможность проведения сессии Birds of a Feather (BOF), а также раннего создания списка электронной рассылки для предварительного обсуждения. Кроме того, BOF может служить форумом для одного представления или обсуждения без какого-либо намерения сформировать рабочую группу.
BOF — это сессия на встрече IETF, допускающая «исследование рынка» и технический «мозговой штурм». Любое лицо может запросить разрешение на проведение BOF по какой-либо теме. Запрос ДОЛЖЕН (MUST) быть подан соответствующему директору направления, который должен утвердить BOF до его включения в расписание. Лицу, запрашивающему BOF, может быть предложено выступить председателем BOF.
Председатель BOF также отвечает за предоставление отчёта о результатах BOF. Если директор направления утверждает проведение, BOF затем включается в расписание путём направления запроса на agenda@ietf.org с копиями директору(ам) направления. Для включения BOF в расписание необходимы описание и повестка BOF.
Доступное для BOF время ограничено, и BOF проводятся по усмотрению директоров направления соответствующего направления. Директор(а) направления может (могут) потребовать дополнительных подтверждений до разрешения BOF. Например:
- Директор направления МОЖЕТ (MAY) потребовать создания открытого списка электронной рассылки до разрешения BOF. Это обеспечивает первоначальный обмен и совместное согласование рамок, словаря и подходов, чтобы сделать время, проведённое на BOF, более продуктивным.
- Директор направления МОЖЕТ (MAY) потребовать проведения BOF до создания рабочей группы (см. раздел 2.2).
- Директор направления МОЖЕТ (MAY) потребовать наличия проекта устава WG до проведения BOF.
- Директор направления МОЖЕТ (MAY) потребовать не проводить BOF до публикации Internet-Draft, описывающего предлагаемую технологию, чтобы его можно было использовать как основу для обсуждения на BOF.
В общем случае BOF по определённой теме проводится только один раз (ОДИН слот на одном пленарном заседании IETF). При необычных обстоятельствах директора направления могут по своему усмотрению разрешить BOF собраться во второй раз. BOF не разрешается собираться три раза. Следует отметить, что при прочих равных условиях WG будет предоставляться приоритет для места проведения встреч перед BOF. Кроме того, иногда BOF могут проводиться для целей, отличных от обсуждения формирования рабочей группы.
Обычно результат BOF будет одним из следующих:
- Интерес к теме и сосредоточенность на ней были достаточными, чтобы обосновать формирование WG;
- Хотя в BOF был выражен разумный уровень интереса, некоторый иной критерий формирования рабочей группы не был выполнен (см. раздел 2.1).
- Обсуждение пришло к плодотворному заключению с результатами, которые должны быть записаны и опубликованы, однако создавать WG нет необходимости; или
- Интереса к теме было недостаточно, чтобы обосновать формирование WG.
3. Работа рабочей группы
IETF предъявляет базовые требования к открытому и справедливому участию и к тщательному рассмотрению технических альтернатив. В рамках этих ограничений рабочие группы автономны, и каждая определяет большинство деталей собственной работы в отношении участия в сессиях, достижения завершённости и т. п. Основное правило работы состоит в том, что принятие или согласие достигается посредством «приблизительного консенсуса» рабочей группы. Участникам WG следует особо учитывать требования к раскрытию конфликтов интересов, изложенные в [2].
С течением времени возникнет ряд процедурных вопросов и проблем, и функция председателя(ей) рабочей группы состоит в управлении процессом группы, помня, что общая цель группы — продвигаться к достижению приблизительного консенсуса при реализации целей и задач рабочей группы.
Существует немного жёстких и неизменных правил организации или ведения деятельности рабочей группы, однако с течением времени сформировался набор успешно зарекомендовавших себя руководящих принципов и практик. Они перечислены здесь; при этом фактический выбор обычно определяется участниками рабочей группы и председателем(ями).
3.1. Планирование сессий
Для согласованного, структурированного взаимодействия WG председатель(и) ДОЛЖЕН (MUST) опубликовать проект повестки задолго до фактической сессии. В повестку следует включить как минимум:
- Пункты для обсуждения;
- Оценочное время, необходимое для каждого пункта; и
- Ясное указание, какие документы участникам потребуется прочитать до сессии, чтобы быть хорошо подготовленными.
Публикация повестки рабочей группы должна включать отправку копии повестки в список рассылки рабочей группы и на agenda@ietf.org.
Все действия рабочей группы должны предприниматься на публичном форуме, и широкое участие поощряется. Рабочая группа будет вести значительную часть своей работы через списки рассылки электронной почты, но может периодически встречаться для обсуждения и рассмотрения состояния и хода задач, разрешения конкретных вопросов и определения будущей деятельности. Пленарные заседания IETF являются основной площадкой для таких очных сессий рабочих групп, и обычно, хотя это не требуется, также могут проводиться активные «промежуточные» очные встречи, телефонные конференции или видеоконференции. К промежуточным встречам применяются те же правила заблаговременного уведомления, отчётности, открытого участия и процесса, которые применяются к другим встречам рабочих групп.
Все заседания рабочей группы (включая проводимые вне встреч IETF) подлежат отражению в отчёте посредством предоставления протоколов. В эти протоколы следует включать повестку заседания, описание обсуждения, включая все принятые решения, и список присутствующих. Председатель рабочей группы отвечает за обеспечение составления и распространения протоколов заседаний, хотя фактическую работу может выполнять лицо, назначенное Председателем рабочей группы. Протоколы подлежат представлению в пригодном для печати тексте ASCII для публикации в IETF Proceedings и размещения в IETF Directories и должны направляться по адресу: minutes@ietf.org
3.2. Место проведения заседания
Каждая рабочая группа определяет такое соотношение обмена по электронной почте и очных заседаний, которое подходит для достижения её контрольных этапов. Электронная почта обеспечивает наиболее широкое участие; очные встречи часто позволяют лучше сосредоточиться и поэтому могут быть более эффективны для достижения консенсуса среди ядра участников рабочей группы.
При определении этого соотношения WG должна обеспечить, чтобы её процесс не приводил к исключению вклада участников, использующих только электронную почту. Решения, достигнутые во время очной встречи по темам или вопросам, которые не обсуждались в списке рассылки либо существенно отличаются от ранее достигнутого в списке рассылки консенсуса, ДОЛЖНЫ (MUST) быть рассмотрены в списке рассылки.
Встречи IETF
Если WG требуется заседание на встрече IETF, Председатель должен подать заявку на временные слоты, как только Секретариат IETF сделает первое объявление об этой встрече IETF в списке WG-chairs. Время заседаний является дефицитным ресурсом на встречах IETF, поэтому раннее размещение заявок облегчит координацию расписания для WG, которым требуется один и тот же набор экспертов.
Заявка на заседание WG на встрече IETF ДОЛЖНА (MUST) быть направлена в Секретариат IETF по адресу agenda@ietf.org. Некоторые Area Directors могут захотеть координировать заседания WG в своей области и потребовать, чтобы временные слоты координировались через них. В этом случае это будет отмечено в объявлении о встрече IETF. Запрос WG на планирование ДОЛЖЕН (MUST) содержать:
- название и полное наименование рабочей группы;
- запрашиваемую продолжительность времени;
- примерный план повестки WG, который предполагается рассмотреть;
- оценочное число людей, которые будут присутствовать на заседании WG;
- связанные WG, которые не следует планировать на тот же временной слот (слоты); и
- при желании может быть добавлен запрос на передачу заседания WG через Интернет в аудио- и видеорежиме.
ПРИМЕЧАНИЕ: Хотя открытое обсуждение и вклад имеют существенное значение для успеха рабочей группы, Председатель отвечает за обеспечение продвижения вперёд. Когда это приемлемо для WG, Председатель может призвать к ограниченному участию (но не к ограниченному присутствию!) на заседаниях рабочих групп IETF с целью достижения продвижения. В таком случае Председатель рабочей группы имеет полномочие отказать любому лицу в предоставлении слова, если оно не подготовлено либо иным образом излагает ненадлежащий материал или, по мнению Председателя, нарушает процесс WG. Если лицо продолжает нарушающее поведение, Председателю следует проконсультироваться с Area Director(s).
В сети
Может быть весьма полезно проводить обмены по электронной почте так же, как очное заседание: с опубликованным расписанием и повесткой, а также с непрерывным подведением итогов и опросом о консенсусе.
Многие участники рабочей группы считают, что обсуждение в списке рассылки — лучшее место для рассмотрения и разрешения вопросов и принятия решений. Выбор стиля работы делает сама рабочая группа. Однако важно отметить, что обсуждение по электронной почте в Интернете доступно значительно более широкому кругу заинтересованных лиц, чем участие во встречах IETF, вследствие времени и расходов, требуемых для присутствия.
Как и на очных заседаниях, иногда одно или несколько лиц могут вести себя в списке рассылки так, что это нарушает продвижение WG. В таких случаях Председателю следует попытаться пресечь это поведение путём непосредственного общения с нарушающим лицом, а не в открытом списке рассылки. Если поведение продолжается, Председатель должен привлечь Area Director к рассмотрению вопроса. В крайнем случае и после явных предупреждений Area Director с одобрения IESG может запросить у сопровождающего списка рассылки заблокировать возможность нарушающего лица отправлять сообщения в список рассылки. (Если программное обеспечение списка рассылки допускает такую операцию.) Даже если это сделано, лицу не должно быть запрещено получать сообщения, отправленные в список. Могут рассматриваться другие методы управления списком рассылки, но они должны быть одобрены AD(s) и IESG.
3.3. Управление заседанием
Рабочие группы принимают решения посредством процесса «приблизительного консенсуса». Консенсус IETF не требует согласия всех участников, хотя это, конечно, предпочтительно. В целом преобладающей должна быть позиция рабочей группы. (Однако необходимо отметить, что «преобладание» не определяется на основе количества или настойчивости, а скорее на основе более общего ощущения согласия.) Консенсус может определяться поднятием рук, гудением или любыми другими средствами, с которыми соглашается WG (разумеется, на основе приблизительного консенсуса). Обратите внимание, что 51% рабочей группы не соответствует «приблизительному консенсусу», а 99% — лучше, чем приблизительный консенсус. Председатель определяет, достигнут ли приблизительный консенсус.
Оценить уровень консенсуса в списке рассылки может быть особенно трудно. Есть два различных случая, когда рабочая группа может пытаться понять уровень консенсуса посредством обсуждения в списке рассылки. Но в обоих случаях объём сообщений по теме сам по себе не является хорошим показателем консенсуса, поскольку значительную часть трафика могут создавать одно или два лица.
В случае, когда консенсус, достигнутый во время очной встречи, проверяется в списке рассылки, необходимо учитывать людей, которые присутствовали на встрече и выразили согласие. Если на встрече присутствовало 100 человек и только несколько лиц
в списке рассылки не согласны с консенсусом встречи, то консенсус следует считать подтверждённым. Обратите внимание, что процессу подтверждения следует предоставить достаточно времени, чтобы читатели списка рассылки могли понять и рассмотреть любые возражения, которые могут быть высказаны в списке. Обычного двухнедельного периода последнего вызова должно быть достаточно для этого.
Другой случай — когда обсуждение полностью велось в списке рассылки. В этом случае определить уровень консенсуса может быть труднее, поскольку большинство людей, подписанных на списки рассылки, активно не участвуют в обсуждениях в списке. Оценка уровня консенсуса оставлена на усмотрение председателя рабочей группы. Наиболее часто используемый метод состоит в том, что председатель рабочей группы излагает то, что он или она считает консенсусной позицией, и одновременно запрашивает у списка комментарии по заявленному заключению.
Задача управления заседаниями рабочей группы состоит в уравновешивании потребности в открытом и справедливом рассмотрении вопросов с потребностью двигаться вперёд. Окончательная ответственность за достижение этого равновесия лежит на рабочей группе в целом. Председатель отвечает за надзор над процессом, но может делегировать непосредственное управление процессом формально назначенному Facilitator.
Иногда уместно вернуться к теме, повторно оценить альтернативы или улучшить понимание группой относящегося к делу решения. Однако ненужных повторных обсуждений вопросов можно избежать, если Председатель обеспечит, чтобы основные доводы обсуждения (и его итог) были обобщены и заархивированы после завершения обсуждения. Также хорошей практикой является отмечать важные решения/достигнутый консенсус по электронной почте в протоколах следующего «очного» заседания и кратко излагать историю принятия решения в окончательных документах, выпускаемых WG.
Для содействия продвижению вперёд Председатель рабочей группы может решить отклонить или отложить рассмотрение вклада участника на основании следующих критериев:
Старый
Вклад относится к теме, которая уже была разрешена, и повторяет ранее доступную информацию;
Незначительный
Вклад является новым и относится к теме, которая уже была разрешена, но считается имеющим незначительное значение для существующего решения;
Сроки
Вклад относится к теме, которую рабочая группа ещё не открыла для обсуждения; или
Область действия
Вклад находится вне области действия устава рабочей группы.
3.4. Разногласия и апелляции
Споры возможны на различных стадиях процесса IETF. Насколько возможно, процесс спроектирован так, чтобы можно было достигать компромиссов и подлинного консенсуса; однако бывают случаи, когда даже наиболее разумные и знающие люди не могут прийти к согласию. Для достижения целей открытости и справедливости такие конфликты должны разрешаться посредством процесса открытого рассмотрения и обсуждения.
Формальные процедуры запроса рассмотрения действий WG, Председателя, Area Director или IESG и подачи апелляций документированы в The Internet Standards Process [1].
4. Прекращение работы рабочей группы
Рабочие группы обычно получают устав для выполнения конкретной задачи или задач. После выполнения задач группа будет расформирована. Однако, если WG выпускает Proposed или Draft Standard, WG часто становится неактивной, а не расформировывается (то есть WG больше не будет вести формальную деятельность, но список рассылки останется доступным для рассмотрения работы по мере её перехода к статусам Draft Standard и Standard.)
Если в какой-либо момент становится очевидно, что рабочая группа не способна завершить работу, изложенную в уставе, либо если предположения, на которых основывалась эта работа, были изменены в ходе обсуждения или опытом, Area Director после консультации с рабочей группой может:
1. Изменить устав, чтобы перефокусировать её задачи,
2. Выбрать нового Председателя (Председателей), или
3. Расформировать группу.
Если рабочая группа не согласна с выбором Area Director, она может подать апелляцию в IESG (см. раздел 3.4).
5. Изменение устава рабочей группы
Обновлённые контрольные этапы при необходимости повторно согласовываются с Area Director и IESG, а затем представляются в Секретариат IESG: iesg-secretary@ietf.org.
Изменение устава рабочей группы (кроме пересмотра контрольных этапов) следует тем же процедурам, что и первоначальное утверждение устава (см. раздел 2). Пересмотренный устав должен быть представлен в IESG и IAB для одобрения. Как и при первоначальном утверждении устава, IESG может одобрить новый устав без изменений, может запросить внесение изменений в новый устав (включая требование, чтобы Working Group продолжила использовать старый устав), либо может отказаться одобрить рабочую группу с изменённым уставом. В последнем случае рабочая группа расформировывается.
6. Роли персонала
Рабочие группы требуют значительной заботы и поддержки. Помимо общего участия, успешным рабочим группам помогают усилия участников, исполняющих конкретные функциональные роли. Area Director должен согласовать конкретных лиц, исполняющих роли Председателя WG и Консультанта рабочей группы, и они действуют по усмотрению Area Director.
6.1. Председатель WG
Председатель рабочей группы заботится о продвижении вперёд через справедливый и открытый процесс и обладает широким усмотрением при ведении дел WG. Председатель должен обеспечить выполнение ряда задач непосредственно либо другими лицами, назначенными для выполнения этих задач.
Председатель несёт ответственность и обладает полномочием принимать от имени рабочей группы решения по всем вопросам процесса и кадрового состава рабочей группы в соответствии с правилами IETF. AD обладает полномочием и несёт ответственность помогать в принятии этих решений по запросу Председателя или когда обстоятельства оправдывают такое вмешательство.
Ответственность Председателя включает по меньшей мере следующее:
Обеспечить управление процессом и содержанием WG
Председатель несёт окончательную ответственность за обеспечение того, чтобы рабочая группа продвигалась вперёд и соблюдала свои контрольные этапы. Председатель также отвечает за обеспечение того, чтобы рабочая группа действовала открыто и справедливо. Для некоторых рабочих групп этого можно добиться, если Председатель выполняет все действия, связанные с управлением. В других рабочих группах — особенно с большим числом участников или участием, вызывающим разногласия, — полезно распределить функции управления процессом и/или секретарские функции между другими участниками. Управление процессом относится строго к стилю взаимодействия рабочей группы, а не к его содержанию. Оно обеспечивает справедливость и выявляет избыточность. Секретарская функция включает редактирование документов. Довольно часто рабочая группа поручает задачу редактора спецификации одному или двум участникам. Иногда они также входят в состав описываемой ниже проектной группы.
Модерировать список рассылки WG
Председателю следует стремиться обеспечивать, чтобы обсуждения в этом списке были релевантными и приходили к консенсусным соглашениям. Председателю следует обеспечивать подведение итогов обсуждений в списке и надлежащее документирование результатов (во избежание повторений). Председатель также может решить запланировать организованные онлайновые «сессии» с повесткой дня и ожидаемыми результатами. Они могут быть организованы как настоящие заседания, проводимые в течение нескольких дней (чтобы обеспечить участие через Интернет).
Организовывать, подготавливать и вести очные и онлайновые формальные сессии.
Планировать сессии WG
Председатель должен заранее планировать и объявлять все сессии WG (см. раздел 3.1).
Сообщать результаты сессий
Председатель и/или Секретарь должны обеспечивать ведение протоколов сессии и распространение списка присутствующих (см. раздел 3.1).
Сразу после сессии Председатель WG ДОЛЖЕН (MUST) предоставить директору области очень краткий отчёт (примерно один абзац, по электронной почте) о сессии.
Распределять рабочую нагрузку
Разумеется, в каждой WG будут участники, которые не могут (или не хотят) выполнять какую-либо работу вообще. Большую часть времени основной объём работы выполняют несколько преданных делу участников. Задача Председателя — мотивировать достаточное число экспертов для справедливого распределения рабочей нагрузки.
Разработка документов
Рабочие группы выпускают документы, и документам нужны авторы. Председатель должен обеспечивать, чтобы авторы документов WG вносили изменения, согласованные WG (см. раздел 6.3).
Публикация документов
Председатель и/или редактор документа будут работать с RFC Editor, чтобы обеспечить соответствие документа требованиям к публикации RFC [5] и координировать любые редакторские изменения, предложенные RFC Editor. Особую обеспокоенность вызывает то, чтобы все участники одновременно работали с одной и той же версией документа.
Реализации документов
Согласно процедурам, описанным в [1], Председатель отвечает за документирование конкретных реализаций, которые позволяют спецификации соответствовать статусу Draft или Internet Standard, вместе с документацией по тестированию взаимодействия этих реализаций.
6.2. Секретарь WG
Ведение протоколов и редактирование документов рабочей группы часто выполняются специально назначенным участником или набором участников. В этой роли задача Секретаря состоит в фиксации решений WG, а не в выполнении основной спецификационной работы.
6.3. Редактор документа
Большинство рабочих групп IETF сосредоточивают свои усилия на документе или наборе документов, фиксирующих результаты работы группы. Рабочая группа обычно назначает одного или нескольких человек редактором конкретного документа. Редактор документа отвечает за обеспечение того, чтобы содержание документа точно отражало решения, принятые рабочей группой.
Как общая практика, должности Председателя рабочей группы и Редактора документа занимают разные лица, чтобы помочь обеспечить точное отражение в итоговых документах консенсуса рабочей группы и соблюдение всех процессов.
6.4. Фасилитатор WG
Когда заседания имеют тенденцию отвлекаться от темы или вызывать разногласия, часто полезно поручить одному участнику задачу «управления процессом». Его задача — наблюдать за характером, а не содержанием взаимодействий участников. То есть он уделяет внимание стилю обсуждения и расписанию повестки дня, а не вносит непосредственный технический вклад самостоятельно.
6.5. Проектные группы
Часто полезно и, возможно, неизбежно, чтобы подгруппа рабочей группы разработала предложение по решению конкретной проблемы. Такая подгруппа называется проектной группой. Чтобы проектная группа оставалась небольшой и гибкой, допустимы закрытое членство и частные заседания. Проектные группы могут варьироваться от неформального разговора людей в коридоре до формального состава экспертов-добровольцев, которых председатель WG или AD назначает для решения спорной проблемы. Результат работы проектной группы всегда подлежит утверждению, отклонению или изменению WG в целом.
6.6. Консультант рабочей группы
По усмотрению директора области рабочей группе может быть назначен Консультант. Консультанты обладают специальной технической подготовкой, соответствующей WG, а также опытом в архитектуре Интернета и процессе IETF.
6.7. Директор области
Директора областей отвечают за обеспечение того, чтобы рабочие группы в их области создавали согласованные, скоординированные, архитектурно непротиворечивые и своевременные результаты в качестве вклада в общие результаты IETF.
7. Документы рабочей группы
7.1. Документы сессии
Все относящиеся к делу документы, которые будут обсуждаться на сессии, следует опубликовать и сделать доступными как Internet-Drafts не позднее чем за две недели до начала сессии. Любой документ, не соответствующий этому сроку публикации, может обсуждаться на сессии рабочей группы только при специальном одобрении председателя(ей) рабочей группы. Поскольку важно, чтобы члены рабочей группы имели достаточно времени для рассмотрения всех документов, такое исключение следует предоставлять только при необычных обстоятельствах. Окончательную повестку сессии следует разместить в списке рассылки рабочей группы не позднее чем за две недели до сессии и в это же время направить на agenda@ietf.org для публикации на веб-сайте IETF.
7.2. Internet-Drafts (I-D)
Каталог Internet-Drafts предоставляется рабочим группам как ресурс для размещения и распространения рабочих копий документов рабочей группы. Это хранилище реплицируется в различных точках Интернета. Рекомендуется размещать черновики документов, как только они становятся достаточно стабильными.
Здесь подчёркивается, что Internet-Drafts являются рабочими документами и не имеют какого-либо официального статуса стандарта. В конечном счёте они могут стать документом на пути стандартизации или исчезнуть из поля зрения. Internet-Drafts направляются по адресу: internet-drafts@ietf.org
Формат Internet-Draft должен быть таким же, как для RFC [2]. Кроме того, I-D должен содержать:
- начальный стандартный шаблонный текст, предоставляемый Секретариатом на его веб-сайте и в каталоге ftp;
- имя файла I-D; и
- дату истечения срока действия I-D.
Полная спецификация требований к Internet-Draft содержится в файле "1id-guidelines.txt" в каталоге Internet-Drafts на сайте Internet Repository. Организация каталога Internet-Drafts описана в файле "1id-organization" в каталоге Internet-Drafts на сайте Internet Repository. Этот файл также содержит правила именования Internet-Drafts. (Дополнительные сведения об Internet-Drafts см. в [1].)
7.3. Request For Comments (RFC)
Работа рабочей группы IETF часто приводит к публикации одного или нескольких документов в составе серии Request For Comments (RFCs) [1]. Эта серия является архивной публикационной записью сообщества Интернета. Документ может быть написан отдельным лицом в рабочей группе, группой в целом с назначенным Редактором или другими лицами, не участвующими в IETF.
ПРИМЕЧАНИЕ: серия RFC является только механизмом публикации, и публикация не определяет статус документа в IETF. Статус определяется отдельными явными метками статуса, присваиваемыми IESG от имени IETF. Иными словами, читателю напоминается, что все Internet Standards публикуются как RFC, но НЕ все RFC определяют стандарты [4].
7.4. Last-Call рабочей группы
Когда WG решает, что документ готов к публикации, он может быть направлен в IESG для рассмотрения. В большинстве случаев определение того, что WG считает документ готовым к публикации, осуществляется посредством объявления Председателем WG Last-Call рабочей группы. Решение объявить Last-Call рабочей группы принимается по усмотрению Председателя WG, действующего совместно с директором области. Last-Call рабочей группы служит в её рамках той же цели, что и IESG Last-Call в более широком сообществе IETF (см. [1]).
7.5. Представление документов
Как только WG определила, что внутри WG существует хотя бы приблизительный консенсус относительно продвижения документа, необходимо выполнить следующее:
- Версия соответствующего документа в точности в том виде, в каком она согласована WG, ДОЛЖНА (MUST) находиться в каталоге Internet-Drafts.
- Соответствующий документ ДОЛЖЕН (MUST) быть отформатирован в соответствии с разделом 7.3.
- Председатель WG ДОЛЖЕН (MUST) отправить электронное письмо соответствующему директору области. Копия запроса также ДОЛЖНА (MUST) быть направлена в Секретариат IESG. Письмо ДОЛЖНО (MUST) содержать ссылку на имя файла I-D документа и запрашиваемое действие. Копия сообщения, направляемая в Секретариат IESG, предназначена для обеспечения регистрации запроса Секретариатом, чтобы он мог отслеживать продвижение документа в рамках процесса.
Если IESG не возвращает документ WG для дальнейшей разработки, дальнейшее продвижение документа становится ответственностью IESG. После одобрения IESG ответственность за окончательное решение совместно несут RFC Editor, Председатель WG и Редактор документа.
8. Рассмотрение документов
IESG рассматривает все документы, представленные для публикации как RFC. Обычно в случае представления от WG, предназначенного в качестве Informational или Experimental RFC, необходим минимальный обзор IESG. В случае документов на пути стандартизации проводится более обширное рассмотрение.
До того как IESG начнёт своё обсуждение документов на пути стандартизации, Секретариат IETF объявит "Last-Call" в списке рассылки IETF (см. [1]). Этот Last-Call объявит о намерении IESG рассмотреть документ и запросит окончательные комментарии от IETF в течение двух недель. Важно отметить, что Last-Call предназначен как краткая окончательная проверка с сообществом Интернета, чтобы удостовериться, что не были упущены или неправильно поняты важные вопросы. Last-Call не следует использовать как более общее углублённое рассмотрение.
Рассмотрение IESG учитывает ответы на Last-Call и приведёт к одному из следующих возможных выводов:
1. Документ принимается без изменений с запрошенным статусом.
Этот факт будет объявлен Секретариатом IETF в списке рассылки IETF и RFC Editor.
2. Документ принимается без изменений, но не с запрошенным статусом.
Этот факт будет объявлен Секретариатом IETF в списке рассылки IETF и RFC Editor (более подробную информацию см. в [1]).
3. Автору(ам)/WG предлагаются изменения, касающиеся содержания.
Предложения IESG должны быть ясными и прямыми, чтобы облегчить рабочей группе и авторам исправление спецификации. Если автор(ы)/WG могут удовлетворительно для IESG объяснить, почему изменения не необходимы, документ будет принят для публикации, как указано в пункте 1 выше. Если изменения внесены, пересмотренный документ может быть повторно представлен на рассмотрение IESG.
4. IESG предлагает изменения и рекомендует изменение статуса.
В указанном порядке соблюдаются процессы, описанные выше для пунктов 3 и 2.
5. Документ отклоняется.
Любое отклонение документа будет сопровождаться конкретными и исчерпывающими доводами IESG. Хотя процесс IETF и рабочих групп организован так, что эта альтернатива вряд ли возникнет для документов, поступающих от рабочей группы, IESG имеет право и обязанность отклонять документы, которые, по мнению IESG, в каком-либо отношении имеют критические недостатки.
Если какое-либо лицо или группа лиц считает, что рассмотрение
обращения было несправедливым, имеется возможность подать
процедурную жалобу. Механизм для этого типа жалоб описан в [1].
9. Соображения безопасности
Документы, описывающие процессы IETF, такие как этот, не влияют на
безопасность сетевой инфраструктуры или интернет-приложений.
Следует отметить, что все рабочие группы IETF обязаны рассматривать
и понимать последствия для безопасности любой разрабатываемой ими
технологии. Этот анализ должен быть включён в любые создаваемые в
результате RFC в разделе Security Considerations. Обратите внимание,
что одного лишь указания на существенную брешь в безопасности теперь
уже недостаточно. Разрабатываемые IETF технологии не должны
добавлять небезопасности в среду, в которой они используются.
10. Благодарности
Эта редакция данного документа в значительной степени опирается на
предыдущую версию (RFC 1603), редакторами которой были Erik Huizer
и Dave Crocker. Она была рассмотрена рабочей группой Poisson.
11. Ссылки
[1] Bradner, S., Editor, "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[2] Hovey, R., and S. Bradner, "The Organizations involved in the
IETF Standards Process", BCP 11, RFC 2028, October 1996.
[3] Gavin, J., "IAB and IESG Selection, Confirmation, and Recall
Process: Operation of the Nominating and Recall Committees", BCP
10, RFC 2282, February 1998.
[4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards",
RFC 1796, April 1995.
[5] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC
2223, October 1997.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Level", BCP 14, RFC 2119, March 1997.
12. Адрес редактора
Scott Bradner
Harvard University
1350 Mass Ave.
Cambridge MA
02138
USA
Phone +1 617 495 3864
EMail: sob@harvard.edu
Приложение: Образец устава рабочей группы
Working Group Name:
IP Telephony (iptel)
IETF Area:
Transport Area
Chair(s):
Jonathan Rosenberg <jdrosen@bell-labs.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allyn Romanow <allyn@mci.net>
Responsible Area Director:
Allyn Romanow <allyn@mci.net>
Mailing Lists:
General Discussion:iptel@lists.research.bell-labs.com
To Subscribe: iptel-request@lists.research.bell-labs.com
Archive: http://www.bell-labs.com/mailing-lists/siptel
Description of Working Group:
Прежде чем интернет-телефония сможет стать широко развёрнутой
услугой, необходимо развернуть ряд протоколов. К ним относятся
сигнализация и обмен возможностями, а также ряд «периферийных»
протоколов для предоставления связанных услуг.
Основная цель этой рабочей группы — разработать два таких
вспомогательных протокола и frameword document. Это:
1. Синтаксис обработки вызовов. При установлении вызова между двумя
конечными точками сигнализация, как правило, проходит через
несколько серверов (таких как gatekeeper H.323), которые отвечают
за пересылку, перенаправление или проксирование сообщений
сигнализации. Например, пользователь может совершить вызов на
j.doe@bigcompany.com. Сообщение сигнализации для инициирования
вызова поступит на некоторый сервер в bigcompany. Этот сервер может
сообщить вызывающему абоненту, что вызываемый абонент занят,
переслать запрос на инициацию вызова на другой сервер, расположенный
ближе к пользователю, либо полностью отклонить вызов (среди прочих
возможностей). Весьма желательно позволить вызываемому абоненту
влиять на этот процесс, направляя сервер при принятии им решения о
том, как действовать. Это может обеспечить широкий набор
продвинутых услуг персональной мобильности и агентов вызова.
Такие предпочтения могут быть выражены в синтаксисе обработки
вызовов, который может быть создан пользователем (или автоматически
сгенерирован некоторым инструментом), а затем загружен на сервер.
Группа разработает этот синтаксис и определит способы его безопасной
передачи и расширения. Результатом будет один RFC на пути
стандартизации.
2. Кроме того, группа подготовит документ модели услуг, который
описывает услуги, обеспечиваемые синтаксисом обработки вызовов, и
рассматривает, как может использоваться этот синтаксис. Результатом
этого документа будет один RFC.
3. Gateway Attribute Distribution Protocol. При совершении вызова
между IP-хостом и пользователем PSTN необходимо использовать
телефонный шлюз. Выбор таких шлюзов может основываться на многих
критериях, включая выраженные клиентом предпочтения, предпочтения
поставщика услуг и доступность шлюзов, помимо номера телефона
назначения. Поскольку могут использоваться шлюзы за пределами
административного домена хостов, необходим протокол, позволяющий
шлюзам в удалённых доменах распространять свои атрибуты (такие как
связность с PSTN, поддерживаемые кодеки и т. д.) сущностям в других
доменах, которым необходимо выбрать шлюз. Протокол должен обеспечивать
масштабируемую, эффективно использующую полосу пропускания и очень
безопасную передачу этих атрибутов. Группа исследует и разработает
протокол для этой цели, подготовит Internet-Draft и при необходимости
продвинет его до RFC.
Goals and Milestones:
May 98 Выпустить первый Internet-Draft по service framework
Jul 98 Представить framework ID в IESG для публикации в качестве RFC.
Aug 98 Выпустить первый Internet-Draft по Call Processing Syntax
Oct 98 Представить Call processing syntax в IESG для рассмотрения
в качестве Proposed Standard.
Dec 98 Достичь консенсуса по основам gateway attribute
distribution protocol
Jan 99 Представить Gateway Attribute Distribution protocol в IESG
для рассмотрения в качестве RFC (info, exp, stds track TB