О документе
Network Working Group S. Bradner
Request for Comments: 2026 Harvard University
BCP: 9 October 1996
Obsoletes: 1602
Category: Best Current Practice
Процесс стандартизации Интернета — редакция 3
1. ВВЕДЕНИЕ
Этот меморандум документирует процесс, в настоящее время используемый интернет-сообществом для стандартизации протоколов и процедур. Процесс стандартов Интернета является деятельностью Internet Society, которую от имени интернет-сообщества организуют и которой управляют Internet Architecture Board (IAB) и Internet Engineering Steering Group (IESG).
1.1 Стандарты Интернета
Интернет, представляющий собой свободно организованное международное сотрудничество автономных взаимосвязанных сетей, поддерживает связь между хостами благодаря добровольному соблюдению открытых протоколов и процедур, определённых стандартами Интернета. Также существует много изолированных взаимосвязанных сетей, которые не подключены к глобальному Интернету, но используют стандарты Интернета.
Описанный в этом документе процесс стандартов Интернета относится ко всем протоколам, процедурам и соглашениям, которые используются в Интернете или Интернетом, независимо от того, являются ли они частью набора протоколов TCP/IP. Однако в случае протоколов, разработанных и/или стандартизированных неинтернет-организациями, процесс стандартов Интернета обычно применяется к использованию протокола или процедуры в контексте Интернета, а не к спецификации самого протокола.
В общем случае стандарт Интернета — это спецификация, которая стабильна и хорошо понятна, технически состоятельна, имеет несколько независимых и совместимых реализаций со значительным опытом эксплуатации, пользуется существенной общественной поддержкой и явно полезна в некоторых или всех частях Интернета.
1.2 Процесс стандартизации Интернета
В общих чертах процесс создания стандарта Интернета прост: спецификация проходит период разработки и несколько итераций рассмотрения интернет-сообществом, а также пересмотра на основе опыта, принимается в качестве стандарта соответствующим органом (см. ниже) и публикуется. На практике процесс сложнее из-за: (1) трудности создания спецификаций высокого технического качества; (2) необходимости учитывать интересы всех затронутых сторон; (3) важности достижения широкого консенсуса сообщества; и (4) трудности оценки полезности конкретной спецификации для интернет-сообщества.
Цели процесса стандартов Интернета:
o техническое совершенство;
o предварительная реализация и тестирование;
o ясная, краткая и легко понимаемая документация;
o открытость и справедливость; и
o своевременность.
Описанные в этом документе процедуры предназначены быть справедливыми, открытыми и объективными; отражать существующую (доказанную) практику; и быть гибкими.
o Эти процедуры предназначены для предоставления справедливой, открытой и объективной основы для разработки, оценки и принятия стандартов Интернета. Они предоставляют достаточные возможности для участия и представления замечаний всеми заинтересованными сторонами. На каждом этапе процесса стандартизации спецификация неоднократно обсуждается, а её достоинства обсуждаются на открытых совещаниях и/или в публичных электронных списках рассылки; кроме того, она предоставляется для рассмотрения через всемирные онлайновые каталоги.
o Эти процедуры явно направлены на признание и принятие общепринятых практик. Таким образом, спецификация-кандидат должна быть реализована и протестирована на корректность работы и совместимость несколькими независимыми сторонами, а также использоваться во всё более требовательных средах, прежде чем она может быть принята в качестве стандарта Интернета.
o Эти процедуры обеспечивают значительную гибкость для адаптации к широкому разнообразию обстоятельств, возникающих в процессе стандартизации. Опыт показал, что эта гибкость жизненно важна для достижения перечисленных выше целей.
Цель технической состоятельности, требование предварительной реализации и тестирования и необходимость позволить всем заинтересованным сторонам представлять замечания требуют значительных времени и усилий. С другой стороны, быстрое развитие сетевых технологий сегодня требует своевременной разработки стандартов. Процесс стандартов Интернета предназначен для уравновешивания этих противоречащих целей. Считается, что этот процесс настолько короток и прост, насколько возможно без ущерба для технического совершенства, тщательного тестирования до принятия стандарта либо открытости и справедливости.
С момента своего возникновения Интернет был и, как ожидается, останется развивающейся системой, участники которой регулярно учитывают новые требования и технологии при его проектировании и реализации. Пользователям Интернета и поставщикам оборудования, программного обеспечения и услуг, поддерживающих его, следует ожидать и приветствовать эту эволюцию как один из основных принципов философии Интернета.
Описанные в этом документе процедуры являются результатом эволюции в течение ряда лет, обусловленной как потребностями растущего и всё более разнообразного интернет-сообщества, так и опытом.
1.3 Структура данного документа
Раздел 2 описывает публикации и архивы процесса стандартов Интернета. Раздел 3 описывает типы спецификаций стандартов Интернета. Раздел 4 описывает трек спецификаций стандартов Интернета. Раздел 5 описывает RFC категории Best Current Practice. Раздел 6 описывает процесс и правила стандартизации Интернета. Раздел 7 определяет способ обработки в рамках процесса стандартов Интернета спецификаций и практик, спонсируемых внешними сторонами, разработанных и контролируемых другими органами стандартизации или иными лицами. Раздел 8 описывает требования к уведомлениям и ведению записей. Раздел 9 определяет процесс отклонения, допускающий однократные исключения из некоторых требований данного документа. Раздел 10 излагает правила, необходимые для защиты прав интеллектуальной собственности в контексте разработки и использования стандартов Интернета. Раздел 11 содержит благодарности некоторым людям, участвовавшим в создании данного документа. Раздел 12 отмечает, что вопросы безопасности данным документом не рассматриваются. Раздел 13 содержит перечень нумерованных ссылок. Раздел 14 содержит определения некоторых терминов, используемых в данном документе. Раздел 15 приводит адреса электронной и обычной почты автора. Приложение A содержит перечень часто используемых сокращений.
2. ПУБЛИКАЦИИ, СВЯЗАННЫЕ СО СТАНДАРТАМИ ИНТЕРНЕТА
2.1 Requests for Comments (RFCs)
Каждая отдельная версия спецификации, связанной со стандартами Интернета, публикуется как часть серии документов «Request for Comments» (RFC). Эта архивная серия является официальным каналом публикации документов о стандартах Интернета и других публикаций IESG, IAB и интернет-сообщества. RFC можно получить с ряда интернет-хостов, используя анонимный FTP, gopher, World Wide Web и другие интернет-системы получения документов.
Серия сетевых документов RFC началась в 1969 году в рамках первоначального проекта ARPA по созданию территориально распределённой сети (ARPANET) (см. глоссарий сокращений в Приложении A). RFC охватывают широкий круг тем помимо стандартов Интернета: от раннего обсуждения новых исследовательских концепций до меморандумов о состоянии Интернета. Публикация RFC находится в непосредственной ответственности RFC Editor, действующего под общим руководством IAB.
Правила форматирования и представления RFC определены в [5].
Каждый RFC доступен в текстовом формате ASCII. Некоторые RFC также доступны в других форматах. Другие версии RFC могут содержать материал (например, диаграммы и рисунки), которого нет в версии ASCII, и могут быть отформатированы иначе.
*********************************************************
* *
* К спецификациям на пути стандартизации применяется *
* более строгое требование: текстовая версия ASCII *
* является определяющим источником, поэтому она *
* должна быть полной и точной спецификацией стандарта, *
* включая все необходимые диаграммы и иллюстрации. *
* *
*********************************************************
Статус спецификаций интернет-протоколов и служб периодически обобщается в RFC под названием "Internet Official Protocol Standards" [1]. Этот RFC показывает уровень зрелости и другую полезную информацию для каждой спецификации интернет-протокола или службы (см. раздел 3).
Некоторые RFC документируют стандарты Интернета. Эти RFC образуют подсерию «STD» серии RFC [4]. Когда спецификация принимается в качестве стандарта Интернета, ей присваивается дополнительная метка "STDxxx", но она сохраняет свой номер RFC и своё место в серии RFC. (см. раздел 4.1.3)
Некоторые RFC стандартизируют результаты обсуждений сообщества по поводу принципиальных положений или выводов о том, как наилучшим образом выполнять некоторые операции либо функции процесса IETF. Эти RFC образуют [повреждённый фрагмент исходника: "the specification has been adopted as a BCP, it is given the additional label \"BCPxxx\", but it keeps its RFC number and its place in the RFC series."] (см. раздел 5)
Не все спецификации протоколов или служб для Интернета должны или станут стандартами Интернета либо BCP. Такие спецификации, не относящиеся к пути стандартизации, не подпадают под правила стандартизации Интернета. Спецификации, не относящиеся к пути стандартизации, могут публиковаться непосредственно как RFC категории "Experimental" или "Informational" по усмотрению RFC Editor после консультации с IESG (см. раздел 4.2).
********************************************************
* *
* Важно помнить, что не все RFC являются документами *
* на пути стандартизации и что не все документы на *
* пути стандартизации достигают уровня стандарта *
* Интернета. Аналогично, не все RFC, описывающие *
* текущие практики, прошли проверку и утверждение, *
* необходимые для того, чтобы стать BCP. См. *
* RFC-1796 [6] для получения дополнительной *
* информации. *
* *
********************************************************
2.2 Интернет-черновики (Internet-Drafts)
В ходе разработки спецификации черновые версии документа предоставляются для неформального рассмотрения и комментирования путём размещения их в каталоге IETF "Internet-Drafts", который реплицируется на ряде интернет-хостов. Это делает развивающийся рабочий документ легко доступным широкой аудитории, облегчая процесс рассмотрения и пересмотра.
Internet-Draft, опубликованный в качестве RFC либо остававшийся без изменений в каталоге Internet-Drafts более шести месяцев без рекомендации IESG к публикации в качестве RFC, просто удаляется из каталога Internet-Drafts. В любой момент Internet-Draft может быть заменён более новой версией той же спецификации, что запускает шестимесячный период ожидания заново.
Internet-Draft НЕ является средством «публикации» спецификации; спецификации публикуются посредством механизма RFC, описанного в предыдущем разделе. Internet-Drafts не имеют формального статуса и могут быть изменены или удалены в любой момент.
********************************************************
* *
* Ни при каких обстоятельствах на Internet-Draft *
* не следует ссылаться в какой-либо статье, отчёте *
* или Request-for-Proposal, и поставщик также не *
* должен заявлять о соответствии Internet-Draft. *
* *
********************************************************
Примечание: Допустимо ссылаться на спецификацию на пути стандартизации, которую обоснованно можно ожидать опубликованной в качестве RFC, используя выражение "Work in Progress" без ссылки на Internet-Draft. Это также может быть сделано в самом документе на пути стандартизации, если спецификация, в которой сделана ссылка, оставалась бы полным и понятным документом как при наличии, так и при отсутствии ссылки на "Work in Progress".
3. СПЕЦИФИКАЦИИ СТАНДАРТОВ ИНТЕРНЕТА
Спецификации, подпадающие под процесс стандартизации Интернета, относятся к одной из двух категорий: техническая спецификация (Technical Specification, TS) и заявление о применимости (Applicability Statement, AS).
3.1 Техническая спецификация (Technical Specification, TS)
Техническая спецификация — это любое описание протокола, службы, процедуры, соглашения или формата. Она может полностью описывать все относящиеся к делу аспекты своего предмета либо оставлять один или несколько параметров или вариантов неопределёнными. TS может быть полностью самодостаточной либо включать материал из других спецификаций посредством ссылок на другие документы (которые могут быть или не быть стандартами Интернета).
TS должна включать утверждение о своей области действия и общем назначении использования (области применимости). Поэтому TS, изначально специфичная для конкретного контекста, должна содержать соответствующее утверждение. Однако TS не задаёт требования к своему использованию в Интернете; эти требования, зависящие от конкретного контекста, в котором TS включается в различные конфигурации систем, определяются заявлением о применимости.
3.2 Заявление о применимости (Applicability Statement, AS)
Заявление о применимости указывает, каким образом и при каких обстоятельствах одна или несколько TS могут применяться для поддержки конкретной возможности Интернета. AS может устанавливать варианты использования TS, не являющихся стандартами Интернета, как обсуждается в разделе 7.
AS идентифицирует относящиеся к делу TS и конкретный способ их объединения, а также может задавать конкретные значения или диапазоны параметров TS либо подфункции протокола TS, которые должны быть реализованы. AS также указывает обстоятельства, при которых использование конкретной TS является обязательным, рекомендуемым или факультативным (см. раздел 3.3).
AS может описывать конкретные способы использования TS в ограниченной «области применимости», например для интернет-маршрутизаторов, терминальных серверов, интернет-систем, взаимодействующих с Ethernet, или серверов баз данных на основе дейтаграмм.
Наиболее широким типом AS является всеобъемлющая спецификация соответствия, обычно называемая "requirements document", для определённого класса интернет-систем, например интернет-маршрутизаторов или интернет-хостов.
AS не может иметь на пути стандартизации более высокий уровень зрелости, чем любая TS на пути стандартизации, от которой зависит AS (см. раздел 4.1). Например, на TS уровня Draft Standard можно ссылаться из AS уровня Proposed Standard или Draft Standard, но не из AS уровня Standard.
3.3 Уровни требований
AS должна применять к каждой из TS, на которые она ссылается, один из следующих «уровней требований»:
(a) Обязательный: Реализация указанной TS в соответствии с AS требуется для достижения минимального соответствия. Например, IP и ICMP должны быть реализованы всеми интернет-системами, использующими набор протоколов TCP/IP.
(b) Рекомендуемый: Реализация указанной TS не требуется для минимального соответствия, но опыт и/или общепринятая техническая мудрость свидетельствуют о её желательности в области применимости AS. Поставщикам настоятельно рекомендуется включать функции, возможности и протоколы рекомендуемых TS в свои продукты и следует исключать их только в случае, если такое исключение оправдано особыми обстоятельствами. Например, протокол TELNET следует реализовывать всеми системами, которым был бы полезен удалённый доступ.
(c) Факультативный: Реализация указанной TS является необязательной в области применимости AS; то есть AS не создаёт явной необходимости применять TS. Однако конкретный поставщик может решить реализовать её, либо конкретный пользователь может решить, что она необходима в определённой среде. Например, DECNET MIB может считаться ценным в среде, где используется протокол DECNET.
Как отмечено в разделе 4.1, существуют TS, которые не находятся на пути стандартизации или были сняты с пути стандартизации и поэтому не являются обязательными, рекомендуемыми или факультативными. Для этих TS доступны два дополнительных обозначения «уровня требований»:
(d) Ограниченное использование: TS считается подходящей для использования только в ограниченных или уникальных обстоятельствах. Например, использование протокола с обозначением "Experimental" в целом следует ограничивать теми, кто активно участвует в эксперименте.
(e) Не рекомендуется: TS, считающаяся неподходящей для общего использования, получает метку "Not Recommended". Это может быть связано с её ограниченной функциональностью, специализированным характером или историческим статусом.
Хотя TS и AS концептуально различны, на практике документ на пути стандартизации может объединять AS и одну или несколько связанных TS. Например, технические спецификации, разрабатываемые специально и исключительно для некоторой конкретной области применимости, например для хостов почтовых серверов, часто содержат в единой спецификации всю относящуюся к делу информацию AS и TS. В таких случаях намеренное распределение информации между несколькими документами исключительно для сохранения формального различия AS/TS не служило бы никакой полезной цели. Однако TS, которая, вероятно, будет применяться более чем в одной области применимости, следует разрабатывать модульно, чтобы облегчить её включение несколькими AS.
RFC "Official Protocol Standards" (STD1) перечисляет общий уровень требований для каждой TS, используя номенклатуру, определённую в этом разделе. Этот RFC периодически обновляется. Во многих случаях более подробные описания уровней требований конкретных протоколов и отдельных возможностей протоколов будут содержаться в соответствующих AS.
4. ПУТЬ СТАНДАРТИЗАЦИИ ИНТЕРНЕТА
Спецификации, предназначенные стать стандартами Интернета, развиваются через набор уровней зрелости, известных как «путь стандартизации». Эти уровни зрелости — "Proposed Standard", "Draft Standard" и "Standard" — определены и рассмотрены в разделе 4.1. Способ продвижения спецификаций по пути стандартизации описан в разделе 6.
Даже после принятия спецификации в качестве стандарта Интернета дальнейшее развитие часто происходит на основе опыта и осознания новых требований. Номенклатура и процедуры стандартизации Интернета предусматривают замену старых стандартов Интернета новыми и присвоение описательных меток для указания статуса «снятых с использования» стандартов Интернета. Набор уровней зрелости определён в разделе 4.2, чтобы охватить эти и другие спецификации, которые не считаются находящимися на пути стандартизации.
4.1 Уровни зрелости пути стандартизации
Спецификации Интернета проходят этапы разработки, тестирования и принятия. В рамках процесса стандартизации Интернета эти этапы формально именуются «уровнями зрелости».
В этом разделе описаны уровни зрелости и ожидаемые характеристики спецификаций на каждом уровне.
4.1.1 Предлагаемый стандарт (Proposed Standard)
Начальным уровнем зрелости пути стандартизации является "Proposed Standard". Для перевода спецификации на путь стандартизации на уровне "Proposed Standard" требуется конкретное действие IESG.
Спецификация Proposed Standard обычно стабильна, в ней разрешены известные варианты проектных решений, считается, что она хорошо понятна, она прошла значительное рассмотрение сообществом и, по-видимому, пользуется достаточным интересом сообщества, чтобы считаться ценной. Однако дальнейший опыт может привести к изменению или даже отзыву спецификации до её продвижения.
Обычно ни реализация, ни опыт эксплуатации не требуются для обозначения спецификации как Proposed Standard. Однако такой опыт крайне желателен и обычно является весомым аргументом в пользу присвоения обозначения Proposed Standard.
Идентификатор и границы: RFC2026/part-003, SHA-256=8bf80de2a2ab74b49f4fc53a5b6c90770c1f8fd7d5bc00f5437cd3cf7cc3bed3
IESG может потребовать опыта реализации и/или эксплуатации до присвоения спецификации статуса Proposed Standard, если она существенно влияет на основные протоколы Интернета либо задаёт поведение, которое может оказать значительное эксплуатационное воздействие на Интернет.
Спецификация Proposed Standard не должна иметь известных технических упущений в отношении предъявляемых к ней требований. Однако IESG может сделать исключение из этого требования, чтобы допустить продвижение спецификации к состоянию Proposed Standard, когда она считается полезной и необходимой (и своевременной), даже при наличии известных технических упущений.
Разработчикам реализаций следует рассматривать Proposed Standards как незрелые спецификации. Их желательно реализовывать, чтобы получить опыт и подтвердить, проверить и уточнить спецификацию. Однако, поскольку содержание Proposed Standards может быть изменено при обнаружении проблем или выявлении лучших решений, развёртывать реализации таких стандартов в среде, чувствительной к нарушениям работы, не рекомендуется.
4.1.2 Draft Standard
Спецификация, для которой были разработаны как минимум две независимые и совместимые реализации на основе разных кодовых баз и для которой получен достаточный успешный эксплуатационный опыт, может быть повышена до уровня «Draft Standard». Для целей данного раздела «совместимые» означает функционально эквивалентные или взаимозаменяемые компоненты системы либо процесса, в которых они используются. Если для реализации требуется запатентованная или иным образом контролируемая технология, отдельные реализации также должны быть результатом отдельного прохождения процесса лицензирования. Повышение до Draft Standard является значительным продвижением по статусу, свидетельствующим о твёрдой уверенности в том, что спецификация зрелая и будет полезной.
Требование как минимум двух независимых и совместимых реализаций применяется ко всем вариантам и возможностям спецификации. В случаях, когда один или несколько вариантов или возможностей не были продемонстрированы как минимум в двух совместимых реализациях, спецификация может быть повышена до уровня Draft Standard только при удалении этих вариантов или возможностей.
Председатель Working Group отвечает за документирование конкретных реализаций, которые дают спецификации право на статус Draft или Internet Standard, вместе с документацией о проверке взаимодействия этих реализаций. Документация должна включать сведения о поддержке каждого отдельного варианта и возможности. Эту документацию следует направлять Area Director вместе с запросом о действии над протоколом. (см. раздел 6)
Draft Standard должен быть хорошо понятен и известен как достаточно стабильный как по своей семантике, так и в качестве основы для разработки реализации. Draft Standard всё ещё может требовать дополнительного или более широкого практического опыта, поскольку реализации, основанные на спецификациях Draft Standard, могут продемонстрировать непредвиденное поведение при крупномасштабном использовании в производственных средах.
Draft Standard обычно считается окончательной спецификацией, и изменения, вероятно, будут вноситься только для решения обнаруженных конкретных проблем. В большинстве обстоятельств поставщикам разумно развёртывать реализации Draft Standards в среде, чувствительной к нарушениям работы.
4.1.3 Internet Standard
Спецификация, для которой получены значительный опыт реализации и успешный эксплуатационный опыт, может быть повышена до уровня Internet Standard. Internet Standard (который может именоваться просто Standard) характеризуется высокой степенью технической зрелости и общепринятым убеждением, что указанный протокол или служба приносит значительную пользу сообществу Интернета.
Спецификации, достигшей статуса Standard, присваивается номер в серии STD при сохранении её номера RFC.
4.2 Уровни зрелости вне Standards Track
Не каждая спецификация находится на Standards Track. Спецификация может не предназначаться для Internet Standard либо предназначаться для последующей стандартизации, но ещё не быть готовой к включению в Standards Track. Спецификация может быть заменена более поздним Internet Standard либо по иной причине выйти из употребления или утратить поддержку.
Спецификации, не находящиеся на Standards Track, маркируются одним из трёх уровней зрелости «вне Track»: «Experimental», «Informational» или «Historic». Документы с этими метками ни в каком смысле не являются Internet Standards.
4.2.1 Experimental
Обозначение «Experimental» обычно указывает на спецификацию, являющуюся частью некоторой исследовательской или опытно-конструкторской работы. Такая спецификация публикуется для общего сведения технического сообщества Интернета и в качестве архивной записи работы с учётом лишь редакционных соображений и проверки того, что была обеспечена надлежащая координация с процессом стандартизации (см. ниже). Experimental specification может быть результатом организованной исследовательской работы в Интернете (например, Research Group IRTF), IETF Working Group либо индивидуальным вкладом.
4.2.2 Informational
Спецификация «Informational» публикуется для общего сведения сообщества Интернета и не представляет консенсуса или рекомендации сообщества Интернета. Обозначение Informational предназначено для своевременной публикации весьма широкого спектра ответственных информационных документов из многих источников с учётом лишь редакционных соображений и проверки того, что была обеспечена надлежащая координация с процессом стандартизации (см. раздел 4.2.3).
Спецификации, подготовленные за пределами сообщества Интернета и не включённые в Internet Standards Process ни одним из положений раздела 10, могут публиковаться как Informational RFCs с разрешения владельца и с согласия RFC Editor.
4.2.3 Процедуры для Experimental и Informational RFCs
Если они не являются результатом действий IETF Working Group, документы, предназначенные для публикации со статусом Experimental или Informational, следует направлять непосредственно RFC Editor. RFC Editor опубликует любые такие документы как Internet-Drafts, если они ещё не были опубликованы таким образом. Чтобы различать эти Internet-Drafts, они будут помечены или сгруппированы в каталоге I-D так, чтобы их было легко распознать. Перед дальнейшими действиями RFC Editor выждет две недели после этой публикации для получения комментариев. Предполагается, что RFC Editor будет руководствоваться своим суждением относительно редакционной пригодности документа для публикации со статусом Experimental или Informational и может отказаться от публикации документа, который, по экспертному мнению RFC Editor, не связан с деятельностью в Интернете либо не соответствует техническому и/или редакционному стандарту для RFCs.
Чтобы гарантировать, что обозначения Experimental и Informational, относящиеся к не-standards track, не используются неправомерно для обхода Internet Standards Process, IESG и RFC Editor договорились, что RFC Editor будет направлять в IESG любой документ, представленный для публикации как Experimental или Informational, который, по мнению RFC Editor, может быть связан с работой, выполняемой или предполагаемой к выполнению в сообществе IETF. IESG обязан рассмотреть такой направленный документ в разумный срок и рекомендовать либо опубликовать его в первоначально представленном виде, либо направить его в IETF как вклад в Internet Standards Process.
Если (a) IESG рекомендует передать документ в IETF и продвигать его в контексте IETF, но автор отказывается это сделать, или (b) IESG считает, что документ предлагает нечто конфликтующее с установленной работой IETF либо фактически враждебное ей, документ всё равно может быть опубликован как Experimental или Informational RFC. Однако в этих случаях IESG может вставить в RFC надлежащий текст «disclaimer» либо в раздел «Status of this Memo», либо непосредственно после него, чтобы прояснить читателям обстоятельства его публикации.
Документы, предлагаемые IETF Working Groups для Experimental и Informational RFCs, проходят рассмотрение IESG. Рассмотрение инициируется с использованием процесса, описанного в разделе 6.1.1.
4.2.4 Historic
Спецификация, заменённая более новой спецификацией или по любой иной причине считающаяся устаревшей, относится к уровню «Historic». (Пуристы предлагали использовать слово «Historical»; однако к настоящему моменту употребление «Historic» исторически сложилось.)
Примечание: Спецификации Standards Track обычно не должны зависеть от других спецификаций Standards Track, находящихся на более низком уровне зрелости, или от спецификаций вне Standards Track, за исключением цитируемых спецификаций других органов стандартизации. (См. раздел 7.)
5. RFCs BEST CURRENT PRACTICE (BCP)
Подсерия BCP серии RFC предназначена быть способом стандартизации практик и результатов обсуждений сообщества. Документ BCP подлежит тому же базовому набору процедур, что и документы Standards Track, и поэтому является средством, посредством которого сообщество IETF может определять и утверждать лучшее текущее мнение сообщества относительно формулировки принципа или того, что считается наилучшим способом выполнения некоторых операций или функций процесса IETF.
Исторически стандарты Интернета в целом были связаны с техническими спецификациями аппаратного и программного обеспечения, требуемого для компьютерной связи через взаимосвязанные сети. Однако, поскольку сам Интернет состоит из сетей, эксплуатируемых большим разнообразием организаций с различными целями и правилами, качественное обслуживание пользователей требует, чтобы операторы и администраторы Интернета следовали некоторым общим руководящим принципам для политик и операций. Хотя эти руководящие принципы в целом отличаются по охвату и стилю от стандартов протоколов, их установление нуждается в аналогичном процессе формирования консенсуса.
Хотя признаётся, что такие органы, как IAB и IESG, состоят из лиц, которые могут участвовать как частные лица в технической работе IETF, также признаётся, что сами эти органы существуют как лидеры сообщества.
Как лидеры технического сообщества Интернета, эти органы должны иметь возможность предлагать идеи для стимулирования работы в определённой области, привлекать внимание сообщества к определённому вопросу, формулировать архитектурный принцип или сообщать свои соображения по другим вопросам. Подсерия BCP создаёт упорядоченный способ для этих руководящих органов вносить предложения в механизм формирования консенсуса IETF, одновременно оценивая мнение сообщества по данному вопросу.
Наконец, серия BCP может использоваться для документирования работы самого IETF. Например, настоящий документ определяет IETF Standards Process и опубликован как BCP.
5.1 Процесс рассмотрения BCP
В отличие от документов Standards Track, механизмы, описанные в BCPs, плохо подходят для поэтапного внедрения, характерного для трёхэтапного Standards Track, и вместо этого обычно имеют смысл лишь для полного и немедленного введения в действие.
Процесс BCP аналогичен процессу для Proposed Standards. BCP представляется в IESG для рассмотрения (см. раздел 6.1.1), и применяется существующий процесс рассмотрения, включая Last-Call в списке рассылки IETF Announce. Однако после одобрения документа IESG процесс заканчивается и документ публикуется. Получившийся документ рассматривается как имеющий техническое одобрение IETF.
В частности, документ, рассматриваемый для статуса BCP, должен пройти процедуры, изложенные в разделах 6.1 и 6.4 настоящего документа. Процесс BCP может быть обжалован в соответствии с процедурами раздела 6.5.
Поскольку BCPs предназначены для выражения консенсуса сообщества, но достигаются быстрее, чем стандарты, BCPs требуют особой тщательности. В частности, BCPs не следует рассматривать просто как более сильные Informational RFCs; скорее, их следует рассматривать как документы, подходящие для содержания, отличающегося от Informational RFCs.
Спецификации или группе спецификаций, которые были одобрены как BCP, присваивается номер в серии BCP при сохранении её номера или их номеров RFC.
6. ПРОЦЕСС СТАНДАРТИЗАЦИИ ИНТЕРНЕТА
Механика Процесса стандартизации Интернета включает решения IESG о включении спецификации в трек стандартов либо о переводе спецификации, находящейся в треке стандартов, с одного уровня зрелости на другой. Хотя для руководства IESG при принятии решения о включении спецификации в трек стандартов, продвижении по нему или исключении из него имеется ряд достаточно объективных критериев (описанных ниже и в разделе 4), для какой-либо спецификации не существует алгоритмической гарантии включения в трек стандартов или продвижения по нему. Опытное коллективное суждение IESG о техническом качестве спецификации, предлагаемой к включению в трек стандартов или продвижению в нём, является существенной составляющей процесса принятия решений.
6.1 Действия со стандартами
«Действие со стандартами» — включение конкретной спецификации в трек стандартов, её продвижение в нём или исключение из него — должно быть одобрено IESG.
6.1.1 Инициирование действия
Спецификация, которую предполагается включить в трек стандартов Интернета или продвинуть в нём, должна быть сначала опубликована как Internet-Draft (см. раздел 2.2), если она не оставалась неизменной со времени публикации в качестве RFC. Она должна оставаться Internet-Draft в течение периода не менее двух недель, позволяющего провести полезное рассмотрение сообществом; после этого может быть инициирована рекомендация о действии.
Действие со стандартами инициируется рекомендацией рабочей группы IETF, ответственной за спецификацию, своему Area Director, с копией в Секретариат IETF, либо, в случае спецификации, не связанной с Рабочей группой, рекомендацией отдельного лица, направленной в IESG.
6.1.2 Рассмотрение и одобрение IESG
IESG должна определить, удовлетворяет ли представленная ей в соответствии с разделом 6.1.1 спецификация применимым критериям рекомендуемого действия (см. разделы 4.1 и 4.2), а также должна определить, соответствуют ли техническое качество и ясность спецификации ожидаемым для уровня зрелости, для которого рекомендуется эта спецификация.
Чтобы получить всю информацию, необходимую для принятия этих решений, особенно когда IESG считает спецификацию чрезвычайно важной с точки зрения её потенциального воздействия на Интернет или на набор протоколов Интернета, IESG по своему усмотрению может поручить независимое техническое рассмотрение спецификации.
IESG направит IETF уведомление о предстоящем рассмотрении документа(ов) IESG, чтобы обеспечить окончательное рассмотрение широким интернет-сообществом. Это уведомление «Last-Call» должно быть направлено электронной почтой в список рассылки IETF Announce. Комментарии к Last-Call должны приниматься от любого лица, и их следует направлять согласно указаниям в объявлении Last-Call.
Период Last-Call не должен быть короче двух недель, за исключением случаев, когда предлагаемое действие со стандартами не было инициировано Рабочей группой IETF; в таком случае период Last-Call не должен быть короче четырёх недель. Если IESG считает, что интересам сообщества будет отвечать предоставление большего времени для комментариев, она может установить более длительный период Last-Call либо явно продлить текущий период Last-Call.
IESG не связана действием, рекомендованным при представлении спецификации. Например, IESG может решить рассмотреть спецификацию для публикации в иной категории, чем запрошенная. Если IESG определит это до выпуска Last-Call, то Last-Call следует отражать позицию IESG. IESG также может решить изменить категорию публикации на основании откликов на Last-Call. Если это решение приведёт к публикации спецификации на «более высоком» уровне, чем тот, для которого был проведён первоначальный Last-Call, следует выпустить новый Last-Call с указанием рекомендации IESG. Кроме того, IESG может решить рекомендовать создание новой Рабочей группы в случае существенных разногласий в ответ на Last-Call по спецификации, не исходящей от Рабочей группы IETF.
В разумный срок после истечения периода Last-Call IESG должна принять окончательное решение о том, одобрять ли действие со стандартами, и уведомить IETF о своём решении электронной почтой через список рассылки IETF Announce.
6.1.3 Публикация
Если действие со стандартами одобрено, RFC Editor направляется уведомление, копия которого направляется IETF, с инструкциями опубликовать спецификацию в качестве RFC. На этом этапе спецификация должна быть удалена из каталога Internet-Drafts.
В каждом выпуске бюллетеня Internet Society должна публиковаться официальная сводка завершённых и ожидающих действий со стандартами. Она является «официальной публикацией, фиксирующей действия со стандартами Интернета».
RFC Editor должен периодически публиковать RFC «Internet Official Protocol Standards» [1], обобщающий статус всех спецификаций протоколов и служб Интернета.
6.2 Продвижение в треке стандартов
Процедура, описанная в разделе 6.1, соблюдается для каждого действия, сопровождающего продвижение спецификации по треку стандартов.
Спецификация должна оставаться на уровне Proposed Standard не менее шести (6) месяцев.
Спецификация должна оставаться на уровне Draft Standard не менее четырёх (4) месяцев либо до проведения по меньшей мере одной встречи IETF — в зависимости от того, что наступит позже.
Эти минимальные периоды предназначены для обеспечения достаточной возможности рассмотрения сообществом без серьёзного ущерба своевременности. Эти интервалы должны отсчитываться от даты публикации соответствующего RFC (или соответствующих RFC) либо, если действие не приводит к публикации RFC, от даты объявления об одобрении действия IESG.
Спецификация может (и, действительно, вероятно будет) пересматриваться по мере её продвижения по треку стандартов. На каждом этапе IESG должна определить объём и значимость пересмотра спецификации и, если это необходимо и уместно, изменить рекомендуемое действие. Ожидаются незначительные пересмотры, однако значительный пересмотр может потребовать, чтобы спецификация накопила больше опыта на текущем уровне зрелости до дальнейшего продвижения. Наконец, если спецификация была изменена весьма существенно, IESG может рекомендовать рассматривать пересмотр как новый документ, вновь входящий в трек стандартов с самого начала.
Изменение статуса должно приводить к повторной публикации спецификации в качестве RFC, кроме редкого случая, когда в спецификации вообще не было изменений с момента последней публикации. Как правило, желательные изменения будут «пакетироваться» для включения на следующем уровне трека стандартов. Однако откладывание изменений до следующего действия со стандартами для спецификации не всегда будет возможным или желательным; например, важную типографскую ошибку или техническую ошибку, не означающую изменения общей функции спецификации, может потребоваться исправить немедленно. В таких случаях IESG или RFC Editor может быть предложено повторно опубликовать RFC (с новым номером) с исправлениями, и это не перезапускает отсчёт минимального времени на уровне.
Когда спецификация в треке стандартов не достигла уровня Internet Standard, но остаётся на одном и том же уровне зрелости в течение двадцати четырёх (24) месяцев, а затем каждые двенадцать (12) месяцев до изменения статуса, IESG должна рассмотреть жизнеспособность усилий по стандартизации, ответственных за эту спецификацию, и полезность технологии. По итогам каждого такого рассмотрения IESG должна одобрить прекращение или продолжение усилий по разработке; одновременно IESG должна решить, сохранить ли спецификацию на том же уровне зрелости или перевести её в статус Historic. Это решение должно быть доведено до IETF электронной почтой через список рассылки IETF Announce, чтобы предоставить интернет-сообществу возможность прокомментировать его. Это положение предназначено не для создания угрозы законным и активным усилиям Рабочей группы, а для предоставления административного механизма прекращения угасших усилий.
6.3 Пересмотр стандарта
Новая версия установленного Internet Standard должна пройти полный процесс стандартизации Интернета так, как если бы она была совершенно новой спецификацией. Когда новая версия достигнет уровня Standard, она обычно заменит предыдущую версию, которая будет переведена в статус Historic. Однако в некоторых случаях обе версии могут остаться Internet Standards, чтобы учесть требования уже развёрнутой базы. В этой ситуации взаимосвязь между предыдущей и новой версиями должна быть явно указана в тексте новой версии или в другом подходящем документе (например, Applicability Statement; см. раздел 3.2).
6.4 Вывод стандарта из обращения
По мере изменения и развития технологии новая спецификация Standard может оказаться настолько явно технически превосходящей, что одну или несколько существующих спецификаций трека стандартов для той же функции следует вывести из обращения. В этом случае или когда по какой-либо иной причине считается, что существующую спецификацию трека стандартов следует вывести из обращения, IESG должна одобрить изменение статуса старой спецификации или старых спецификаций на Historic. Эта рекомендация должна быть выпущена с применением тех же процедур Last-Call и уведомления, что и для любого другого действия со стандартами. Запрос на вывод существующего стандарта из обращения может исходить от Рабочей группы, Area Director или другой заинтересованной стороны.
6.5 Разрешение конфликтов и апелляции
Споры возможны на различных этапах процесса IETF. Насколько возможно, процесс устроен так, чтобы можно было достичь компромиссов и подлинного консенсуса, однако бывают случаи, когда даже наиболее разумные и осведомлённые люди не способны прийти к согласию. Для достижения целей открытости и справедливости такие конфликты должны разрешаться посредством открытого рассмотрения и обсуждения. В этом разделе устанавливаются процедуры, которым необходимо следовать при рассмотрении вопросов стандартов Интернета, не поддающихся разрешению посредством обычных процессов, с помощью которых Рабочие группы IETF и другие участники Процесса стандартов Интернета обычно достигают консенсуса.
6.5.1 Споры в Рабочей группе
Отдельное лицо (независимо от того, является ли оно участником соответствующей Рабочей группы) может не согласиться с рекомендацией Рабочей группы, полагая, что либо (a) его или её собственные взгляды не были адекватно учтены Рабочей группой, либо (b) Рабочая группа сделала неверный технический выбор, который ставит качество и/или целостность результата или результатов Рабочей группы под существенную угрозу. Первый вопрос представляет собой проблему с процессом Рабочей группы; второй является утверждением о технической ошибке. Эти два вида несогласия весьма различаются, но оба рассматриваются одним и тем же процессом рассмотрения.
Лицо, не согласное с рекомендацией Рабочей группы, должно всегда сначала обсудить этот вопрос с председателем или председателями Рабочей группы, которые могут привлечь к обсуждению других членов Рабочей группы (либо Рабочую группу в целом).
Если таким способом устранить несогласие не удаётся, любая из вовлечённых сторон может довести его до сведения Area Director или Area Directors области, в которой учреждена Рабочая группа. Area Director или Area Directors должны попытаться разрешить спор.
Если несогласие не может быть разрешено Area Director или Area Directors, любая из вовлечённых сторон затем может обжаловать его в IESG в полном составе. Затем IESG должна рассмотреть ситуацию и попытаться разрешить её способом по своему выбору.
Если несогласие не разрешено к удовлетворению сторон на уровне IESG, любая из вовлечённых сторон может обжаловать решение в IAB. Затем IAB должна рассмотреть ситуацию и попытаться разрешить её способом по своему выбору.
Решение IAB является окончательным в отношении вопроса о том, были ли соблюдены процедуры стандартов Интернета, а также в отношении всех вопросов технической обоснованности.
6.5.2 Сбои процесса
Этот документ устанавливает процедуры, обязательные к соблюдению для обеспечения открытости и справедливости Процесса стандартов Интернета, а также технической жизнеспособности создаваемых стандартов. IESG является главным представителем IETF для этой цели, и именно IESG поручено обеспечивать соблюдение обязательных процедур и выполнение всех необходимых предварительных условий для действия со стандартами.
Если какое-либо лицо не согласно с действием, предпринятым IESG в рамках этого процесса, этому лицу следует сначала обсудить вопрос с председателем ISEG. Если председатель IESG не способен удовлетворить заявителя жалобы, то IESG в полном составе следует повторно рассмотреть предпринятое действие с учётом доводов заявителя жалобы и определить, требуются ли какие-либо дальнейшие действия. IESG должна издать отчёт о рассмотрении жалобы для IETF.
Если заявитель жалобы не удовлетворён результатом рассмотрения IESG, апелляция может быть подана в IAB. Затем IAB должна рассмотреть ситуацию выбранным ею способом, попытаться её урегулировать и сообщить IETF о результате своего рассмотрения.
Если обстоятельства того требуют, IAB может предписать аннулировать решение IESG, и тогда ситуация должна быть такой, какой она была до принятия решения IESG. IAB также может рекомендовать действие IESG или дать иные рекомендации, которые сочтёт уместными. Однако IAB не может подменять роль IESG, вынося решение, которое уполномочена принимать только IESG.
Решение IAB является окончательным в отношении вопроса о том, были ли соблюдены процедуры стандартов Интернета.
6.5.3 Вопросы применимой процедуры
Дальнейшее обращение возможно только в случаях, когда утверждается, что сами процедуры (то есть процедуры, описанные в этом документе) являются неадекватными или недостаточными для защиты прав всех сторон в справедливом и открытом Процессе стандартизации Интернета. Заявления на этом основании могут быть направлены Совету попечителей Internet Society. Президент Internet Society должен подтвердить получение такой апелляции в течение двух недель и при подтверждении сообщить заявителю ожидаемую продолжительность рассмотрения апелляции попечителями. Попечители должны рассмотреть ситуацию выбранным ими способом и сообщить IETF о результате своего рассмотрения.
Решение попечителей по завершении их рассмотрения является окончательным в отношении всех аспектов спора.
6.5.4 Процедура апелляций
Все апелляции должны включать подробное и конкретное описание фактов спора.
Все апелляции должны быть инициированы в течение двух месяцев с момента, когда оспариваемое действие или решение стало известно публично.
На всех этапах процесса апелляций лица или органы, ответственные за принятие решений, вправе определять конкретные процедуры, которым они будут следовать при принятии своего решения.
Во всех случаях решение о разрешении спора и доведение этого решения до участвующих сторон должны быть осуществлены в разумный срок.
[ПРИМЕЧАНИЕ: Эти процедуры намеренно и явно не устанавливают фиксированный максимальный срок, который должен считаться «разумным» во всех случаях. Процесс стандартизации Интернета придаёт первостепенное значение консенсусу и усилиям по его достижению и намеренно отказывается от детерминированно быстрого исполнения процедур в пользу свободы усмотрения, в пределах которой могут быть достигнуты более подлинные технические соглашения.]
7. ВНЕШНИЕ СТАНДАРТЫ И СПЕЦИФИКАЦИИ
Многие группы по стандартизации, помимо IETF, создают и публикуют документы стандартов для сетевых протоколов и служб. Когда эти внешние спецификации играют важную роль в Интернете, желательно достичь общих соглашений об их использовании — то есть установить Стандарты Интернета, относящиеся к этим внешним спецификациям.
Существуют две категории внешних спецификаций:
(1) Открытые стандарты
Различные национальные и международные органы по стандартизации, такие как ANSI, ISO, IEEE и ITU-T, разрабатывают разнообразные спецификации протоколов и служб, подобные определённым здесь Техническим спецификациям. Национальные и международные группы также публикуют «соглашения разработчиков реализаций», аналогичные Заявлениям о применимости, в которых фиксируется совокупность деталей, специфичных для реализации и касающихся практического применения их стандартов. В целях Процесса стандартизации Интернета все они считаются «открытыми внешними стандартами».
(2) Иные спецификации
Иные проприетарные спецификации, получившие широкое использование в Интернете, могут рассматриваться интернет-сообществом так, как если бы они являлись «стандартами». Такая спецификация, как правило, не разрабатывается открытым образом, обычно является проприетарной и контролируется поставщиком, поставщиками или организацией, которые её создали.
7.1 Использование внешних спецификаций
Во избежание конфликта между конкурирующими версиями спецификации интернет-сообщество не будет стандартизировать спецификацию, которая является лишь «интернет-версией» существующей внешней спецификации, если только не достигнута явная договорённость о сотрудничестве для этого. Однако существует несколько способов, которыми внешняя спецификация, важная для функционирования и/или развития Интернета, может быть принята для использования в Интернете.
7.1.1 Включение открытого стандарта
Стандарт Интернета TS или AS может включать открытый внешний стандарт посредством ссылки. Например, многие Стандарты Интернета включают посредством ссылки стандарт ANSI на набор символов «ASCII» [2]. Всякий раз, когда это возможно, спецификация, на которую делается ссылка, должна быть доступна в сети.
7.1.2 Включение иных спецификаций
Иные проприетарные спецификации могут включаться посредством ссылки на версию спецификации, если правообладатель выполняет требования раздела 10. Если иная проприетарная спецификация не является широко и легко доступной, IESG может запросить её публикацию в качестве Информационного RFC.
Как правило, IESG не следует отдавать предпочтение конкретной проприетарной спецификации перед технически эквивалентной конкурирующей спецификацией (конкурирующими спецификациями), делая какую-либо включённую спецификацию поставщика «обязательной» или «рекомендуемой».
7.1.3 Принятие за основу
Рабочая группа IETF может взять за основу внешнюю спецификацию и разработать на её основе спецификацию Интернета. Это допустимо, если (1) спецификация предоставлена Рабочей группе в соответствии с требованиями раздела 10 и (2) первоначальный разработчик спецификации передал IETF контроль изменений для этой спецификации либо для спецификаций, созданных на основе первоначальной спецификации.
8. УВЕДОМЛЕНИЯ И ВЕДЕНИЕ УЧЁТА
Каждая из организаций, участвующих в разработке и утверждении Стандартов Интернета, должна публично объявлять о каждой деятельности, которой она занимается, и вести общедоступную запись о ней в той мере, в какой эта деятельность представляет собой осуществление какой-либо части Процесса стандартизации Интернета. Для целей этого раздела к организациям, участвующим в разработке и утверждении Стандартов Интернета, относятся IETF, IESG, IAB, все Рабочие группы IETF и Совет попечителей Internet Society.
Объявления о заседаниях IETF и Рабочих групп должны направляться по электронной почте в список рассылки IETF Announce и должны делаться достаточно заблаговременно до деятельности, чтобы все заинтересованные стороны могли эффективно участвовать. Объявление должно содержать (или предоставлять указатели на) всю информацию, необходимую для обеспечения участия любого заинтересованного лица. Например, в случае заседания объявление должно включать повестку, в которой указаны относящиеся к стандартам вопросы, подлежащие обсуждению.
Официальная запись относящейся к стандартам деятельности организации должна включать как минимум следующее:
o устав организации (либо определяющий документ, эквивалентный уставу);
o полные и точные протоколы заседаний;
o архивы списков рассылки электронной почты Рабочей группы; и
o все письменные материалы участников, относящиеся к деятельности организации в области стандартов.
С практической точки зрения официальная запись всех действий Процесса стандартизации Интернета ведётся Секретариатом IETF и находится в его ведении, за исключением того, что ожидается, что каждая Рабочая группа IETF будет вести собственный архив списка рассылки электронной почты и должна прилагать все разумные усилия, чтобы обеспечить фиксацию и включение в архивы всего трафика. Кроме того, председатель Рабочей группы отвечает за предоставление Секретариату IETF полных и точных протоколов всех заседаний Рабочей группы. Internet-Drafts, удалённые (по любой причине) из каталогов Internet-Drafts, должны архивироваться Секретариатом IETF исключительно для сохранения исторической записи деятельности, связанной со стандартами Интернета, и поэтому не могут быть извлечены, кроме как при особых обстоятельствах.
9. ИЗМЕНЕНИЕ ПРОЦЕССА
Этот документ, устанавливающий правила и процедуры, по которым создаются Стандарты Интернета и связанные документы, сам является продуктом Процесса стандартизации Интернета (как BCP, как описано в разделе 5). Он заменяет предыдущую версию и, вероятно, со временем сам будет заменён.
Хотя на момент публикации этот документ представляет мнение сообщества о надлежащем и правильном процессе, которому следует следовать, и требованиях, которые следует выполнить, чтобы получить наилучшие возможные Стандарты Интернета и BCP, нельзя предполагать, что так будет оставаться всегда. Время от времени может возникать желание обновить его, заменив новой версией. Обновление этого документа осуществляется с применением тех же открытых процедур, которые используются для любого другого BCP.
Кроме того, могут возникать ситуации, когда следование процедурам ведёт к тупику относительно конкретной спецификации, либо ситуации, когда процедуры не дают указаний. В этих случаях может быть уместно применить описанную ниже процедуру отклонения.
9.1 Процедура отклонения
По рекомендации ответственной Рабочей группы IETF (либо, если Рабочая группа не сформирована, по рекомендации специального комитета) IESG может включить конкретную спецификацию в путь стандартизации или продвинуть её по нему, даже если некоторые требования этого документа не выполнены или не будут выполнены. Однако IESG может одобрить такое отклонение только если сначала определит, что вероятные выгоды для интернет-сообщества, вероятно, перевесят любые издержки для интернет-сообщества, возникающие в результате несоблюдения требований этого документа. Осуществляя это усмотрение, IESG должна как минимум рассмотреть: (a) технические достоинства спецификации; (b) возможность достижения целей Процесса стандартизации Интернета без предоставления отклонения; (c) альтернативы предоставлению отклонения; (d) побочные и прецедентные последствия предоставления отклонения; и (e) способность IESG сформулировать отклонение настолько узко, насколько возможно. При определении, одобрять ли отклонение, IESG вправе ограничить его область действия конкретными частями этого документа и установить такие дополнительные ограничения или условия, которые она сочтёт уместными для защиты интересов интернет-сообщества.
Предлагаемое отклонение должно подробно описывать усматриваемую проблему, пояснять точное положение этого документа, которое вызывает необходимость в отклонении, а также результаты рассмотрения IESG, включая рассмотрение пунктов (a)–(d) предыдущего абзаца. Предлагаемое отклонение должно быть выпущено как Internet Draft. Затем IESG должна объявить продлённый Last-Call продолжительностью не менее 4 недель, чтобы позволить сообществу прокомментировать предложение.
Своевременно после истечения периода Last-Call IESG должна принять окончательное решение о том, одобрить или не одобрить предлагаемое отклонение, и уведомить IETF о своём решении по электронной почте через список рассылки IETF Announce. Если отклонение одобрено, оно должно быть передано RFC Editor с запросом опубликовать его в качестве BCP.
Эта процедура отклонения предназначена для применения, когда считается необходимым однократное «waving» какого-либо положения этого документа. Постоянные изменения этого документа должны осуществляться через обычный процесс BCP.
К этому процессу применяется процесс апелляций, установленный в разделе 6.5.
9.2 Исключения
Никакое применение этой процедуры не может сокращать какие-либо установленные сроки, освобождать какое-либо предложение от требований открытости, справедливости или консенсуса либо от необходимости вести надлежащие записи заседаний и обсуждений в списках рассылки.
В частности, предметом отклонения не должны быть следующие разделы этого документа: 5.1, 6.1, 6.1.1 (первый абзац), 6.1.2, 6.3 (первое предложение), 6.5 и 9.
10. ПРАВА ИНТЕЛЛЕКТУАЛЬНОЙ СОБСТВЕННОСТИ
10.1. Общая политика
Идентификатор и границы: RFC2026/part-006, SHA-256=7f23e6bdba6de99da0614d149ef3ad7c4c69c61b0f029fb42b40ffa283377ca2. Фрагмент: заключительный абзац раздела 10.1; разделы 10.2–13; библиографические записи [1]–[5].
Во всех вопросах прав интеллектуальной собственности и процедур намерение состоит в том, чтобы приносить пользу интернет-сообществу и широкой общественности, уважая при этом законные права других лиц.
10.2 Обязательства по конфиденциальности
Ни один вклад, на который распространяется какое-либо требование конфиденциальности или какое-либо ограничение его распространения, не может рассматриваться ни в одной части Процесса стандартизации Интернета, и не должно предполагаться наличие какого-либо обязательства по конфиденциальности в отношении такого вклада.
10.3. Права и разрешения
В ходе работы над стандартами IETF получает вклады в различных формах и от многих лиц. Для наилучшего содействия распространению этих вкладов необходимо понимать любые права интеллектуальной собственности (IPR), относящиеся к вкладам.
10.3.1. Все вклады
Подавая вклад, каждое лицо, фактически подающее этот вклад, считается согласившимся со следующими условиями от своего имени, от имени представляемой им организации (если таковая имеется) и от имени владельцев любых прав собственности на вклад. Если в поданном материале помимо участника (участников), фактически осуществляющего подачу, указаны и другие участники, фактический податель (фактические податели) заявляет, что каждый другой поименованный участник был уведомлён об этих же условиях и согласился принять их от своего имени, от имени любой организации, которую он может представлять, и от имени любого известного владельца любых прав собственности на вклад.
l. Некоторые произведения (например, произведения Правительства США) не охраняются авторским правом. Однако в той мере, в какой поданный материал охраняется или может охраняться авторским правом, участник, представляемая им организация (если таковая имеется) и владельцы любых прав собственности на вклад предоставляют ISOC и IETF неограниченное, бессрочное, неисключительное, безвозмездное, действующее во всём мире право и лицензию в отношении любых авторских прав на вклад. Эта лицензия включает право копировать, публиковать и распространять вклад любым способом, а также создавать производные произведения, основанные на всём вкладе или его части либо включающие их; лицензия на такие производные произведения имеет тот же объём, что и лицензия на исходный вклад.
2. Участник признаёт, что ISOC и IETF не обязаны публиковать, иным образом использовать или распространять какой-либо вклад.
3. Участник разрешает ссылаться на имя (имена) и адрес (адреса) участника (участников), а также наименования организаций, которые он представляет (если таковые имеются).
4. Участник заявляет, что во вкладе надлежащим образом указаны основные участники.
5. Участник, представляемая им организация (если таковая имеется) и владельцы любых прав собственности на вклад соглашаются, что никакая информация во вкладе не является конфиденциальной и что ISOC и его аффилированные организации могут свободно раскрывать любую информацию, содержащуюся во вкладе.
6. Участник заявляет, что раскрыл существование любых прав собственности или прав интеллектуальной собственности на вклад, которые разумно и лично известны участнику. Участник не заявляет, что ему лично известны все потенциально относящиеся к делу права собственности и права интеллектуальной собственности, принадлежащие или заявленные представляемой им организацией (если таковая имеется) либо третьими лицами.
7. Участник заявляет, что ему не известны разумно и лично какие-либо ограничения его способности предоставить изложенные выше права, подтверждения и соглашения.
Ратифицируя это описание процесса IETF, Internet Society гарантирует, что не будет препятствовать традиционному открытому и свободному доступу к документам IETF, права и лицензии на которые были предоставлены согласно процедурам, изложенным в данном разделе, включая Internet-Drafts и RFC. Эта гарантия является бессрочной и не будет отозвана Internet Society или его правопреемниками либо цессионариями.
10.3.2. Документы на пути стандартизации
(A) Если в отношении какой-либо спецификации на пути стандартизации известны или заявлены какие-либо патенты, патентные заявки либо иные права собственности и о них доведено до сведения IESG, IESG не должен (shall) продвигать спецификацию без включения в документ примечания, указывающего на существование таких прав или заявленных прав. Если перед продвижением спецификации требуются реализации, для подтверждения достаточности спецификации должны рассматриваться (shall) только те реализации, разработчики которых заявили о принятии надлежащих мер для соблюдения любых таких прав или заявленных прав.
(B) IESG отказывается от какой-либо ответственности за выявление существования или оценку применимости каких-либо заявленных авторских прав, патентов, патентных заявок либо иных прав при исполнении своих обязательств по (A) и не будет занимать позицию относительно действительности или объёма любых таких прав.
(C) Если IESG известно о правах или заявленных правах согласно (A), Исполнительный директор IETF должен попытаться (shall) получить от заявителя таких прав письменное заверение, что после одобрения IESG соответствующей спецификации (спецификаций) на пути стандартизации Интернета любая сторона сможет получить право реализовывать, использовать и распространять технологию или произведения при реализации, использовании или распространении технологии, основанной на конкретной спецификации (спецификациях), на открыто определённых, разумных и недискриминационных условиях. Рабочая группа, предлагающая использование технологии, в отношении которой заявлены права собственности, может содействовать Исполнительному директору IETF в этих усилиях. Результаты этой процедуры не должны (shall) влиять на продвижение спецификации по пути стандартизации, за исключением того, что IESG может отложить одобрение, если задержка может способствовать получению таких заверений. Однако результаты, тем не менее, будут зафиксированы Исполнительным директором IETF и сделаны доступными. IESG также может указать включить краткое изложение результатов в любой опубликованный RFC, содержащий спецификацию.
10.3.3 Определение разумности и недискриминационности условий
IESG не будет явно определять, что заверение о разумных и недискриминационных условиях использования технологии исполнено на практике. Вместо этого он будет использовать обычные требования для продвижения Интернет-стандартов, чтобы убедиться в разумности условий использования. Если две независимые реализации спецификации, требуемые для перехода от Proposed Standard к Draft Standard, были созданы разными организациями или лицами либо если достигнуты требуемые для перехода от Draft Standard к Standard «значительная реализация и успешный опыт эксплуатации», предполагается, что условия должны быть разумными и в некоторой степени недискриминационными. Это предположение может быть оспорено в период Last-Call.
10.4. Уведомления
(A) Документы на пути стандартизации должны (shall) содержать следующее уведомление:
"The IETF takes no position regarding the validity or scope of
any intellectual property or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; neither does
it represent that it has made any effort to identify any such
rights. Information on the IETF's procedures with respect to
rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made
available for publication and any assurances of licenses to
be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat."
(B) IETF призывает все заинтересованные стороны как можно раньше доводить до его сведения существование любых прав интеллектуальной собственности, относящихся к Интернет-стандартам. Для этой цели каждый документ по стандарту должен (shall) содержать следующее приглашение:
"The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights which may cover technology that may be
required to practice this standard. Please address the
information to the IETF Executive Director."
(C) Следующее уведомление об авторском праве и отказ от гарантий должны (shall) включаться во всю документацию ISOC, относящуюся к стандартам:
"Copyright (C) The Internet Society (date). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implmentation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE."
(D) Если IESG на момент публикации осведомлена о заявленных правах собственности в отношении документа на пути стандартизации либо описанной или упомянутой в нём технологии, такой документ должен (shall) содержать следующее уведомление:
"The IETF has been notified of intellectual property rights
claimed in regard to some or all of the specification contained
in this document. For more information consult the online list
of claimed rights."
11. БЛАГОДАРНОСТИ
За прошедшие годы в разработке документов, определяющих Процесс стандартизации IETF, участвовал ряд людей. Процесс был впервые описан в RFC 1310, затем пересмотрен в RFC 1602 до нынешней работы, которая в значительной степени опирается на предшествующие версии. Особую благодарность следует выразить Lyman Chapin, Phill Gross и Christian Huitema как редакторам предыдущих версий; Jon Postel и Dave Crocker — за их вклад в эти версии; Andy Ireland, Geoff Stewart, Jim Lampert и Dick Holleman — за проверку юридических аспектов описанных здесь процедур; John Stewart, Robert Elz и Steve Coya — за их значительный вклад в окончательную версию.
Кроме того, значительная заслуга в уточнении деталей процессов IETF принадлежит многим участникам различных составов Рабочей группы POISED.
12. ВОПРОСЫ БЕЗОПАСНОСТИ
В этом меморандуме вопросы безопасности не обсуждаются.
13. ССЫЛКИ
[1] Postel, J., "Internet Official Protocol Standards", STD 1,
USC/Information Sciences Institute, March 1996.
[2] ANSI, Coded Character Set -- 7-Bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
USC/Information Sciences Institute, October 1994.
[4] Postel, J., "Introduction to the STD Notes", RFC 1311,
USC/Information Sciences Institute, March 1992.
[5] Postel, J., "Instructions to RFC Authors", RFC 1543,
USC/Information Sciences Institute, October 1993.
[6] Huitema, C., J. Postel и S. Crocker "Not All RFCs are
Standards", RFC 1796, апрель 1995 г.
14. ОПРЕДЕЛЕНИЯ ТЕРМИНОВ
IETF Area — подразделение управления в составе IETF. Область состоит
из рабочих групп, связанных с общей темой, например маршрутизацией.
Областью управляют один или два директора области.
Area Director — руководитель области IETF. Директора областей вместе
с председателем IETF образуют Internet Engineering Steering Group
(IESG).
File Transfer Protocol (FTP) — интернет-приложение, используемое для
передачи файлов в сети TCP/IP.
gopher — интернет-приложение, используемое для интерактивного выбора
и получения файлов в сети TCP/IP.
Internet Architecture Board (IAB) — назначенная группа, содействующая
управлению процессом стандартизации IETF.
Internet Engineering Steering Group (IESG) — группа, состоящая из
директоров областей IETF и председателя IETF. IESG совместно с IAB
отвечает за управление IETF и является органом утверждения стандартов
IETF.
interoperable — для целей настоящего документа «interoperable» означает
способность к взаимодействию по пути передачи данных.
Last-Call — период публичных комментариев, используемый для оценки
степени консенсуса относительно обоснованности предлагаемого действия
по стандартизации.
(см. раздел 6.1.2)
online — относящийся к информации, предоставляемой через Интернет.
В настоящем документе материал называется доступным online, когда его
можно получить без ограничений или чрезмерной платы с помощью
стандартных интернет-приложений, таких как анонимный FTP, gopher или
WWW.
Working Group — группа, уполномоченная IESG и IAB работать над
определённой спецификацией, набором спецификаций или темой.
15. АДРЕС АВТОРА
Scott O. Bradner
Harvard University
Holyoke Center, Room 813
1350 Mass. Ave.
Cambridge, MA 02138
USA
Телефон: +1 617 495 3864
EMail: sob@harvard.edu
ПРИЛОЖЕНИЕ A: ГЛОССАРИЙ СОКРАЩЕНИЙ
ANSI: American National Standards Institute
ARPA: (U.S.) Advanced Research Projects Agency
AS: Applicability Statement
FTP: File Transfer Protocol
ASCII: American Standard Code for Information Interchange
ITU-T: Telecommunications Standardization sector of the
International Telecommunication Union (ITU), a UN
treaty organization; ITU-T was formerly called CCITT.
IAB: Internet Architecture Board
IANA: Internet Assigned Numbers Authority
IEEE: Institute of Electrical and Electronics Engineers
ICMP: Internet Control Message Protocol
IESG: Internet Engineering Steering Group
IETF: Internet Engineering Task Force
IP: Internet Protocol
IRSG Internet Research Steering Group
IRTF: Internet Research Task Force
ISO: International Organization for Standardization
ISOC: Internet Society
MIB: Management Information Base
OSI: Open Systems Interconnection
RFC: Request for Comments
TCP: Transmission Control Protocol
TS: Technical Specification
WWW: World Wide Web