RFC 2026 The Internet Standards Process — Revision 3

Опубликовано 27.10.1996 автором Nikolai Malykh 
Network Working Group                                     S. Bradner
Request for Comments: 2026                        Harvard University
BCP: 9                                                  October 1996
Obsoletes: 1602
Category: Best Current Practice

Процесс стандартизации для Internet – Ревизия 3

The Internet Standards Process — Revision 3

PDF

Статус документа

Этот документ относится к категории обмена опытом (Best Current Practice) в сообществе Internet и служит приглашением к дискуссии и внесению предложений в целях дальнейшего развития. Документ может распространяться свободно.

Аннотация

В этом документе описаны процессы, используемые в сообществе Internet для стандартизации протоколов и процедур. Документ определяет этапы процесса стандартизации, требования для перевода документа с одного этапа на другой, а также типы документов, используемые в этом процессе. Рассмотрены также вопросы прав на интеллектуальную собственность и авторских прав, связанные с процессом стандартизации.

1. Введение

В этом документе описаны процессы, используемые в настоящее время сообществом Internet для стандартизации протоколов и процедур. Процесс стандартизации (Internet Standards) представляет собой действия Internet Society, организованные и управляемые от лица сообщества Internet комитетом по архитектуре Internet (IAB1) и группой IESG2.

1.1 Стандарты Internet

Internet представляет собой слабо организованное множество расположенных в разных странах автономных систем и соединенных между собой сетей, поддерживающих взаимодействие между хостами (host-to-host communication) с помощью открытых протоколов и процедур, определяемых стандартами Internet. Существует также множество соединенных между собой сетей, изолированных от глобальной сети Internet, но использующих стандарты Internet.

Процесс стандартизации Internet (Internet Standards Process), описанный в этом документе, относится ко всем протоколам, процедурам и соглашениям, используемым в сети Internet, независимо от того, связаны ли они со стеком протоколов TCP/IP. Для протоколов, разрабатываемых и/или стандартизуемых не относящимися к Internet организациями, процесс стандартизации Internet обычно применяется к использованию протоколов и процедур в контексте Internet, а не к самим спецификациям протоколов.

В общем случае стандарт Internet представляет собой спецификацию, которая стабильна и понятна, технически компетентна и имеет множество независимых, совместимых реализаций с достаточным опытом применения, а также получила достаточно широкую публичную поддержку и признана полезной для всей сети или отдельных частей Internet.

1.2 Процесс стандартизации в Internet

В общих чертах процесс создания стандарта Internet прост – спецификация проходит период разработки и несколько стадий рецензирования в сообществе Internet, пересматривается на основе набранного опыта, адаптируется в качестве стандарта через подходящий комитет (см. ниже) и публикуется. На практике процесс несколько усложняется, поскольку (1) для разработки спецификации требуются квалифицированные специалисты, (2) нужно принимать во внимание интересы множества сторон, (3) требуется получить широкую поддержку сообщества и (4) достаточно сложно оценить полезность конкретной спецификации для сообщества Internet.

Целями процесса стандартизации (Internet Standards Process) являются:

  • техническое совершенство;

  • предварительная реализация и тестирование;

  • четкость, краткость и понятность документации;

  • открытость и беспристрастность;

  • своевременность.

Описанные в этом документе процедуры разработаны для обеспечения беспристрастности, открытости и объективности, учета накопленного опыта, а также гибкости.

  • Процедуры предназначены для обеспечения беспристрастной, открытой и объективной основы при разработке, оценке и адаптации стандартов Internet. Они предоставляют широкие возможности для участия и комментирования всем заинтересованным сторонам. На каждом этапе процесса стандартизации спецификация многократно обсуждается, ее достоинства и недостатки рассматриваются на открытых заседаниях и/или в публичных списках рассылок, а также обеспечивается доступность документов для просмотра и рецензирования.

  • Процедуры явно направлены на признание и принятие в качестве общепринятой практики. Таким образом, спецификация-кандидат должна быть реализована и протестирована на предмет корректной работы и интероперабельности множеством независимых сторон, а также должна быть использована в более сложных средах до того, как она может быть адаптирована в качестве стандарта Internet.

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

Техническое совершенство, рассмотрение до реализации и тестирования, а также обеспечение заинтересованным сторона возможности высказать свое мнение требуют значительного времени и сил. С другой стороны современные темпы развития и внедрения сетевых технологий требуют достаточно быстрой разработки стандартов. Процесс стандартизации (Internet Standards Process) предназначен для балансирования этих противоречивых требований. Процесс предполагается сделать простым и коротким, насколько это возможно без ущерба техническому совершенству, за счет тестирования до адаптации стандарта, а также благодаря открытости и беспристрастности.

Сеть Internet с момента своего создания постоянно эволюционирует, благодаря тому, что участники регулярно выдвигают новые требования и предлагают новые технологии – это свойство предполагается сохранить в будущем. Пользователям Internet и поставщикам программ, оборудования и услуг следует понимать и принимать этот фактор в качестве основного принципа философии Internet.

Описанные в документе процедуры являются результатом многолетнего развития под воздействием растущих потребностей сообщества Internet и учитывают набранный опыт.

1.3 Организация документа

В разделе 2 описаны публикации и архивы, связанные с процессом стандартизации Internet. В разделе 3 рассмотрены типы спецификаций стандартов Internet. Раздел 4 описывает процедуры для проектов спецификаций стандартов Internet. В разделе 5 описаны процедуры для документов BCP (обмен опытом). В разделе 6 описаны процессы и правила стандартизации Internet. В разделе 7 описана работа в процессе стандартизации Internet со спецификациями и документами, созданными в рамках или с участием других комитетов по стандартизации и аналогичных организаций. Раздел 8 посвящен требованиям к хранению замечаний и записей. В разделе 9 определены возможные исключения из описываемых здесь процедур. В разделе 10 приведены правила, связанные с защитой прав интеллектуальной собственности в контексте разработки и использования стандартов Internet. В разделе 11 приведены благодарности людям, принявшим участие в создании этого документа. В разделе 12 отмечено, что данный документ не связан с вопросами безопасности. В разделе 13 приведен список литературы. В разделе 14 даны определения некоторых терминов, используемых в этом документе. Раздел 15 содержит адреса авторов, а в Приложении A приведен список используемых сокращений.

2. Публикации, связанные со стандартами Internet

2.1 RFC

Каждая версия относящейся к стандартам Internet спецификации публикуется в рамках серии документов RFC3. Эта архивируемая серия является официальным каналом для публикации стандартов Internet, а также других документов IESG, IAB и сообщества Internet. Документы RFC можно загрузить с множества сайтов Internet, используя анонимный доступ FTP, gopher, WWW и другие средства Internet.

Серия RFC по сетям началась в 1969 году в рамках проекта распределенной сети проекта ARPA (ARPANET) (см. Приложение A, где описаны сокращения). Серия RFC включает широкий спектр тем в дополнение к стандартам Internet — от начального обсуждения новых концепций до документов о состоянии сети Internet. Публикация RFC входит в сферу ответственности RFC Editor в рамках деятельности IAB.

Правила форматирования и представления RFC определены в документе [5]. Каждый документ RFC доступен в форме текстового фала ASCII. Некоторые RFC представлены дополнительно в других форматах. Отдельные версии RFC могут включать материалы, которые невозможно представить в текстовом формате (в частности, графики и рисунки) и форматируются в особом порядке.

Более жесткие требования предъявляются к проектам стандартов — текстовая версия является определяющим источником и, следовательно, должна содержать полную и точную спецификацию стандарта, включая все нужные диаграммы и рисунки.

Статус спецификаций протоколов и служб Internet публикуется периодически обновляемом RFC «Internet Official Protocol Standards» [1]. Этот документ показывает уровень совершенства и другую полезную информацию для каждой спецификации протокола или сервиса Internet (см. раздел 3).

В некоторых RFC документированы стандарты Internet. Такие RFC образуют подмножество STD в серии RFC [4]. Когда спецификация принимается в качестве стандарта Internet, она получает дополнительную метку сида STDxxx, но сохраняет свой номер RFC и положение в серии документов (см. параграф 4.1.3).

Некоторые RFC стандартизуют результаты общественных обсуждений принципов и заключений о наилучших способах выполнения тех или иных операций или функций процесса IETF. Такие RFC образуют подмножество документов BCP и получают дополнительную метку BCPxxx, сохраняя свой номер RFC и место в серии документов (см. раздел 5).

Не всем спецификациям протоколов и служб следует присваивать статус Internet Standard или BCP. Для не относящихся к стандартам спецификаций не применяются правила стандартизации Internet. Такие документы могут сразу публиковаться со статусом «Экспериментальный» (Experimental) или «Информационный» (Informational) RFC по решению RFC Editor вместе с IESG (см. параграф 4.2).

Важно напомнить, что не все RFC являются проектами стандартов и не все проекты получают статус Internet Standard. Точно так же не все RFC, описывающие опыт решения тех или иных задач, становятся BCP. Дополнительная информация по этим вопросам приведена в RFC 1796 [6].

2.2 Черновые варианты (Internet-Draft)

В процессе разработки спецификации предварительные (черновые — draft) варианты документа могут публиковаться для просмотра и комментирования в каталоге IETF Internet-Drafts, который доступен на множестве хостов Internet. Это позволяет обеспечить широкой аудитории доступ к документу и упрощает процесс его рецензирования и обновления.

Документы Internet-Draft публикуются в качестве RFC или сохраняются в каталоге Internet-Drafts не более 6 месяцев. Если в течение этого срока документ не получил одобрения IESG на публикацию RFC, он просто удаляется из каталога. Черновой вариант документа может быть в любой момент заменен новой версией и отсчет 6 месяцев начнется заново с момента обновления.

Наличие документа Internet-Draft не означает публикации спецификации, поскольку спецификации публикуются только через механизм RFC, описанный в предыдущем параграфе. Документы Internet-Drafts не имеют формального статуса и могут быть удалены в любой момент.

Ни в коем случае не следует ссылаться на документы Internet-Draft в статьях, отчетах или запросах предложений, а также использовать такие документы в качестве основания для претензий на несоответствие Internet-Draft.

Примечание: Допустимо ссылаться на проекты спецификаций, которые с достаточной вероятностью будут опубликованы в форме RFC, используя фразу «Work in Progress» (работа продолжается) без ссылки на документы Internet-Draft. Это можно делать и в проектах стандартов, пока упоминаемая спецификация не завершена (с указанием фразы «Work in Progress» или без таковой).

3. Спецификации стандартов Internet

Спецификации, подчиняющиеся процедурам стандартизации Internet делятся на две категории — технические спецификации (TS4) и заявления о применимости (AS5).

3.1 Технические спецификации (TS)

Технической спецификацией является любое описание протокола, сервиса, процедуры, соглашения или формата. Спецификация может полностью описывать все аспекты темы или оставлять некоторые параметры или опции не заданными. TS может быть самодостаточным документом или включать материалы из других спецификаций путем указания ссылок на соответствующие документы (не обязательно стандарты Internet).

В TS следует включать указание сферы действия, а также описание области применения. Таким образом, TS, по сути своей относящиеся к некому контексту, должны включать заявление на этот счет. Однако TS не задают требования по их использованию в Internet — такие требования в зависимости от конкретного контекста применения спецификации TS определяются в заявлении о применимости (Applicability Statement).

3.2 Заявление о применимости (AS)

Заявление о применимости указывает как и при каких условиях одна или множество TS могут применяться для поддержки конкретной возможности (свойства) Internet. AS может указывать применимость TS, которые не являются стандартами Internet, как указано в разделе 7.

AS указывает имеющие отношение к вопросу TS и конкретный способ их применения, а также может включать отдельные значения или диапазоны параметров TS или указывать субфункции TS, которые должны быть реализованы. AS также указывает обстоятельства, при которых использование конкретных TS является обязательным, рекомендуемым или факультативным (см. параграф 3.3).

AS может описывать конкретные методы применения TS в ограниченной области применимости (domain of applicability) – например, для маршрутизаторов Internet, терминальных серверов, систем Internet с интерфейсами в сети Ethernet или серверов баз данных, работающих на основе дейтаграмм.

Наиболее полным вариантом AS является всеобъемлющая спецификация соответствия (их называют обычно «документ о требованиях» – requirements document) для определенного класса систем Internet (например, маршрутизаторов или хостов).

AS не может иметь уровня, превышающего уровень совершенства любой TS с проектом стандарта, на которую AS опирается (см. параграф 4.1). Например, TS уровня Draft Standard может указываться в AS уровня предложенного (Proposed Standard) или предварительного стандарта (Draft Standard), но не в AS уровня Standard.

3.3 Уровни требований

В AS следует указывать один из перечисленных ниже уровней требований (requirement level) к каждой упоминаемой TS:

  1. Обязательно (Required). Реализация упоминаемой TS обязательна для выполнения минимальных требований, задаваемых данным AS. Например, протоколы IP и ICMP должны быть реализованы в любой системе Internet, использующей стек протоколов TCP/IP.

  2. Рекомендуется (Recommended). Реализация упоминаемой TS не требуется для обеспечения минимальной совместимости, однако опыт и общие технические соображения говорят о желательности этой реализации в сфере применимости AS. Производителям настоятельно рекомендуется включать функции, свойства и протоколы из Recommended TS в свою продукцию и следует отказываться от изх поддержки лишь при наличии серьезных оснований. Например, протокол TELNET следует поддерживать во всех системах, где может потребоваться удаленный доступ.

  3. Факультативно (Elective). Реализация упоминаемой TS не является обязательной в сфере применения AS. Это означает, что разработчики вправе самостоятельно принять решение о поддержке этой спецификации или отдать принятие такого решения пользователю. Например, поддержка DECNET MIB может оказаться желательной для сред, где используется протокол DECNET.

Как указано в параграфе 4.1, к TS, которые не являются проектами стандартов или утратили такой статус, приведенные выше требования не применяются.

Для таких TS вводятся два дополнительных уровня требований:

  1. Ограниченное применение (Limited Use). TS считается приемлемой для использования лишь в определенных или уникальных обстоятельствах. Например, применение протокола уровня Experimental в общем случае следует ограничивать средами, активно участвующими в данном эксперименте.

  2. Не рекомендуется (Not Recommended). TS считается не подходящей для общего пользования. Это может быть обусловлено ограниченной функциональностью, специфической природой или статусом устаревшей (Historic).

Хотя документы TS и AS концептуально разделены, на практике проект стандарта может включать в себя AS и одну или множество TS. Например, техническая спецификация, разработанная специально и исключительно для некой сферы применения (скажем, хост почтового сервера), зачастую включает всю информацию, имеющую отношение к AS и TS. В таких случаях нет никакого смысла разделять информацию по нескольким документам с единственной целью сохранить формальное различие между AS и TS. Однако для TS, которые явно могут применяться в разных сферах, следует принимать этот факт во внимание и обеспечивать возможность создания нескольких заявлений AS.

В документе Official Protocol Standards (STD1) приводятся общие уровни требований для каждой TS с использованием определенной в этом разделе номенклатуры. Этот документ (RFC) периодически обновляется. Во многих случаях более подробное описание уровней требований для конкретных протоколов или отдельных функций можно найти в соответствующих документах AS.

4. Проекты стандартов Internet

Спецификации, которые предназначены на роль стандартов Internet, проходят через несколько уровней процесса под названием «standards track» (стандартизация). Эти уровни включают Proposed Standard (предложенный стандарт), Draft Standard (предварительный стандарт) и Standard (стандарт) — они определены в параграфе 4.1. Сам процесс стандартизации описан в разделе 6.

Даже после утверждения спецификации в статусе Internet Standard зачастую продолжается ее развитие на основе набранного опыта и осознания новых требований. Номенклатура и процедуры стандартизации Internet обеспечивают замену устаревших стандартов Internet на новые и присваивание соответствующих меток документам, связанным с выведенными из употребления стандартами. В параграфе 4.2 определен набор статусных уровней для документов, которые не являются проектами стандартов (например, данный документ).

4.1 Уровни совершенства проектов стандартов

Спецификации Internet проходят стадии разработки, тестирования и внедрения. В рамках стандартизации Internet эти этапы имеют формализованные метки (maturity level — уровень совершенства).

В этом разделе описаны «уровни совершенства» и характеристики, ожидаемые от спецификаций на каждом уровне.

4.1.1 Предложенный стандарт

Исходным уровнем для проекта стандарта служит Proposed Standard (предложенный стандарт). Для присвоения спецификации статуса Proposed Standard требуются действия согласие IESG.

Спецификации уровня Proposed Standard в общем случае описывают стабильные, понятные и получившие позитивные отклики от сообщества решения, которые представляются подходящими для решения задач сообщества. Однако последующий опыт применения может менять оценки и даже приводить к отказу от таких спецификаций без принятия в качестве стандарта.

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

IESG может потребовать наличия реализации и опыта применения до предоставления статуса Proposed Standard спецификациям, которые существенно воздействуют на основные протоколы Internet или задают поведение, которое может оказать значительное влияние на работу сети Internet.

Документы уровня Proposed Standard не должны иметь каких-либо технических пропусков в части включаемых в спецификацию требований. Тем не менее, IESG вправе отказаться от этого требования для того, чтобы присвоить статус Proposed Standard спецификациям, которые представляются полезными и необходимыми (а также, своевременными) даже с учетом технических недоработок.

Разработчикам следует трактовать уровень Proposed Standard как незавершенную спецификацию. Желательно реализовать ее для приобретения опыта и проверки, тестирования и прояснения спецификации. Однако, поскольку спецификация уровня Proposed Standard может быть изменена в результате обнаружения проблем или появления более эффективного решения, развертывание реализаций таких стандартов в чувствительной к повреждениям среде не рекомендуется.

4.1.2 Предварительный стандарт

Спецификация, на основе которой были разработаны по крайней мере две независимых и совместимых реализации с разным кодом, проверенные на практике, может получить статус предварительного стандарта (Draft Standard). Совместимость в данном случае означает функциональную эквивалентность или взаимозаменяемость компонент системы или процессов, в которых они используются. Если для реализации требуется использовать запатентованную или контролируемую иным способом технологию, требуется также наличие реализаций полученных с использованием раздельных процессов лицензирования. Повышение статуса спецификации до уровня Draft Standard показывает потенциальную полезность данной спецификации.

Требование наличия по крайней мере двух независимых и совместимых реализаций относится ко всем опциям и характеристикам, включенным в спецификацию. В тех случаях, когда для некоторых опций или характеристик нет двух независимых совместимых реализаций спецификация может получить статус Draft Standard только после удаления соответствующих опций или характеристик.

Руководитель рабочей группы отвечает за документирование реализаций, использованных для получения статуса Draft Standard или Internet Standard, и результатов тестирования их взаимодействия. Такая документация должна включать информацию о поддержке каждой отдельной опции или характеристики. Документацию следует представлять руководителю направления (Area Director) при запросе статуса (см. раздел 6)

Предварительный стандарт (Draft Standard) должен быть хорошо растолкованным (well-understood) и для него должна быть достоверная информация о достаточном уровне стабильности, а также должна присутствовать база для разработки реализаций. Спецификация уровня Draft Standard может потребовать дополнения или более широкого развертывания в реальных условиях после того, как реализации, основанные на спецификации уровня Draft Standard, продемонстрируют непредусмотренное поведение при крупномасштабном использовании в в реальных средах.

Документы со статусом Draft Standard обычно рассматриваются, как окончательные спецификации, изменения в которые могут вноситься лишь в случаях обнаружения тех или иных проблем. Для разработчиков в большинстве случаев целесообразно развернуть реализации Draft Standards в чувствительной к нарушениям среде.

4.1.3 Стандарт Internet

Спецификации, для которых имеет значимый опыт реализации и успешного применения, могут получать статус стандартов (Internet Standard). Статус Internet Standard (иногда просто Standard) характеризуется высоким уровнем технической зрелости и обычно показывает, что соответствующие протоколы или службы обеспечивают сообществу Internet значимые преимущества.

Спецификациям, получившим статус стандарта, присваивается номер в серии документов STD с сохранением имеющегося номера RFC.

4.2 Уровни совершенства документов, не являющихся проектами стандартов

Не каждая спецификация содержит проект стандарта. Спецификация может просто не предназначаться на роль стандарта Internet или пока не готова быть проектом стандарта. Кроме того, спецификация может быть заменена более новым документом со статусом Internet Standard, в также полностью выйти из употребления.

Спецификации, не относящиеся к проектам стандартов получают специальные метки Experimental (экспериментальная), Informational (информационная) или Historic (устаревшая). Документы с такими метками никогда не получают статуса Internet Standard.

4.2.1 Экспериментальная

Статус Experimental обычно присваивается спецификациям, которые являются частью какого-то исследования или разработки. Такие спецификации публикуются с информационными целями для технического сообщества Internet и, как часть процесса архивирования результатов работ. Такие спецификации публикуются по усмотрению редакторов с учетом адекватности их координации с процессом стандартизации (см. ниже). Спецификации со статусом Experimental могут быть результатом организованного исследования Internet (например, исследовательской группы IRTF), рабочей группы IETF или усилий отдельных исследований.

4.2.2 Информационная

Информационные (Informational) спецификации публикуются для информирования сообщества Internet по общим вопросам и не представляют какого-либо согласованного мнения сообщества или рекомендаций. Метка Informational применяется для обозначения своевременных публикаций по широкому спектру вопросов и присваивается по решению редактора по результатам проверки адекватности координации документа с процессом стандартизации (см. параграф 4.2.3).

Спецификации, подготовленные вне сообщества Internet и не включенные в процесс стандартизации Internet по любому из перечисленных в разделе 10 признаков, могут публиковаться как Informational RFC с разрешения владельца и при согласии RFC Editor.

4.2.3 Процедуры для экспериментальных и информационных RFC

Если документ, для которого предполагается публикация в категории Experimental или Informational, не является результатом работы группы IETF, такой документ следует представлять напрямую RFC Editor. Документ будет опубликован RFC Editor, как Internet-Draft, который еще не публиковался. Для того, чтобы отделить такие документы от остальных Internet-Draft они помечаются или группируются в каталог I-D. После такой публикации RFC Editor ожидает в течение двух недель откликов на спецификацию. Предполагается, что редактор (RFC Editor) оценит целесообразность публикации документа со статусом Experimental или Informational. Возможен также отказ от публикации, если по мнению RFC Editor документ не связан с функционированием Internet или не соответствует техническим и/или редакционным требованиям к RFC.

Для предотвращения использования спецификаций Experimental и Informational с целью обхода процесса стандартизации Internet между IESG и RFC Editor была достигнута договоренность о том, что RFC Editor будет информировать IESG о любых документах, поданных для публикации в категории Experimental или Informational, если по мнению редактора такая спецификация с работами, выполняемыми или планируемыми в сообществе IETF. В течение разумного срока IESG будет рассматривать такие документы и рекомендовать их публикацию с запрошенным статусом или передавать в IETF с целью включения в процесс стандартизации Internet.

Если (a) IESG рекомендует передать документ на обработку в контексте IETF, но автор не согласен с таким решением или (b) IESG решит, что документ вступает в противоречие с действиями IETF, документ может быть опубликован со статусом Experimental или Informational. В таких случаях IESG может включить в документ текст об ограничениях (disclaimer) в разделе Status of this Memo публикуемого RFC или сразу после этого раздела для понимания читателями обстоятельств публикации документа.

Документы, предложенные для публикации со статусом Experimental или Informational рабочими группами IETF, проходят процедуру рецензирования IESG. Рецензирование инициируется в соответствии с процессом, описанным в параграфе 6.1.1.

4.2.4 Устаревшая

При создании новой спецификации взамен существующей или по иным причинам документ может быть признан утратившим силу. Для таких документов предусмотрен отдельный статус Historic (были предложения воспользоваться термином Historical, но в настоящее время используется Historic).

Примечание. Спецификации проектов стандартов обычно не должны зависеть от других спецификаций проектов стандартов, имеющих более низкий уровень совершенства (статус), или спецификаций, не являющихся проектами стандартов, если это не спецификации от других органов по стандартизации (см. раздел 7).

5. Обобщение опыта (BCP)

Серия документов BCP среди RFC предназначена для спецификаций, связанных с практикой стандартизации и результатами обсуждений в рамках сообщества. К документам BCP применяется такой же набор процедур, как для проектов стандартов, и, таким образом, сообщество IETF может определять и подтверждать представления о позитивном опыте применения.

Исторически стандарты Internet представляют собой прежде всего технические спецификации для программ и оборудования, которые требуются компьютерам при взаимодействии через соединенные между собой сети. Однако в силу того, что Internet представляет собой множество сетей, управляемых разными организациями с различными целями и правилами, для высококачественного обслуживания пользователей Internet требуется обеспечить следование всех операторов и администраторов неким общим рекомендациям в части политики и операций. Несмотря на то, что такие рекомендации по своему содержанию и стилю существенно отличаются от стандартов протоколов, для организации документов с рекомендациями требуется аналогичный процесс, обеспечивающий достижение консенсуса.

Хотя в состав таких организаций, как IAB и IESG входят люди, которые сами по себе могут участвовать в технической работе IETF, понятно, что эти организации, как таковые, являются лидерами в сообществе. В качестве лидеров технического сообщества Internet эти организации должны выдвигать идеи, стимулирующие работы в определенных направлениях, поднимать значимость некоторых проблем, задавать архитектурные принципы и обращать свои мысли на другие вопросы. Серия документов BCP обеспечивает хорошо структурированный способ управления обменом опыта для этих управляющих организаций, позволяющий вносить предложения в части направлений работы IETF с учетом мнения сообщества.

Кроме того, серия BCP может быть использована также для документирования деятельности IETF. Например, данный документ определяет процесс стандартизации IETF и публикуется, как BCP.

5.1 Процесс рецензирования BCP

В отличие от проектов стандартов механизмы, описываемые в BCP, не так хорошо подходят для поэтапного внедления и, в общем случае, для имеет смысл лишь полная и незамедлительная реализация.

Процесс BCP похож на процесс для предложенных стандартов. BCP подается в IESG для рецензирования (см. параграф 6.1.1) с использованием существующих процедур рецензирования, включая Last-Call в списке почтовых рассылок IETF Announce. Однако после одобрения IESG процесс завершается публикацией документа. Опубликованный документ считается получившим техническое одобрение IETF.

В частности, документа, являющиеся кандидатами в BCP, должны пройти процедуры, описанные в параграфах 6.1 и 6.4 данного документа. Процесс BCP может быть обжалован в соответствии с процедурами параграфа 6.5.

Поскольку BCP представляет согласованное мнение сообщества, но разработка таких документов занимает меньшие сроки, для BCP требуются особые меры. В частности, к BCP не следует относиться просто как к более строгим информационным RFC, скорее их следует рассматривать, как документы, отличающиеся по своему содержимому от информационных RFC.

Спецификации или группе спецификаций, одобренной в качестве BCP, присваивается номер в серии BCP с сохранением номеров RFC.

6. Процесс стандартизации Internet

Механизмы процесса стандартизации Internet включают решения IESG, касающиеся изменения уровня совершенства проекта стандарта. Несмотря на наличие большого числа объективных критериев (см. ниже и раздел 4) для принятия решения IESG, не существует алгоритма гарантированной оценки той или иной спецификации. Технический опыт коллектива IESG играет важную роль в процессе принятия решений об оценке проектов стандартов.

6.1 Действия по стандартизации

Действия по стандартизации (standards action) – включение конкретной спецификации в число проектов стандартов или исключение из их числа — должны одобряться IESG.

6.1.1 Инициирование

Спецификация, претендующая на уровень проекта стандарта Internet, должна быть сначала направлена, как Internet-Draft (см. параграф 2.2), если статус не был изменен при публикации RFC. Документ продолжает находиться в категории Internet-Draft в течение периода не менее двух недель. За это время могут быть получены отклики, на основании которых может быть рекомендовано изменение статуса (действия по стандартизации).

Действия по стандартизации инициируются рекомендацией, направляемой ответственной за спецификацию рабочей группы IETF руководителю направления (Area Director) с копией в секретариат IETF. Если спецификация не связана с рабочей группой, она может быть рекомендована членом IESG.

6.1.2 Рецензия и одобрение IESG

IESG следует определить, соответствует ли представленная спецификация критериям параграфа 6.1.1 в части рекомендованных действий (см. параграфы 4.1 и 4.2), а также следует определить соответствие технического уровня и четкости изложения спецификации тому уровню совершенства, который рекомендуется установить для данной спецификации.

Для получения всей информации, требующейся для такого определения, особенно в тех случаях, когда IESF рассматривает спецификацию, как чрезвычайно важную с точки зрения возможного влияния на Internet или стек протоколов Internet, IESG может, по своему усмотрению, назначить независимую техническую экспертизу спецификации.

IESG будет направлять в IETF уведомление об ожидающих рассмотрения IESG документах для того, чтобы обеспечить возможность окончательного рассмотрения документа сообществом Internet. Такое уведомление (Last-Call) передается по электронной почте через список рассылки IETF Announce. Комментарии к Last-Call нужно принимать от всех, отправлять их следует по адресу, указанному в анонсе Last-Call.

Период ожидания для Last-Call следует делать не короче двух недель за исключением случаев, когда стандартизация не была инициирована рабочей группой IETF — в таких случаях на рассмотрение документа сообществом следует отводить не менее четырех недель. Если IESG предполагает значительный интерес сообщества к рассматриваемому документу, продолжительность Last-Call может быть увеличена (в том числе и для начатого ранее обсуждения).

IESG может изменить действие, рекомендованное при подаче спецификации. Например, может быть принято решение о рассмотрении вопроса публикации спецификации в категории, отличной от предложенной изначально. Если IESG принимает такое решение до процедуры Last-Call, эта процедура должна проводиться с учетом точки зрения IESG. IESG может также принять решение об изменении категории при публикации на основе откликов 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. Этот момент считается публикацией (publication of record) стандарта Internet.

RFC Editor следует периодически обновлять документ Internet Official Protocol Standards [1], в котором указывается статус всех спецификаций протоколов и служб Internet.

6.2 Продвижение стандартов

Описанная в параграфе 6.1 применяется для каждой спецификации, продвигаемой в качестве стандарта.

Спецификация должна сохранять статус предложенного стандарта (Proposed Standard) не менее шести (6) месяцев.

Спецификация должна сохранять статус предварительного стандарта (Draft Standard) не менее четырех (4) или до момента очередной конференции IETF (но не менее 4 месяцев).

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

В процессе стандартизации спецификация может быть (скорей всего, реально будет) пересмотрена. На этом этапе IESG нужно определить объем и значимость пересмотра и, при необходимости, изменить рекомендованные по отношению к ней действия. Незначительные изменения ожидаемы, но серьезная переработка спецификации может потребовать накопления дополнительного опыта до смены уровня (статуса). Если же спецификация изменена очень существенно, IESG может порекомендовать рассматривать ее как новый документ, для которого процесс стандартизации запускается с самого начала.

Смена статуса влечет за собой переиздание спецификации в новом RFC, за исключением редких случаев, когда спецификация практически не изменилась по сравнению с предыдущей публикацией. Как правило «пакет» изменений включается в спецификацию при прохождении следующего уровня стандартизации. Однако отсрочка внесения изменений до этого момента в некоторых случаях может быть нежелательной или даже невозможной. Например, в случае серьезной опечатки или технической ошибки, которая не требует замены спецификации в целом, может потребоваться незамедлительная корректировка. В таких случаях IESG или RFC Editor может быть предложено переиздание RFC (с новым номером); отсчет времени ожидания в процессе стандартизации для таких случаев не сбрасывается.

Когда проект стандарта не получил статуса Internet Standard, но сохраняет свой уровень в течение двадцати четырех (24) месяцев, каждые двенадцать (12) месяцев (пока статус не изменится) IESG нужно пересматривать вопрос осмысленность продолжения усилий по стандартизации и полезности предложенной технологии. После каждого такого пересмотра IESG следует принимать решение о прекращении или продолжении работ и одновременно IESG нужно принять решение о сохранении для спецификации текущего уровня или ее перевода в статус Historic (устаревшая). Это решение должно быть передано в IETF по электронной почте через список рассылок IETF Announce, чтобы обеспечить сообществу Internet возможность выразить свое мнение. Это положение не препятствует легитимной и активной работе групп WG и предназначено для создания административного механизма прекращения бессмысленной работы.

6.3 Пересмотр стандарта

Новая версия существующего стандарта (Internet Standard) должна полностью проходить процесс стандартизации Internet, как новая спецификация. После того, как новая версия достигла уровня Standard, она обычно становится заменой прежней версии, которая получает статус Historic (устаревшая). Однако в некоторых случаях обе версии могут сохранять статус Internet Standard для удовлетворения требований установленной базы. В таких случаях отношения между старой и новой версией спецификации должны быть явно указаны в тексте новой версии или специальном документе (например, заявление о применимости – Applicability Statement; см. параграф 3.2).

6.4 Отзыв стандарта

Поскольку технологии развиваются, возможны ситуации, когда новая спецификация уровня Standard обеспечивает настолько сильное техническое превосходство по отношению к одной или нескольким существующим спецификациям, что их следует отозвать. В таких случаях или в иных ситуациях, когда действующую спецификацию по тем или иным причинам нужно отозвать, IESG следует одобрить замену статуса старой спецификации на Historic. При этом следует использовать такую же процедуру Last-Call и процедуры уведомления, которые применяются при других действиях по стандартизации. Запрос на отзыв стандарта может исходить из рабочей группы (WG), руководителя направления (Area Director) или иной заинтересованной стороны.

6.5 Разрешение конфликтов и апелляции

На различных этапах процесса IETF возможно возникновение споров. Насколько это возможно, процесс разработан так, чтобы можно было найти компромисс и в итоге прийти к соглашению, однако возникают ситуации, когда даже самые грамотные и разумные люди не могут прийти к согласию. В целях обеспечения открытости и беспристрастности такие конфликты должны разрешаться в процессе открытого обсуждения. В данном параграфе описаны процедуры, которых следует придерживаться в тех случаях, когда проблемы стандартизации Internet не могут быть решены в рамках обычных процессов рабочих групп IETF и других участников процесса стандартизации.

6.5.1 Обсуждения в рабочих группах

Отдельные лица (независимо от их принадлежности к соответствующей рабочей группе) могут не соглашаться с рекомендациями рабочей группы на основании своей убежденности в том, что (a) их точка зрения не получила адекватного рассмотрения в рабочей группе или (b) рабочая группа выбрала технически некорректное решение, которое на их взгляд ставит под сомнение качество и/или целостность результатов работы группы. Первый случай относится к организации работы группы, а второй связан с возможностью технической ошибки. Эти случаи достаточно сильно различаются, но для обоих используется одинаковая процедура рецензирования (обзора).

Несогласному с рекомендациями рабочей группы нужно сначала обсудить вопрос с руководителем этой группы, который может привлечь к обсуждению других членов группы (или всю группу целиком).

Если таким способом разногласия снять не удалось, любая из вовлеченных сторон может обратиться к руководителю направления (Area Director) в рамках которого создана данная группа. Руководителю направления следует попытаться разрешить споры.

Если руководителю направление не удается снять разногласия, любая из вовлеченных в процесс сторон может обратиться непосредственно в IESG. В таких случаях IESG следует изучить ситуацию и попытаться разрешить конфликт выбранным по своему усмотрению путем.

Если на уровне IESG не удается найти решения, удовлетворяющего стороны, любой из вовлеченных в процесс может обратиться для разрешения конфликта в IAB. В таких случаях IAB следует изучить ситуацию и попытаться разрешить конфликт выбранным по своему усмотрению путем.

Решение IAB является окончательным для вопросов, относящихся к соблюдению процедуры стандартизации Internet, и вопросов, связанных с техническими преимуществами.

6.5.2 Нарушения процесса стандартизации

В этом документе наперед задаются процедуры, требующиеся для соблюдения открытости и беспристрастности процесса стандартизации Internet, а также технической жизнеспособности принимаемых стандартов. IESG в данном направлении является основным агентом IETF, именно IESG отвечает за соблюдение требуемых процедур и выполнение всех требующихся при стандартизации действий.

Если отдельный человек (individual) не согласен с предпринятыми в этом процессе действиями IESG, этому человеку следует сначала обсудить вопрос с председателем ISEG. Если IESG Chair не сможет удовлетворить претензии, IESG в целом следует пересмотреть свои действия с учетом заявленных претензий и определить необходимость дальнейших действий. IESG нужно представить свой отчет о рассмотрении жалобы в IETF.

Если заявитель не удовлетворен итогами рассмотрения IESG, он может обратиться в IAB со своими претензиями. IAB следует разобраться в ситуации и попытаться решить проблему по своему усмотрению, сообщив результат в IETF.

Если обстоятельства этого требуют, IAB может отменить решение IESG и вернуть ситуацию в состояние, которое было до принятия решения IESG. IAB может также рекомендовать применение тех или иных мер к IESG или вынести иные рекомендации по своему усмотрению. Однако IAB не имеет права брать на себя роль IESG в части принятия решений вопросов, в которых полномочия предоставлены только IESG.

Решение вопросов соблюдения процедур стандартизации Internet в IAB является окончательным.

6.5.3 Вопросы применимости процедуры

Для исключительных случаев, когда возникают претензии к самим процедурам (описанным в настоящем документе) в части их неадекватности или недостаточной защиты прав всех сторон в плане открытости и беспристрастности процессов стандартизации Internet, существует специальная процедура. Жалобы такого типа передаются в Попечительский совет сообщества Internet6. Президент Internet Society должен быть проинформирован о такой апелляции в течение двух недель с момента ее подачи и сразу должен уведомить подателя жалобы о предполагаемом сроке ее рассмотрения в Попечительском совете. Совету следует решить принять решение по своему усмотрению и сообщить в IETF о принятом решении.

Решение Попечительского совета является окончательным применительно ко всем аспектам спора.

6.5.4 Процедура апелляции

Все апелляции должны включать подробное и конкретное описание фактов, с которыми связан спор.

Все апелляции должны подаваться в течение двух месяцев с момента публикации оспариваемого действия или решения.

На всех этапах рассмотрения апелляций лица или организации, ответственные за принятие решения, по своему усмотрению определяют конкретные процедуры принятия решений.

Во всех случаях связанные со спором решения и информирование о принятом решении вовлеченных в спор сторон должны осуществляться в течение разумного срока.

[Примечание. Эти процедуры осознанно и явно не устанавливают максимальное время, которое может рассматриваться, как разумное для всех случаев. Процесс стандартизации Internet делает ставку на согласие и усилия по его достижению, поэтому отказывается от ускорения принятия решений в пользу более полного рассмотрения технических аспектов.]

7. Внешние стандарты и спецификации

Существует множество групп и организаций за пределами IETF, разрабатывающих и публикующих стандарты для сетевых протоколов и служб. Если такие сторонние спецификации играют важную роль в Internet, делательно заключить общее соглашение об их использовании — например, путем выпуска стандартов Internet, связанных с такими сторонними спецификациями.

Сторонние спецификации делятся на две категории:

  1. Открытые стандарты

    Различные национальные и международные организации (такие, как ANSI, ISO, IEEE, ITU-T) разрабатывают многочисленные спецификации протоколов и услуг, подобные определенным здесь техническим спецификациям (Technical Specification). Национальные и международные группы также публикуют «соглашения разработчиков», аналогичные определенным здесь заявлениям о применимости (Applicability Statement) и содержащие детали зависящих от реализации практических применений своих стандартов. В рамках процесса стандартизации Internet все эти документы рассматриваются, как открытые внешние стандарты (open external standards).

  2. Другие спецификации

    Некоторые «фирменные» (proprietary) спецификации, которые могут широко использоваться в Internet, могут рассматриваться сообществом Internet наравне со стандартами. Такие спецификации обычно не разрабатываются в рамках открытого процесса и контролируются производителями или организациями, выпустившими данную спецификацию.

7.1 Использование сторонних спецификаций

Для предотвращения конфликтов между конкурирующими версиями спецификаций сообщество Internet не будет стандартизовать спецификации, которые являются просто «Internet-версиями» существующих сторонних спецификаций, без явного согласованного решения о необходимости такой стандартизации. Однако существуют некоторые ситуации, когда сторонние спецификации, играющие важную роль в работе и/или развитии Internet, могут быть адаптированы для применения в Internet.

7.1.1 Включение открытых стандартов

Технические спецификации (TS) или Заявления о применимости (AS) со статусом Internet Standard могут включать в себя сторонние стандарты путем указания ссылок на них. Например, во многих документах Internet Standard используется стандартный набор символов ANSI, известный, как код ASCII [2]. По возможности, упоминания таких стандартов должны включать ссылку на доступную в сети публикацию.

7.1.2 Включение других спецификаций

Зачастую в документы могут включаться фирменные спецификации путем указания версии спецификации и правообладателя в соответствии с требованиями раздела 10. Если такая спецификация не распространена достаточно широко или труднодоступна, IESG может запросить ее публикации со статусом Informational RFC.

В общем случае IESG не следует отдавать предпочтение той или иной фирменной спецификации по отношению к ее техническим эквивалентам и конкурирующим спецификациям, указывая такую спецификацию в качестве обязательной (required) или рекомендуемой (recommended).

7.1.3 Допущение

Рабочая группа IETF может начать со сторонней спецификации и переработать ее в спецификацию Internet. Это допускается, если (1) спецификация предоставлена рабочей группе с соблюдением требований раздела 10 и (2) контроль за изменениями передан в IETF исходным разработчиком спецификации или производных от нее спецификаций.

8. Хранение записей

Каждая организация, вовлеченная в разработку и одобрение стандартов Internet, должна открыто анонсировать и поддерживать общедоступную запись с информацией о каждом виде деятельности, которым она занимается в плане участия в процессах стандартизации Internet. В этом разделе организациями, вовлеченными в разработку и одобрение стандартов Internet, считаются IETF, IESG, IAB, все рабочие группы IETF, а также Internet Society Board of Trustees7.

Заседания IETF и WG должны анонсироваться по электронной почте через список рассылки IETF Announce заблаговременно, чтобы обеспечить возможность участия всех заинтересованных сторон. Анонс должен включать (или указывать) всю информацию, которая может потребоваться для участия заинтересованных лиц. Для заседаний, например, в анонс нужно включать повестку дня, где указаны связанные со стандартизацией вопросы, которые будут обсуждаться.

Формальная запись о мероприятии для связанной со стандартизацией организации должна включать по крайней мере:

  • устав организации (или эквивалентный ему документ);

  • точное и полное расписание заседаний;

  • архивы электронной почты рабочей группы;

  • все тексты от участников процесса, связанный с мероприятием по стандартизации.

С практической точки зрения формальная запись всех мероприятий процесса стандартизации Internet поддерживается секретариатом IETF, который несет за это ответственность за исключением ситуаций, когда предполагается, что рабочая группа IETF поддерживает свой архив почтовой переписки и дожна прилагать все возможные усилия по включению в этот архив всего трафика электронной почты. Руководитель рабочей группы отвечает за предоставление в секретариат IETF полных и точных расписаний встреч рабочей группы. Предварительные стандарты (Internet-Draft), которые (по любой причине) удалены из каталогов Internet-Drafts, должны архивироваться секретариатом IETF с единственной целью сохранения информации о процессах стандартизации Internet. Доступ к таким архивам следует предоставлять только при соответствующих обстоятельствах.

9. Изменение процесса

Данный документ, устанавливающий правила и процедуры для стандартов Internet и связанных с ними документов, сам является результатом процесса стандартизации Internet (как документ BCP, см. раздел 5). Документ заменяет предыдущую версию и с течением времени сам будет заменен более новым документом.

Хотя на момент публикации документа он представлял точку зрения сообщества на организацию процесса стандартизации и требования к документам, позволяющие обеспечить наилучшее качество документов Internet Standard и BCP, не следует предполагать, что это будет корректно всегда. Время от времени может возникать желание обновить документ путем его замены на новую версию. При обновлении данного документа используются такие же открытые процедуры, которые применяются для других BCP.

Кроме того, возможны ситуации, когда жесткое следование процедурам для конкретной спецификации может заводить в тупик или процедура не сможет обеспечить указаний для процесса. В таких ситуациях может оказаться уместным применение описанной ниже процедуры variance (отклонение).

9.1 Процедура Variance

По рекомендации ответственного из рабочей группы IETF (при отсутствии рабочей группы по рекомендации специального комитета) IESG может ввести отдельную спецификацию в процесс стандартизации и продвигать ее даже в тех случаях, когда некоторые требования данного документа не выполняются или не будут выполняться. IESG может одобрить такое отклонение (variance) после принятия решения о том, что преимущества сообщества Internet превзойдут издержки сообщества, связанные с отказом от соблюдения требований данного документа. Для применения этой прерогативы IESG нужно, по крайней мере, рассмотреть (a) технические достоинства спецификации, (b) возможности стандартизации без отклонения от Internet Standards Process, (c) альтернативы отклонению от процедуры, (d) побочные эффекты отказа от соблюдения правил и (e) возможность IESG минимизировать отклонения от правил. При решении вопроса одобрения отклонений от процедуры IESG по своему усмотрению может ограничивать область отклонений от данного документа и вносить дополнительные ограничения в целях защиты интересов сообщества Internet.

Предлагаемое отклонение должно подробно указывать возникшую проблему, указывать положения данное документа, от которых нужно отклониться, и, как результат — решение IESG, включающее пункты (a) – (d) предыдущего параграфа. Предложенное отклонение следует ввести в качестве Internet Draft. После этого IESG нужно провести расширенную процедуру Last-Call с продолжительностью не менее 4 недель, чтобы получить отклики сообщества на предложение.

IESG по истечении периода Last-Call своевременно готовит свое окончательное решение, одобряющее или отклоняющее предложенное отклонение от процедуры. Об этом решении нужно уведомить IETF по электронной почте через список рассылки IETF Announce. Если отклонение было одобрено, его следует переслать RFC Editor с запросом на публикацию со статусом BCP.

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

К описанным здесь отклонениям от процедур применим процесс подачи и разрешения апелляций (параграф 6.5).

9.2 Исключения

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

В частности, субъектом отклонения от процедуры не могут быть требования параграфов 5.1, 6.1, 6.1.1 (первый абзац), 6.1.2, 6.3 (первое предложение), 6.5 и 9.

10. Права интеллектуальной собственности

10.1. Общие правила

Во всех вопросах, связанных с правами интеллектуальной собственности, целью является обеспечение пользы сообществу Internet и обществу в целом при соблюдении законных прав других лиц.

10.2 Обеспечение конфиденциальности

Никакой часть работы (contribution), которая может быть субъектом тех или иных требований по защите конфиденциальности или иных ограничений на распространение, не может рассматриваться ни на каком этапе процесса стандартизации Internet Standards Process, и не должно делаться никаких допущений в части обеспечения конфиденциальности любого такого вклада (contribution).

10.3. Права и разрешения

В процессе разработки стандартов IETF принимает вклад в такую работу в разных формах от множества лиц. Для эффективного использования таких вкладов требуется понимать права интеллектуальной собственности (IPR8), связанные с ними.

10.3.1. Все вклады в работу

Предлагая свой вклад в работу, каждое предлагающее такой вклад лицо соглашается с приведенными ниже условиями от своего имени, от имени представляемой им организации (если таковая есть) или от имени обладателя прав на вносимый вклад. Когда представленное содержит вклад не только реальных заявителей, но и других лиц, реальные заявители удостоверяют, что все упомянутые участники (contributor) соглашаются с этими условиями от своего имени, от имени организации, которую они могут представлять, или от имени другого обладателя прав на данный вклад.

  1. Некоторые виду работ (например, государственная служба в США) не являются субъектом авторских прав. Однако, принимая, что заявленное является или может быть авторских прав, заявитель, представляемая им организация (если таковая есть) или иные обладатели прав на данный вклад, предоставляют неограниченное, бессрочное, неисключительное, безвозмездное, всемирное право и лицензию ISOC и IETF на любые авторские права на данный вклад. Эта лицензия включает право копировать, публиковать и распространять вклад любым способом, а также создавать на его базе другие работы, включающие этот вклад полностью или частично (лицензия на такие производные работы будет такой же, как на исходный вклад).

  2. Вкладчик (contributor) понимает, что ISOC и IETF не принимают на себя обязательств в части публикации или иного распространения его вклада.

  3. Вкладчик предоставляет право упоминать его имя(имена) и адрес (адреса), а также указывать представляемую организацию(и) (если она есть).

  4. Вкладчик признает, что вклад принимается, как «вознаграждение» основных вкладчиков.

  5. Вкладчик, представляемая им организация (если она есть) и обладатели прав на вклад подтверждают, что вклад не содержит конфиденциальной информации, а ISOC и связанные организации могут свободно раскрывать содержащуюся во вкладе информацию.

  6. Вкладчик признает, что он раскрывает наличие каких-либо имущественных прав или прав интеллектуальной собственности на вклад, которые известны ему. Вкладчик не заявляет, что лично ему известны любые потенциальные имущественные или интеллектуальные права, которые принадлежат или заявлены представляемой им организацией (если она есть) или третьей стороной.

  7. Вкладчик признает отсутствие ограничений на возможность передачи указанных выше прав, персонально известных ему.

Утверждая это описание процесса IETF, Internet Society гарантирует, не будет препятствовать открытому и свободному доступу к документам IETF, для которых предоставлены права и лицензии в соответствии с установленными здесь процедурами, включая документы Internet-Draft и RFC. Эта гарантия является бессрочной и не будут отозвана Internet Society или его преемниками или правопреемниками.

10.3.2. Проекты стандартов

  1. Если IESG известны или заявлены какие-либо патенты, заявки на патенты или иные права собственности применительно к любой спецификации в проекте стандарта, IESG не следует принимать спецификацию без включения в документ текста, указывающего о наличии таких прав или заявке на них. Если спецификацию нужно реализовать до ее принятия, для демонстрации адекватности спецификации принимаются во внимание только те реализации, которые, по заявлению разработчиков, не нарушают таких прав или заявок на них.

  2. IESG не несет никакой ответственности за идентификацию наличия или оценку применимости каких-либо заявленных прав, патентов, заявок на патенты или иных прав в части исполнения обязательств по пункту (A) и не будет занимать никакой позиции по вопросу обоснованности или области действий любых таких прав.

  3. Когда IESG известно о правах, указанных в пункте (A), или заявках на них, исполнительному директору IETF (Executive Director) нужно попытаться получить от заявителя таких прав письменное подтверждение того, что после одобрения IESG спецификации(й) стандарта(ов) Internet любая сторона сможет получить право на реализацию, использование и распространение технологии или работ с использованием или распространением технологии на базе конкретной спецификации(й) на опубликованных, разумных и недискриминационных условиях. Рабочей группе, предлагающей использование технологии, права собственности на которую заявлены, может оказать свою помощь исполнительному директору IETF. Результаты этой процедуры не должны оказывать влияния на процесс стандартизации за исключением того, что IESG может отложить одобрение спецификации, если такая задержка поможет получению требуемого согласия правообладателей. Результаты процедуры будут записаны исполнительным директором IETF и сделаны доступными. IESG может также рекомендовать включение этих результатов во все публикуемые для данной спецификации RFC.

10.3.3 Определение разумных и недискриминационных условий

IESG не будет явно определять, что обеспечение разумных и недискриминационных условий обеспечено практически. Вместо этого будут использоваться обычные требования по развитию стандартов Internet, чтобы убедиться в разумности условий использования. Если две несвязанных реализации спецификации, которые требуются для смены статура Proposed Standard на Draft Standard, будут выполнены двумя разными организациями или индивидуалами или будет достигнут существенный опыт реализации и применения, требуемый для пеервода спецификации со статусом Draft Standard на уровень Standard, это будет основанием считать условия использования разумными и в той или иной степени недискриминационными. Это допущение может быть обжаловано во время процедуры Last-Call.

10.4. Примечания

  1. В проекты стандартов следует включать приведенное ниже замечание:

    «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.»

  2. IETF призывает все заинтересованные стороны в кратчайшие сроки заявлять о наличии каких-либо прав интеллектуальной собственности, относящихся к стандартам Internet. Для этого в каждый, связанный со стандартами документ, следует включать приведенный ниже текст:

    «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.»

  3. Во все связанные со стандартами документы 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.»

  4. В случае, когда IESG знает, что на момент публикации были заявлены права относительно проекта стандарта или описанной (упомянутой) технологии, в документ следует включать приведенный ниже текст:

    «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 Standards Process. Процесс изначально был описан в 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 29, 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, and S. Crocker, “Not All RFCs are Standards”, RFC 1796, April 1995.

14. Определения терминов

IETF Area — направление (деятельности) IETF

Управляемое подразделение в рамках IETF. Направление включает рабочие группы (WG), связанные общей тематикой (например, маршрутизация). Функции управления осуществляются одним или двумя Руководителями направления (Area Director).

Area Director — Руководитель направления

Руководитель IETF Area. Руководители направления вместе с Председателем IETF (IETF Chair) образуют IESG10.

File Transfer Protocol (FTP)

Приложение Internet, используемое для передачи файлов в сетях TCP/IP.

gopher

Приложение Internet, служащее для интерактивного выбора и загрузки файлов в сетях TCP/IP.

Internet Architecture Board (IAB)

Группа, назначенная для оказания помощи в управлении процессом стандартизации IETF.

Internet Engineering Steering Group (IESG)

Группа, состоящая из Руководителей направлений IETF и Председателя IETF. IESG вместе с IAB отвечает за управление IETF и служит для IETF органом, одобряющим стандарты.

interoperable

В данном документе термин «интероперабельность» означает способность взаимодействия через канал обмена данными.

Last-Call

Период публичного комментирования, используемый для оценки уровня согласия сообщества в части обоснованности предложенного решения по стандартизации (см. параграф 6.1.2).

online

Этот термин служит для обозначения информации, доступной через Internet. Документ, указанный, как online, может быть найден и получен через сеть с помощью стандартных приложений Internet (анонимный FTP, gopher, WWW) без каких-либо ограничений или оплаты.

Working Group

Группа под управлением IESG и IAB для работы над конкретной спецификацией, группой спецификаций ил и темой.

15. Адрес автора

Scott O. Bradner

Harvard University

Holyoke Center, Room 813

1350 Mass. Ave.

Cambridge, MA 02138

USA

Phone: +1 617 495 3864

EMail: sob@harvard.edu

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

Приложение 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. – Сектор стандартизации телекоммуникаций Международного Союза Электросвязи. Раньше назывался CCITT.

IAB Internet Architecture Board — Совет по архитектуре Internet.

IANA Internet Assigned Numbers Authority — Агентство по распределению значений для Internet.

IEEE Institute of Electrical and Electronics Engineers — Институт инженеров-электриков и электроников.

ICMP Internet Control Message Protocol — Протокол управляющих сообщений Internet.

IESG Internet Engineering Steering Group — Руководящая инженерная группа Internet.

IETF Internet Engineering Task Force — Комитет по инженерным задачам Internet.

IP Internet Protocol — протокол Internet.

IRSG Internet Research Steering Group — Руководящая группа по исследованиям Internet.

IRTF Internet Research Task Force — Комитет по исследовательским задачам Internet.

ISO International Organization for Standardization — Международный комитет по стандартизации.

ISOC Internet Society — Сообщество Internet.

MIB Management Information Base — база информации для управления.

OSI Open Systems Interconnection — взаимодействие открытых систем.

RFC Request for Comments — запрос обсуждения.

TCP Transmission Control Protocol — протокол управления передачей.

TS Technical Specification — техническая спецификация.

WWW World Wide Web – «всемирная паутина».

1Internet Architecture Board — Совет по архитектуре Internet.

2Internet Engineering Steering Group – исполнительный комитет IETF.

3Request for Comments — запрос комментариев.

4Technical Specification.

5Applicability Statement.

6Internet Society Board of Trustees.

7Попечительский совет Internet.

8Intellectual property rights.

9В соответствии с RFC 3232 документ утратил статус стандарта. Данные о выделенных значениях в настоящее время публикуются на сайте www.iana.org/numbers. Прим. перев.

10Internet Engineering Steering Group

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.