RFC 8126 Guidelines for Writing an IANA Considerations Section in RFCs

Internet Engineering Task Force (IETF)                         M. Cotton
Request for Comments: 8126                                           PTI
BCP: 26                                                         B. Leiba
Obsoletes: 5226                                      Huawei Technologies
Category: Best Current Practice                                T. Narten
ISSN: 2070-1721                                          IBM Corporation
                                                               June 2017

Рекомендации по написанию раздела «Взаимодействие с IANA» в RFC

Guidelines for Writing an IANA Considerations Section in RFCs

PDF

Аннотация

Многие протоколы используют идентификаторы, представляющие собой константы и другие общеизвестные (well-known) значения. Однако после определения протокола и начала его развертывания может потребоваться выделение новых значений (например, для нового типа опций DHCP, нового алгоритма шифрования или аутентификации для IPSec). Для того, чтобы такие параметры имели согласованные значения и интерпретацию в разных реализациях протоколов, требуется централизованное управление выделением значений. Для протоколов IETF функции управления возложены на агентство IANA¹.

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

Этот документ служит заменой RFC RFC 5226.

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

Этот документ относится к категории обмена опытом (Internet Best Current Practices)

Документ является результатом работы IETF² и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG³. Дополнительную информацию о BCP можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc8126.

Авторские права

Авторские права (Copyright (c) 2017) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Многие протоколы используют точки расширения, которые применяют константы для идентификации разных протокольных параметров. Чтобы гарантировать непротиворечивость значений этих полей и возможность взаимодействие, выделение значений полей зачастую требует координации и централизованного хранения выделенных значений. Поле Protocol в заголовке IP [RFC791] и типы MIME [RFC6838] служат примерами такой координации.

IETF выбирает оператора IFO⁴ для параметров протокола, определяемого IETF. В соглашении между IETF и текущим IFO (ICANN), это называется оператором услуг протокольных параметров (IPPSO⁵). Для совместимости с прежней практикой IFO и IPPSO в этом документе обозначаются аббревиатурой IANA [RFC2860].

В этом документе мы будем называть наборы возможных значений полей «пространством имен» (namespace). Привязка или связывание конкретного значения из пространства имен с определенными целями называется выделение (назначением). Используются также термины assigned number (назначенное число), assigned value (назначенное значение), code point (код), protocol constant (протокольная константа), protocol parameter (параметр протокола). Акт назначения называется регистрацией и выполняется в контексте реестра. Термины «назначение» и «регистрация» чередуются в этом документе.

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

Обычно такая информация представляется в специальном разделе IANA Considerations (Взаимодействие с IANA).

1.1. Раздел IANA Considerations предназначен для IANA

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

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

Действия IANA обычно указываются в виде запросов к IANA (например, «агентство IANA просят выделить значение TBD1 из реестра Frobozz …»), а редактор RFC будет менять текст с учетом предпринятых действий («Агентство IANA выделило значение 83 из реестра Frobozz …»).

1.2. Обновление информации

IANA поддерживает web-страницу с дополнительными разъяснениями помимо предоставленных здесь, такими как незначительные обновления и краткое руководство. Авторам документов следует прочесть эту страницу. Все существенные обновления принятой практики будут вноситься в обновления BCP 26 (данный документ), который является определяющим.

<https://iana.org/help/protocol-registration>

1.3. Краткий контрольный список

Полезно ознакомиться с этим документом в целом. Если же нужно быстрое ознакомление, приведенный ниже список поможет быстрее найти наиболее важные вещи, которые нужно сделать, и укажет ссылки на более экзотические действия.

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

1. Указать всю информацию, которую нужно знать IANA в разделе «IANA Considerations» вашего документа (см. параграф 1.1).

2. В этот раздел следует помещать лишь информацию для IANA и назначенных рецензентов. Важные технические сведения нужно размещать в соответствующих разделах документа (см. параграф 1.1).

3. Отметим, что IESG имеет полномочия разрешения споров, связанных с регистрацией в IANA. При возникновении каких-либо вопросов или проблем следует получить консультацию у куратора вашего документа и/или руководителя рабочей группы, который может при необходимости привлечь руководителя направления – Area Director (см. параграф 3.3).

При создании нового реестра нужно выполнить указанные ниже действия.

1. Дать реестру описательное имя и представить краткое описание его применения (см. параграф 2.2).

2. Определить группу, в которую реестр следует включить (см. параграф 2.1).

3. Четко указать информацию, которая требуется для регистрации новых значений (см. параграф 2.2). Обязательно указать типы данных, размеры и допустимые значения полей.

4. Задать начальный набор записей реестра, если они имеются (см. параграф 2.2).

5. Убедиться, что правила внесения изменений понятны IANA на случай необходимости изменения формата или правил в будущем (см. параграф 2.3 и 9.5).

6. Указать политику (или набор политик) регистрации для добавления записей в реестр (см. параграф 4 и обратите внимание на примечания в параграфах 4.11 и 4.12).

7. При использовании политики, требующей назначения экспертов (Expert Review или Specification Required) разобраться с разделом 5 и предоставить рекомендации по рецензированию для экспертов (см. параграф 5.3).

8. Если какой-либо диапазон значений реестра нужно зарезервировать для особых случаев или по иным причинам недоступности значений, обратитесь к разделу 6.

При регистрации в имеющемся реестре нужно выполнить указанные ниже действия.

1. Четко указать реестр по его имени, возможно дополнив ссылкой (см. параграф 3.1).

2. Если реестр имеет множество диапазонов для выделения значений, следует четко указать нужный диапазон (см. параграф 3.1).

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

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

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

6. Следует определить (из справочного документа реестра) все специальные правила или процедуры, которые могут применяться для реестра, такие как публикация в определенном списке рассылки для получения комментариев, и выполнить соответствующие требования (см. параграф 3.1).

7. Если правила регистрации еще не задают политику внесения изменений, следует убедиться, что IANA точно понимает правила внесения изменений на случай такой потребности в будущем (см. параграф 9.5).

Если создается документ «bis» или иным путем отменяется устаревший документ, следует обратиться к разделу 8.

Если нужна ранняя регистрация (например, для поддержки тестовых реализаций) до завершения документа, следует обратиться к [RFC7120].

Если нужно изменить формат/содержимое или правила для имеющегося реестра, см. параграф 2.4.

Если нужно обновить имеющуюся регистрацию, см. параграф 3.2.

Если нужно закрыть реестр за ненадобностью, см. параграф 9.6.

2. Создание и пересмотр реестров

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

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

2.1. Организация реестров

Все реестры IANA доступны на странице Protocol Registries по ссылке <https://www.iana.org/protocols>.

На этой странице перечислены реестры, сгруппированные по категориям протоколов, которые объединяют связанные протоколы и упрощают пользователям поиск нужно информации. Ссылки на названия реестров на странице IANA Protocol Registries ведут читателя к страницам с подробным описанием соответствующих реестров.

К сожалению здесь имеется некоторая непоследовательность в именовании. Имена групп называют «protocol category groups» (группы категорий протоколов), «groups» (группы), «top-level registries» (реестры верхнего уровня) или просто «registries» (реестры). Реестры более низкого уровня называют «registries» или «sub-registries» (субреестры).

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

2.2. Документация, требуемая для реестров

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

В частности, такие инструкции должны содержать перечисленные ниже сведения.

Название (имя) реестра

Это имя будет указываться на web-странице IANA и в будущих документах, которым нужны значения из нового пространства. Следует указать полное имя и сокращения, если оно есть. Весьма желательно выбирать имена, которые не будут вносить путаницы с названиями других реестров.

При создании реестра должно быть указано название группы, в которую он включается, точно соответствующее указанному в списке Protocol Registries.

Предоставление URL для точного указания реестра поможет IANA понять запрос. Такие URL могут удаляться из RFC при окончательной публикации или сохраняться в документе. Если включен URL iana.org, IANA при необходимости будет корректировать ссылку.

Информация, требуемая для регистрации

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

Применимая политика регистрации

Правила, которые будут применяться для всех будущих регистрационных запросов. См. Раздел 4.

Размер, формат и синтаксис записей реестра

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

Предполагается указание строк в кодировке ASCII и следует четко указать, принимается ли во внимание регистр символов (например, все строки следует задавать в верхнем или нижнем регистре).

Строки, представляющие параметры протокола, редко (или никогда) будут использовать символы, отличные от ASCII. Если такие символы действительно нужны, следует четко указать их допустимость и требование представлять символы не-ASCII в кодировке Unicode с использованием соглашения (U+XXXX). При создании реестра нужно тщательно обдумать вопрос применения символов других языков и рассмотреть рекомендации (например, раздел 10 в [RFC7564]).

Начальное выделение и резервирование

Должны быть указаны все начальные назначения или регистрации. Кроме того, следует указать все значения, для приватного использования (Private Use), а также Reserved, Unassigned и т. п. (см. параграф 6).

Ниже приведен пример раздела IANA Considerations в документе, создающем новый реестр.

—————————————————————

X. Взаимодействие с IANA

Этот документ определяет новую опцию DHCP, названную FooBar (см. раздел y) и выделяет значение TBD1 из пространства имен DHCP Option <https://www.iana.org/assignments/bootp-dhcp-parameters> [RFC2132] [RFC2939].

Тег	Имя	Размер данных	Смысл
TBD1	FooBar	N	Сервер FooBar

Опция FooBar также определяет 8-битовое поле FooType, для которого агенство IANA создает и поддерживает новый реестр «Значения FooType», используемый опцией FooBar. Начальные значения для реестра DHCP FooBar FooType приведены ниже, выделение новых значений будет происходить по процедуре Expert Review [BCP26]. Назначение включает имя DHCP FooBar FooType и связанное с ним значение.

Значение	Имя DHCP FooBar FooType	Определение
0	Резерв
1	Frobnitz	RFCXXXX, параграф y.1
2	NitzFrob	RFCXXXX, параграф y.1
3-254	Не выделены
255	Резерв

Примеры документов, создающих реестры, можно найти в [RFC3575], [RFC3968], [RFC4520].

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

2.3. Указание контроля изменений для реестра

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

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

Поэтому рекомендуется создавать все реестры с четким указанием правил изменения и полномочий на это. Для реестров, позволяющих регистрацию вне потока IETF, следует для каждого значения указывать контролера. Если определение или ссылку на зарегистрированное значение когда-либо придется менять, IANA важно знать, кто уполномочен вносить изменения. Например, реестр Media Types [RFC6838] включает поле Change Controller в шаблон регистрации. См. Также параграф 9.5.

2.4. Пересмотр имеющихся реестров

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

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

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

Примеры документов с рекомендациями для обновления имеющихся реестров можно найти в [RFC6895], [RFC3228], [RFC3575].

3. Регистрация новых значений в имеющемся реестре

3.1. Требования к документации для регистрации

Часто документы запрашивают выделение в имеющемся реестре (созданном ранее опубликованным документом).

Такие документы должны четко указывать реестр, в котором регистрируется значение. Используется точное имя реестра с web-страницы IANA и указывается, где определен реестр. При ссылке на имеющийся реестр полезно указывать URL для точной идентификации реестра (см. параграф 2.2).

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

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

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

Предлагаемые значения текстовых строк обычно указываются в документе, поскольку конфликты для них менее вероятны. При возникновении конфликта IANA будет обращаться к авторам для согласования иных значений. Когда в проекте нужно указать строковые значения для тестов или ранних реализаций, иногда используется предполагаемое окончательное значение. Однако зачастую лучше использовать черновое значение, возможно включающее номер версии чернового документа. Это позволит отличить ранние реализации от решений, использующих окончательную версию. В документе, предполагающем окончательное значение foobar, можно использовать, например, foobar-testing-draft-05 для версии проекта -05.

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

Например, приведенный ниже текст можно использовать для запроса номера опции DHCPv6.

IANA предлагается назначить значение кода TBD1 для опции DNS Recursive Name Server и TBD2 – для Domain Search List из пространства номеров опций DHCP, определенного в параграфе 24.3 RFC 3315.

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

При запросе множества значений обычно полезно включать сводную таблицу добавлений/изменений. Полезно указывать такую таблицу в формате, применяемом на web-сайте IANA. Пример такой таблицы приведен ниже.

Значение	Описание	Ссылка
TBD1	Foobar	Данный RFC, параграф 3.2
TBD2	Gumbo	Данный RFC, параграф 3.3
TBD3	Banana	Данный RFC, параграф 3.4

Примечание. Если авторы считают, что включение таблицы приведет к многословию или повторам, они могут включить таблицу в проект с просьбой удалить ее перед публикацией RFC.

3.2. Обновление имеющихся записей

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

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

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

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

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

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

3.3. Переопределение процедур регистрации

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

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

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

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

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

3.4. Раннее выделение значений

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

IANA имеет механизм для обработки раннего назначения в некоторых случаях (см. [RFC7120]). Обычно не требуется указывать в реестре возможность раннего распределения, поскольку будут применяться общие правила.

4. Выбор политики регистрации и общеизвестные правила

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

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

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

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

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

Возможно самым важным является то, что непроверенные расширения могут препятствовать взаимодействию и снижать уровень безопасности (см. [RFC6709]).

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

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

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

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

Перечисленные ниже процедуры определены для общего пользования. Они охватывают типичные варианты политики, которые применялись для описания процедур выделения новых значений в пространстве имен. От документов не требуется строгое использование этих процедур, фактическое требование заключается в предоставлении IANA четких и однозначных инструкций. Однако использование этих терминов настоятельно рекомендуется, поскольку их смысл понятен многим. Разработанные заново правила, включая те, которые комбинируют элементы перечисленных процедур новыми способами, могут применяться, если не подходит ни одна из процедур. Это поможет процессу рецензирования, если будет включено объяснение причин выбора. Описания приведенных ниже процедур даны в последующих параграфах.

1. Private Use – приватное использование.

2. Experimental Use – экспериментальное использование.

3. Hierarchical Allocation – иерархическое выделение.

4. First Come First Served – назначение в порядке очереди.

5. Expert Review – рецензия эксперта.

6. Specification Required – требование спецификации.

7. RFC Required – требование публикации RFC.

8. IETF Review – рецензия IETF.

9. Standards Action – стандартизация.

10. IESG Approval – одобрение IESG.

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

Точно так же бывает полезно задать несколько правил, применяемых «параллельно» в зависимости от обстоятельств. Этот вопрос более подробно рассмотрен в параграфе 4.12.

Ниже приведены примеры RFC, где задано несколько «параллельных» правил выделения значений:

LDAP [RFC4520];

идентификаторы TLS ClientCertificateType [RFC5246] (см. ниже);

реестр MPLS Pseudowire Types [RFC4446].

4.1. Приватное использование

Только для частного или локального использования в соответствии с потребностями и целями локального сайта. Не предпринимается попыток предотвращения использования разными сайтами одних и тех же значений с разными (и несовместимыми) целями. Для IANA нет необходимости рассматривать такие назначения и обычно они не важны зрения взаимодействия. Сайт самостоятельно отвечает за использование значений из диапазона Private Use и предотвращение конфликтов (в пределах своей зоны влияния).

Примеры:

специфические для сайта опции DHCP [RFC2939];

реестр Fibre Channel Port Type [RFC4044];

идентификаторы TLS ClientCertificateType из диапазона 224-255 [RFC5246].

4.2. Экспериментальное использование

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

Когда коды отведены для экспериментального использования, важно разъяснить предполагаемые ограничения сферы охвата для эксперимента. Например, можно указать, допустимы ли эксперименты с этими значениями в открытой сети Internet или их следует ограничивать замкнутыми средами. Пример этого можно найти в [RFC6994].

Пример:

экспериментальные значения в заголовках IPv4, IPv6, ICMPv4, ICMPv6, UDP и TCP [RFC4727].

4.3. Иерархическое распределение

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

Примеры.

• Имена DNS – IANA администрирует домены верхнего уровня (TLD⁶) и, как сказано в [RFC1591]:

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

• Идентификаторы объектов, определенные в ITU-T X.208. В соответствии с <http://www.alvestrand.no/objectid/>, реестры включают:

  • IANA – назначение OID в ветви Private Enterprises (частные предприятия);

  • ANSI – назначение OID в ветви US Organizations;

  • BSI – назначение OID в ветви UK Organizations.

• Пространства имен URN – IANA регистрирует идентификаторы URN для пространств имен (NID⁷ [RFC8141]), а получившая NID организация отвечает за назначение URN в своем пространстве имен.

4.4. Назначение в порядке очереди

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

При создании нового реестра с политикой регистрации First Come First Served помимо поля или ссылки с контактными данными в реестр следует включать поле для контролера изменений. Наличие контролера для каждой записи этого типа делает полномочия внесения изменений в будущем более ясными (см. параграф 2.3).

Важно, чтобы изменения в регистрации кода с политикой First Come First Served сохраняли совместимость с назначенным ранее значением, поэтому вносить изменения нужно с осторожностью. В большинстве случаев контролеру изменений не следует запрашивать несовместимые изменения или менять цели использования выделенного значения (см. параграфы 9.4 и 9.5).

Рабочая группа или иная организация, разрабатывающая протоколы с использованием кодов, назначенных по процедуре First Come First Served, должна быть очень осторожной, чтобы сохранить совместимость кодов в линии с уже выделенными кодами. Если это невозможно, новой работе следует перейти на использование иного кода (и зарегистрировать его использование в нужный момент).

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

Примеры:

имена механизмов SASL [RFC4422];

механизмы протокола LDAP и синтаксис LDAP [RFC4520].

4.5. Рецензия эксперта

Требуется рецензия и одобрение назначенного эксперта (см. раздел 5). Хотя формальное документирование этого не требуется, необходимо представить запрос для назначения эксперта, который оценит работу. В определении реестра нужно четко указать регистраторам, какая информация необходима. Фактический процесс запросов на регистрацию администрирует IANA (см. параграф 1.2).

Эта процедура в предыдущих версиях называлась Designated Expert, а текущее название – Expert Review.

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

При выборе процедуры Expert Review и подготовке рекомендаций для эксперта важно внимательно разобраться с разделом 5.

Хорошие примеры рекомендаций для назначенных экспертов приведены ниже.

Протокол EAP⁸ [RFC3748], раздел 6 и параграф 7.2

North-Bound Distribution of Link-State and TE Information Using BGP [RFC7752], параграф 5.1

При создании нового реестра с политикой Expert Review помимо поля или ссылки с контактными данными в реестр следует включать поле для контролера изменений. Наличие контролера для каждой записи этого типа делает полномочия внесения изменений в будущем более ясными (см. параграф 2.3).

Примеры:

EAP Method Types [RFC3748];

версии алгоритма HTTP Digest AKA [RFC4169];

схемы URI [RFC7595];

типы GEOPRIV Location [RFC4589].

4.6. Требование наличия спецификации

Для процедуры Specification Required требуется рецензия и одобрение назначенного эксперта (см. раздел 5), а значения и их трактовки должны быть документированы в постоянно и легко доступных публикациях с достаточным уровнем детализации для обеспечения совместимости независимых реализаций. Эта процедура совпадает с рецензированием экспертами (Expert Review), дополненным требованием выпуска спецификации. В дополнение к обычному обзору документа назначенный эксперт будет рецензировать открытую спецификацию, оценивая ее стабильность и доступность, а также четкость и техническую обоснованность для обеспечения совместимости независимых реализаций.

Слова «постоянно и легко доступны» означают, что документ можно будет найти и получить в течение достаточно продолжительного срока после того, как IANA выделит запрошенные значения. Публикация RFC является идеальным способом выполнения этих требований, однако процедура Specification Required может применяться не только к документам, опубликованным в форме RFC.

Для публикации RFC по-прежнему требуется формальная рецензия назначенного эксперта, но предполагается, что обычный процесс обзора RFC обеспечит необходимый уровень совместимости. Рецензия назначенного эксперта остается важной, но не менее важно отметить, что при наличии согласия IETF эксперт может быть чисто формальным (in the rough – см. также последний абзац параграфа 5.4).

Как и для процедуры Expert Review (параграф 4.5) следует предоставить четкие рекомендации для эксперта при определении реестра и важно разобраться с разделом 5.

При указании этой политики просто используется термин Specification Required. В некоторых спецификациях указывается «Expert Review with Specification Required» и это лишь вызывает путаницу.

Примеры:

идентификаторы Diffserv-aware TE Bandwidth Constraints Model [RFC4124];

идентификаторы TLS ClientCertificateType из диапазона 64-223 [RFC5246];

идентификаторы ROHC Profile [RFC5795].

4.7. Требование публикации RFC

Для политики RFC Required запрос регистрации и связанная с ним документация должны быть опубликованы в виде RFC. RFC не обязательно быть из потока IETF, это может быть любой поток RFC (в настоящее время IETF, IRTF, IAB, Independent Submission [RFC5742]).

Если не указано иное, подойдет RFC любого типа (например, Standards Track, BCP, Informational, Experimental, Historic).

Примеры:

номера алгоритмов DNSSEC DNS Security [RFC6014];

реестры Media Control Channel Framework [RFC6230];

использование сертификатов DANE TLSA [RFC6698].

4.8. Рецензия IETF

(Эта процедура называлась IETF Consensus в первой версии документа). В соответствии с политикой IETF Review новые значения выделяются только через RFC из потока IETF Stream, прошедших через IESG как AD-Sponsored или документы рабочих групп IETF [RFC2026] [RFC5378], прошедших процедуру IETF Last Call и одобренных IESG как имеющих согласие IETF.

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

Если не указано иное, подойдет RFC любого типа (например, Standards Track, BCP, Informational, Experimental, Historic).

Примеры:

типы алгоритмов IPSECKEY [RFC4025];

типы расширений TLS [RFC5246].

4.9. Стандартизация

Для политики Standards Action значения выделяются только через публикацию RFC серии Standards Track или Best Current Practice в потоке IETF.

Примеры:

типы сообщений BGP [RFC4271];

типы опций Mobile Node Identifier [RFC4283];

идентификаторы TLS ClientCertificateType из диапазона I0-63 [RFC5246];

типы пакетов DCCP [RFC4340].

4.10. Одобрение IESG

Новые назначения могут быть одобрены IESG. Хотя здесь отсутствует требование документирования запроса в RFC, IESG во своему усмотрению время от времени запрашивает документы или другие материалы в поддержку запроса.

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

До одобрения запроса IESG может провести консультации с сообществом путем запроса комментариев (call for comments), обеспечивающие как можно больше информации о запросе.

Примеры:

назначение адресов IPv4 Multicast [RFC5771];

значения типов и кодов IPv4 IGMP [RFC3228];

значения типов и опций заголовков Mobile IPv6 Mobility [RFC6275].

4.11. Использование общеизвестных правил регистрации

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

Допустимо также указать одну или несколько общеизвестных политик и включить дополнительные рекомендации, что следует учитывать при обзоре.

Например для регистрации типов носителей [RFC6838] учитывается множество разных ситуаций, которые включают процедуры IETF Review и Specification Required, а также имеются дополнительные критерии, которые следует принимать во внимание эксперту. Это предназначено не для представления процедуры регистрации, а в качестве примера того, что можно сделать при необходимости учесть другие обстоятельства.

Общеизвестные процедуры от «First Come First Served» до «Standards Action» задают диапазон правил с возрастающим уровнем сложности (указаны номера из полного списка в начале раздела 4).

4. First Come First Served

Без рецензирования с минимальной документацией.

5 и 6 (равносильны).

5. Expert Review

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

6. Specification Required

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

7. RFC Required

Публикация любого RFC (не обязательно в потоке IETF).

8. IETF Review

Публикация RFC в потоке IETF, но не обязательно Standards Track.

9. Standards Action

Публикация RFC в потоке IETF со статусом Standards Track или BCP.

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

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

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

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

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

Соответственно, разработчики документов должны предвидеть это и документировать свои соображения по выбору казанной политики (идеально сделать это в самом документе или в записке куратора работы). Куратор должен убедиться в обоснованности предлагаемой политики до передачи документа в IESG.

При пересмотре спецификации политику регистрации следует следует пересмотреть с учетом опыта применения существующей политики.

4.12. Использование комбинации нескольких процедур

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

Таким образом, конкретный реестр может захотеть иногда применять процедуру RFC Required или IETF Review, а в других случаях назначенный эксперт использует Specification Required.

Альтернативой применению комбинации процедур является требование прохождения всех запросов через RFC или рецензирования запросов из RFC назначенными экспертами даже при наличии рецензии и согласия IETF.

Это можно указать в разделе IANA Considerations при описании создания реестра, как показано ниже.

У IANA запрашивается создание реестра «Fruit Access Flags» в группе «Fruit Parameters». Новые регистрации будут выполняться по процедуре IETF Review или Specification Required [BCP26]. Второй вариант следует применять лишь для регистраций, запрошенных SDO вне IETF. Регистрации, запрошенные в документах IETF обрабатываются по процедуре IETF review.

Такие комбинации обычно используют одну из процедур {Standards Action, IETF Review, RFC Required} вместе с одной из {Specification Required, Expert Review}. Следует предоставить рекомендации о применении каждой процедуры как в приведенном выше примере.

4.13. Временная регистрация

Политики некоторых имеющихся реестров разрешают временную регистрацию (см. схемы URI [RFC7595] и поля Email Header [RFC3864]). Регистрации, обозначенные как временные, обычно определяются как более легко создаваемые, изменяемые, переназначаемые или переводимые в другой статус. Схемы URI, например, позволяют выполнять временную регистрацию с неполной информацией.

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

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

5. Назначенные эксперты

5.1. Выбор экспертов

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

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

Зачастую полезно использовать назначенного эксперта лишь в качестве дополнения к другим процессам. Дополнительное рассмотрение этого вопроса приведено в параграфе 4.12.

5.2. Роль назначенного эксперта

Назначенный эксперт отвечает за инициирование и координацию подходящего обзора запроса на выделение. Широта обзора определяется ситуацией и мнением назначенного эксперта. Обзор может быть широким или узким в зависимости от ситуации и решения назначенного эксперта. Обзор может включать консультации с техническими специалистами, обсуждение в публичном списке рассылки, консультации с рабочей группой (или обсуждение в списке рассылки группы, если она уже распущена) и т. п. В идеальном случае назначенный эксперт следует конкретным критериям , документированным для протокола, который создает или будет использовать пространство имен. Примеры таких критериев можно найти в разделах «Согласование с IANA» (IANA Considerations) [RFC3748] и [RFC3575].

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

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

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

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

Если у назначенного эксперта имеется конфликт интересов для конкретного обзора (например, он является автором или апологетом спецификации, связанной с рассматриваемой регистрацией), эксперту следует заявить самоотвод. Если между всеми назначенными экспертами возникает конфликт, им следует попросить назначить временного эксперта для разбора этого конфликта. Руководитель направления (AD⁹) отвечает за назначение эксперта или сам выполняет его функцию.

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

5.2.1. Управление назначенными экспертами в IETF

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

При возникновении конфликтов, связанных с назначенной группой экспертов применяется обычная процедура апелляции, описанная в параграфе 6.5.1 [RFC2026]. В таком случае назначенная группа экспертов считается рабочей группой.

5.3. Рецензии назначенных экспертов

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

• Назначенный эксперт должен реагировать на запросы своевременно – обычно в течение недели для простых запросов и нескольких недель в более сложных случаях. Необоснованные задержки могут вызывать серьезные проблемы у запрашивающей стороны, например, когда запрашиваемые значения нужны для поставки продукции. Это не означает, что рецензирование должно выполняться в указанные компанией сроки, но оно должно начинаться своевременно, а запрашивающая сторона и IANA должны иметь представление о сроках завершения рецензирования.

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

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

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

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

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

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

• Расширения будут вызывать проблемы в работе развернутых систем.

• Расширение будет конфликтовать с другим расширением, которое активно разрабатывается IETF, и его принятие принесет больше вреда, чем пользы в плане функциональной совместимости.

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

Если запрос следует рассмотреть также в конкретном публичном списке рассылки, следует указать его адрес.

5.4. Рецензии экспертов и жизненный цикл документа

Рецензирование назначенным экспертом выполняется в определенный момент и представляет обзор конкретной версии документа. Хотя рецензирование обычно выполняется во время IETF Last Call, решение вопроса о времени рецензирования определяется здравым смыслом. В процессе рецензирования эксперт может узнать о существенном изменении документации для регистрируемого элемента и это требует внимательного и осторожного рассмотрения.

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

Для регистрация из документов Standards Track часто требуется одобрение эксперта (политика регистрации) в дополнение к согласию IETF (для утверждения Standards Track RFC). В таких случаях рецензия назначенного эксперта должна быть своевременной и поданной до оценки документа в IESG. Как правило, IESG не следует задерживать документ в ожидании запоздалого рецензирования. Кроме того, рецензия эксперта не предназначена для изменения решения IETF, поэтому IESG следует основываться на своей оценке, как это делается для других обзоров Last Call.

6. Терминология для общеизвестных правил

Ниже приведены значения статуса для регистрации значений или диапазонов.

Private Use – приватное использование

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

Experimental – эксперимент

Доступно для экспериментальных приложений, как описано в [RFC3692]. IANA не фиксирует выделение значений для каких-либо конкретных приложений.

Unassigned – не выделено

Не выделено и доступно для распределения в соответствии с документированными процедурами. Хотя обычно ясно, что любые не зарегистрированные и не выделенные значения доступны для распределения, иногда полезно явно указывать это. Отметим, что этот статус существенно отличается от Reserved.

Reserved – резерв

Не распределено и недоступно для распределения. Резервные значения сохраняются для специальных целей типа расширения пространства имен по мере его исчерпания. Статус Reserved иногда применяется для значений, которые были выделены, но перестали использоваться, сохраняя их отложенными, пока имеются не распределенные значения. Отметим, что этот статус существенно отличается от Unassigned.

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

Known Unregistered Use – известное незарегистрированное применение

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

7. Ссылки на документы в реестрах IANA

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

• Если документ регистрирует элемент, определенный и описанный в другом месте, регистрируемой ссылке следует указывать документ с определением, а не документ, задающий регистрацию.

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

• Если регистрируемый элемент описан большей частью в конкретном разделе документа, полезно указать этот раздел (например, параграф 3.2 в [RFC4637], а не просто [RFC4637]).

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

8. Что нужно делать в документах «bis»

Время от времени выпускаются RFC, отменяющие предыдущую версию того же документа. Иногда их называют документами bis, например, как RFC 4637, отмененный документом draft-ietf-foo-rfc4637bis. Если в исходном документе был создан реестр и/или записи в реестре, возникает вопрос по части обработки раздела IANA Considerations в документе bis.

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

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

Например, если RFC 4637 регистрирует флаг BANANA в реестре Fruit Access Flags и документация для этого флага приведена в параграфе 3.2, текущий реестр может иметь вид

Значение	Описание	Ссылка
BANANA	Флаг для banana	[RFC4637], параграф 3.2

Если draft-ietf-foo-rfc4637bis отменяет RFC 4637 и в результате редактирования описание флага перенесено в параграф 4.1.2, раздел IANA Considerations документа bis может содержать текст вида:

У IANA запрашивается изменение регистрационной информации для флага BANANA в реестре Fruit Access Flags, как показано ниже.

Значение	Описание	Ссылка
BANANA	Флаг для banana	Данный RFC, параграф 4.1.2

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

Поскольку этот документ отменяет RFC 4637, у IANA запрашивается замена всех регистрационных записей, указывающих на [RFC4637], записями со ссылкой на [[данный RFC]].

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

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

9. Прочие вопросы

9.1. Когда участия IANA не требуется

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

This document has no IANA actions¹⁰.

IANA предпочитает сохранять такие «пустые» разделы IANA в документах для фиксации того, что в документе явно указано отсутствие требуемых от IANA действий (а не просто забыли их указать). Это отличается от прежней практики запроса удаления таких разделов редакторами RFC и авторам предлагается учитывать данное изменение.

9.2. Пространства имен без документированного руководства

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

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

9.3. Регистрация «постфактум»

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

Это является одной из причин включения в параграф 3.1 рекомендации об использовании значений-заменителей (таких как TBD1) в процессе разработки документов. Проблемы зачастую возникают в результате открытого использования незарегистрированных значения после результатов успешных ранних реализаций, которые сохранили применявшиеся при разработке значения, не назначенные IANA.

9.4. Повторное заявление выделенных значений

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

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

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

• Может оказаться целесообразным описать предлагаемые меры и запросить их оценку в соответствующем сообществе пользователей. В некоторых случаях может оказаться целесообразной подготовка соответствующего RFC и прохождение формальных процедур IETF (включая IETF Last Call), как было сделано при отзыве некоторых опций DHCP из числа зарезервированных для приватного использования (Private Use) [RFC3942].

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

9.5. Контактное лицо, правообладатель или владелец

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

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

Реестры могут включать в дополнение к полю Contact поле Assignee (правообладатель) или Owner (владелец, которого называют также контролером изменений – Change Controller), которое может помочь при решении этой проблемы, давая IANA четкую информацию о фактическом владельце регистрации. Это настоятельно рекомендуется, особенно для регистраций, не требующих RFC для поддержки информации (т. е. для реестров с политикой First Come First Served – параграф 4.4, Expert Review – параграф 4.5 и Specification Required – параграф 4.6). Как вариант, организации могут указать себя в поле Contact, чтобы указать свое владение регистрацией.

9.6. Закрытие и отмена реестров и регистраций

Иногда возникают запросы на «закрытие» реестра для дальнейшей регистрации. В закрытых реестрах регистрация прекращается. Информация в реестре сохраняет свое действие и зарегистрированные ранее записи продолжают обновляться.

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

Конкретные записи реестра могут быть помечены как устаревшие (obsolete) и не используемые или как отмененные (deprecated), применение которых не рекомендуется.

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

10. Апелляции

Апелляции на регистрационные решения IANA можно подавать с использованием обычной процедуры апелляции IETF, описанной в параграфе 6.5 [RFC2026]. Т. е. апелляции следует направлять в IESG, а затем (при необходимости) в IAB.

11. Списки рассылки

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

12. Вопросы безопасности

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

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

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

Анализ вопросов безопасности в общем случае требуется для всех протоколов, применяющих параметры (типы данных, коды операций, ключевые слова и т. п.), документированные в протоколах IETF или зарегистрированные IANA. Обсуждение вопросов безопасности обычно включается в протокольные документы [BCP72]. Ответственность за обеспечение рассмотрения вопросов безопасности (если таковые имеются) при выделении новых значений и рецензирование такого рассмотрения ложится на IANA при рассмотрении соответствующих вопросов выделения значений.

13. Взаимодействие с IANA

Агентство IANA заменило все ссылки на RFC 5226 ссылками на этот документ.

14. Отличия от прежних версий BCP 26

14.1. 2016 – отличия этого документа от RFC 5226

Ниже перечислены существенные дополнения, внесенные в новую версию.

• Удалены ключевые слова, шаблоны и ссылка на RFC 2119. Это простой текст, а не спецификация протокола.

• Добавлен параграф 1.1. Раздел IANA Considerations предназначен для IANA.

• Добавлен параграф 1.2. Обновление информации.

• Добавлен параграф 2.1. Организация реестров.

• Добавлено обобщение опыта для выбора подходящей политики в раздел 4.

• Добавлен параграф 4.12. Использование комбинации нескольких процедур.

• Добавлен параграф 2.3. Указание контроля изменений для реестра.

• Добавлен параграф 3.4. Раннее выделение значений.

• Все общеизвестные правила перенесены в отдельные параграфы раздела 4.

• Добавлен параграф 5.4. Рецензии экспертов и жизненный цикл документа.

• Добавлен раздел 7. Ссылки на документы в реестрах IANA.

• Добавлен раздел 8. Что нужно делать в документах «bis».

• Добавлен параграф 9.5. Контактное лицо, правообладатель или владелец.

• Добавлен параграф 9.6. Закрытие и отмена реестров и регистраций.

Внесены разъяснения и иные правки:

• некоторые части текста перемещены для ясности и удобочитаемости;

• добавлены разъяснения по поводу указания реестров IANA с использованием URL;

• разъяснены различия между Unassigned и Reserved;

• в параграф 4.5. Рецензия эксперта внесены разъяснения по поводу инструкций для эксперта;

• в параграф 4.6. Требование наличия спецификации внесены разъяснения по части объявления политики;

• внесены разъяснения и незначительные правки по всему тексту.

14.2. 2008 – отличия RFC 5226 от RFC 2434

Ниже перечислены основные изменения, внесенные в RFC 5226.

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

• Многочисленные редакторские правки для удобочитаемости.

• Название процедуры IETF Consensus (согласие IETF) заменено на IETF Review (рецензия IETF) и приведены дополнительные разъяснения. Опыт показывает, что люди, увидев слова IETF Consensus (и не глядя на определение этой процедуры) делают некорректное допущение о значении их в контексте IANA Consideration.

• В список определенных правил добавлено RFC Required (требуется публикация RFC).

• Существенно более явные указания и примеры того, что «следует включать в RFC».

• Правило Specification Required (требуется спецификация) сейчас предполагает использование назначенных экспертов (Designated Expert) для оценки ясности спецификаций.

• Добавлено описание временных регистраций.

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

• Изменен текст с целью удаления каких-либо специальных путей для апелляций. Используется описанный в RFC 2026 путь апеллирования.

• Изменен текст с целью удаления каких-либо специальных путей для апелляций. Используется описанный в RFC 2026 путь апеллирования.

• Добавлен раздел об отзыве неиспользуемых значений.

• Добавлен параграф «Регистрация постфактум».

• Добавлен раздел, указывающий, что почтовые рассылки, используемые для оценки возможности выделения значений (например, назначенным экспертом), подчиняются обычным правилам IETF.

15. Литература

15.1. Нормативные документы

[RFC2026] Bradner, S., “The Internet Standards Process – Revision 3”, BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <http://www.rfc-editor.org/info/rfc2026>.

15.2. Дополнительная литература

[BCP72] Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations”, BCP 72, RFC 3552, July 2003, <http://www.rfc-editor.org/info/bcp72>.

[RFC791] Postel, J., “Internet Protocol”, STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.

[RFC1591] Postel, J., “Domain Name System Structure and Delegation”, RFC 1591, DOI 10.17487/RFC1591, March 1994, <http://www.rfc-editor.org/info/rfc1591>.

[RFC2434] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, RFC 2434, DOI 10.17487/RFC2434, October 1998, <http://www.rfc-editor.org/info/rfc2434>.

[RFC2860] Carpenter, B., Baker, F., and M. Roberts, “Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority”, RFC 2860, DOI 10.17487/RFC2860, June 2000, <http://www.rfc-editor.org/info/rfc2860>.

[RFC2939] Droms, R., “Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types”, BCP 43, RFC 2939, DOI 10.17487/RFC2939, September 2000, <http://www.rfc-editor.org/info/rfc2939>.

[RFC3228] Fenner, B., “IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)”, BCP 57, RFC 3228, DOI 10.17487/RFC3228, February 2002, <http://www.rfc-editor.org/info/rfc3228>.

[RFC3575] Aboba, B., “IANA Considerations for RADIUS (Remote Authentication Dial In User Service)”, RFC 3575, DOI 10.17487/RFC3575, July 2003, <http://www.rfc-editor.org/info/rfc3575>.

[RFC3692] Narten, T., “Assigning Experimental and Testing Numbers Considered Useful”, BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, <http://www.rfc-editor.org/info/rfc3692>.

[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., “Extensible Authentication Protocol (EAP)”, RFC 3748, DOI 10.17487/RFC3748, June 2004, <http://www.rfc-editor.org/info/rfc3748>.

[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”, BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <http://www.rfc-editor.org/info/rfc3864>.

[RFC3942] Volz, B., “Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options”, RFC 3942, DOI 10.17487/RFC3942, November 2004, <http://www.rfc-editor.org/info/rfc3942>.

[RFC3968] Camarillo, G., “The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)”, BCP 98, RFC 3968, DOI 10.17487/RFC3968, December 2004, <http://www.rfc-editor.org/info/rfc3968>.

[RFC4025] Richardson, M., “A Method for Storing IPsec Keying Material in DNS”, RFC 4025, DOI 10.17487/RFC4025, March 2005, <http://www.rfc-editor.org/info/rfc4025>.

[RFC4044] McCloghrie, K., “Fibre Channel Management MIB”, RFC 4044, DOI 10.17487/RFC4044, May 2005, <http://www.rfc-editor.org/info/rfc4044>.

[RFC4124] Le Faucheur, F., Ed., “Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering”, RFC 4124, DOI 10.17487/RFC4124, June 2005, <http://www.rfc-editor.org/info/rfc4124>.

[RFC4169] Torvinen, V., Arkko, J., and M. Naslund, “Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2”, RFC 4169, DOI 10.17487/RFC4169, November 2005, <http://www.rfc-editor.org/info/rfc4169>.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., “A Border Gateway Protocol 4 (BGP-4)”, RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.

[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, “Mobile Node Identifier Option for Mobile IPv6 (MIPv6)”, RFC 4283, DOI 10.17487/RFC4283, November 2005, <http://www.rfc-editor.org/info/rfc4283>.

[RFC4340] Kohler, E., Handley, M., and S. Floyd, “Datagram Congestion Control Protocol (DCCP)”, RFC 4340, DOI 10.17487/RFC4340, March 2006, <http://www.rfc-editor.org/info/rfc4340>.

[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., “Simple Authentication and Security Layer (SASL)”, RFC 4422, DOI 10.17487/RFC4422, June 2006, <http://www.rfc-editor.org/info/rfc4422>.

[RFC4446] Martini, L., “IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)”, BCP 116, RFC 4446, DOI 10.17487/RFC4446, April 2006, <http://www.rfc-editor.org/info/rfc4446>.

[RFC4520] Zeilenga, K., “Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)”, BCP 64, RFC 4520, DOI 10.17487/RFC4520, June 2006, <http://www.rfc-editor.org/info/rfc4520>.

[RFC4589] Schulzrinne, H. and H. Tschofenig, “Location Types Registry”, RFC 4589, DOI 10.17487/RFC4589, July 2006, <http://www.rfc-editor.org/info/rfc4589>.

[RFC4727] Fenner, B., “Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers”, RFC 4727, DOI 10.17487/RFC4727, November 2006, <http://www.rfc-editor.org/info/rfc4727>.

[RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.

[RFC5378] Bradner, S., Ed. and J. Contreras, Ed., “Rights Contributors Provide to the IETF Trust”, BCP 78, RFC 5378, DOI 10.17487/RFC5378, November 2008, <http://www.rfc-editor.org/info/rfc5378>.

[RFC5742] Alvestrand, H. and R. Housley, “IESG Procedures for Handling of Independent and IRTF Stream Submissions”, BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009, <http://www.rfc-editor.org/info/rfc5742>.

[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, “IANA Guidelines for IPv4 Multicast Address Assignments”, BCP 51, RFC 5771, DOI 10.17487/RFC5771, March 2010, <http://www.rfc-editor.org/info/rfc5771>.

[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, “The Robust Header Compression (ROHC) Framework”, RFC 5795, DOI 10.17487/RFC5795, March 2010, <http://www.rfc-editor.org/info/rfc5795>.

[RFC6014] Hoffman, P., “Cryptographic Algorithm Identifier Allocation for DNSSEC”, RFC 6014, DOI 10.17487/RFC6014, November 2010, <http://www.rfc-editor.org/info/rfc6014>.

[RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, “Media Control Channel Framework”, RFC 6230, DOI 10.17487/RFC6230, May 2011, <http://www.rfc-editor.org/info/rfc6230>.

[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, “Mobility Support in IPv6”, RFC 6275, DOI 10.17487/RFC6275, July 2011, <http://www.rfc-editor.org/info/rfc6275>.

[RFC6698] Hoffman, P. and J. Schlyter, “The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA”, RFC 6698, DOI 10.17487/RFC6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>.

[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, “Design Considerations for Protocol Extensions”, RFC 6709, DOI 10.17487/RFC6709, September 2012, <http://www.rfc-editor.org/info/rfc6709>.

[RFC6838] Freed, N., Klensin, J., and T. Hansen, “Media Type Specifications and Registration Procedures”, BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.

[RFC6895] Eastlake 3rd, D., “Domain Name System (DNS) IANA Considerations”, BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <http://www.rfc-editor.org/info/rfc6895>.

[RFC6994] Touch, J., “Shared Use of Experimental TCP Options”, RFC 6994, DOI 10.17487/RFC6994, August 2013, <http://www.rfc-editor.org/info/rfc6994>.

[RFC7120] Cotton, M., “Early IANA Allocation of Standards Track Code Points”, BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <http://www.rfc-editor.org/info/rfc7120>.

[RFC7564] Saint-Andre, P. and M. Blanchet, “PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols”, RFC 7564, DOI 10.17487/RFC7564, May 2015, <http://www.rfc-editor.org/info/rfc7564>.

[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, “Guidelines and Registration Procedures for URI Schemes”, BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <http://www.rfc-editor.org/info/rfc7595>.

[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, “North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP”, RFC 7752, DOI 10.17487/RFC7752, March 2016, <http://www.rfc-editor.org/info/rfc7752>.

[RFC8141] Saint-Andre, P. and J. Klensin, “Uniform Resource Names (URNs)”, RFC 8141, DOI 10.17487/RFC8141, April 2017, <http://www.rfc-editor.org/info/rfc8141>.

Благодарности за этот документ (2017)

Thomas Narten и Harald Tveit Alvestrand редактировали две первых версии этого документа (RFC 2434 и RFC 5226), а Thomas продолжил эту работу и с данной версией. Значительная часть текста RFC 5226 сохранена в этом издании.

Спасибо Amanda Baber и Pearl Liang за их многочисленные рецензии и предложения, сделавшие документ лучше.

Для документа были полезны внимательные обзоры и комментарии многих людей, включая Benoit Claise, Alissa Cooper, Adrian Farrel, Stephen Farrell, Tony Hansen, John Klensin, Kathleen Moriarty, Mark Nottingham, Pete Resnick и Joe Touch.

Отдельная благодарность Mark Nottingham за реорганизацию части текста в плане удобочитаемости, Tony Hansen за присмотр, а также Brian Haberman и Terry Manderson за спонсорство.

Благодарности из второго издания (2008)

Ниже приведен раздел благодарностей из RFC 5226.

В этот документ внесли существенный вклад отклики Jari Arkko, Marcelo Bagnulo Braun, Brian Carpenter, Michelle Cotton, Spencer Dawkins, Barbara Denny, Miguel Garcia, Paul Hoffman, Russ Housley, John Klensin, Allison Mankin, Blake Ramsdell, Mark Townsley, Magnus Westerlund, Bert Wijnen.

Благодарности из первого издания (1998)

Ниже приведен раздел благодарностей из RFC 2434.

Jon Postel и Joyce K. Reynolds подробно объяснили, что требуется IANA для эффективного управления распределением значений и терпеливо комментировали многочисленные варианты этого документа. Brian Carpenter внес полезные комментарии к ранним версиям документа. Один абзац раздела «Вопросы безопасности» был заимствован из RFC 2048¹².

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

Michelle Cotton

PTI, an affiliate of ICANN

12025 Waterfront Drive, Suite 300

Los Angeles, CA 90094-2536

United States of America

Phone: +1-424-254-5300

Email: michelle.cotton@iana.org

URI: https://www.iana.org/

Barry Leiba

Huawei Technologies

Phone: +1 646 827 0648

Email: barryleiba@computer.org

URI: http://internetmessagingtechnology.org/

Thomas Narten

IBM Corporation

3039 Cornwallis Ave., PO Box 12195 – BRQA/502

Research Triangle Park, NC 27709-2195

United States of America

Phone: +1 919 254 7798

Email: narten@us.ibm.com

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

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

nmalykh@gmail.com