Network Working Group                                      T. Narten
Request for Comments: 2434                                       IBM
BCP: 26                                                H. Alvestrand
Category: Best Current Practice                              Maxware
                                                        October 1998

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

Guidelines for Writing an IANA Considerations Section in RFCs

PDF

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

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

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

Copyright (C) The Internet Society (1998). All Rights Reserved.

Аннотация

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

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

1. Введение

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

В этом документе мы будем называть наборы возможных значений таких полей пространством имен (name space); реальное содержимое этого пространства может включать имена, числа или иные типы значений. Выделенные конкретные значения в пространстве имен называется присвоенными номерами или присвоенными значениями (assigned number или assigned value). Каждое присвоение значения в пространстве имен называется регистрацией.

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

Не все пространства имен требуют централизованного администрирования. В некоторых случаях полномочия по управлению пространством имен могут быть переданы так, чтобы дальнейшее выделение имен происходило независимо без дополнительной (централизованной) координации. Например, в системе доменных имен (DNS³) IANA имеет дело только с распределением имен доменов верхнего уровня, а все субдомены управляются организациями, которым переданы соответствующие полномочия. Другим примером могут служить идентификаторы объектов (OID), определенные ITU, полномочия по выделению которых также переданы другим организациям [ASSIGNED]. Когда полномочия по управлению пространством имен передаются другим организациям, IANA занимается только вопросами распределения на верхнем уровне.

В этом документе ключевые слова необходимо (MUST), следует (SHOULD), возможно (MAY) интерпретируются в соответствии с RFC 2119 [KEYWORDS]. В данном случае спецификация требований, определенная в RFC 2119, относится к обработке протоколов, которые подаются на стандартизацию IETF.

2. Рассматриваемые вопросы

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

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

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

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

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

В некоторых случаях публикация RFC для выделения значений является излишней. Тем не менее, в общем случае будет полезно (а иногда необходимо) обсудить предлагаемые дополнения в почтовой конференции (mailing list), выделенной для этих целей (например, ietf-types@iana.org для типов media), или более общей почтовой конференции (например, в действующей или бывшей рабочей группе IETF). Такие почтовые конференции обеспечивают для новых регистраций возможность публичного обзора до реального выделения значений и позволяет заинтересованным лицам понять, что в действительности следует регистрировать.

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

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

Решения экспертов могут быть опротестованы с использованием обычного процесса апелляции, описанного в параграфе 6.5 документа [IETF-PROCESS]. Поскольку экспертов назначает IESG, они могут быть отозваны IESG.

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

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

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

Примеры: Специфические для сайта опции DHCP [DHCP], имеющие значение только для данного сайта. Строки “X-foo:” в заголовках почтовых сообщений.

Hierarchical allocation (иерархическое распределение)

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

Примеры: имена DNS, идентификаторы объектов (Object Identifier).

First Come First Served (распределение в порядке поступления запросов)

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

Примеры: выделяемые производителями типы MIME [MIME-REG], номера портов TCP и UDP.

Expert Review (рецензия эксперта)

Требуется одобрение назначенного эксперта (Designated Expert).

Specification Required (требуется спецификация)

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

Примеры: SCSP [SCSP]

IESG Approval (одобрение IESG)

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

IETF Consensus (согласие IETF)

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

Примеры: Расширения SMTP [SMTP-EXT], Идентификаторы BGP Subsequent Address Family [BGP4-EXT].

Standards Action (стандартизация)

Значения выделяются только для RFC со статусом Standards Track, одобренных IESG.

Примеры: Типы MIME верхнего уровня [MIME-REG]

Следует отметить, что зачастую пространство имен имеет смысл разделить на несколько категорий с независимым обслуживанием каждой категории. Например, пространство опций DHCP [DHCP] разделено на две части. Номера опций в диапазоне 1-127 являются уникальными в глобальном масштабе и распределяются в соответствии с процедурой Specification Required, описанной выше, а опции из диапазона 128-254 являются специфическими для сайта, т. е., используемыми локально (Local Use⁴). Деление пространства имен позволяет распределять имена из ряда пространств с минимальными усилиями, сохраняя, в то же время, резервное пространство на будущее.

3. Поддержка регистрации

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

• позволяет автору обновить регистрацию с теми же условиями, как при новой регистрации;

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

4. Что включать в документ

В предыдущем разделе рассмотрены некоторые вопросы, которые следует рассмотреть при формулировке правил распределения значений общего пользования (well-known number) и других протокольных констант. Задачей рабочей группы и/или автора документа является документальная формулировка соответствующих правил. В некоторых случаях может потребоваться включение раздела «Согласование с IANA» (IANA Considerations). В частности, документы, создающие пространство имен (или меняющие определение существующего пространства), для которого предполагается участие IANA в поддержке (например, организация репозитория для хранения выделенных значений), должны описывать процессы распределения имен в будущем. В соответствующем разделе документа должно быть четко указано:

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

• Если запрос требует обсуждения (рецензирования) в конкретном открытом списке рассылки (например, ietf-types@iana.org для типов сред), следует указать адрес списка рассылки. Отметим, что использование процедуры Designated Expert также должно быть указано.
• Если предполагается, что IANA может выделять значения без привлечения внешних рецензентов, должно быть дано руководство обеспечивающее минимизацию субъективизма при распределении.

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

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

Следуя правилам, описанным в [IANA-CONSIDERATIONS], значения из диапазона 0-63 распределяются в порядке поступления запросов (First Come First Served), значения из диапазона 64-240 распределяются по согласованию с IETF (IETF Consensus), а значения в диапазоне 241-255 резервируются для приватного использования (Private Use).

В качестве примеров хорошо подготовленных рекомендаций для IANA по вопросам распределения значений можно указать документы [MIME-REG, MIME-LANG].

5. Применимость к прошлым и будущим документам RFC

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

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

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

Данные по регистрации и обновлению зарегистрированного пространства требуют аутентификации.

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

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

7. Благодарности

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

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

[ASSIGNED] Reynolds, J., and J. Postel, “Assigned Numbers”, STD 2, RFC 1700⁵, October 1994. См. также  http://www.iana.org/numbers.html

[BGP4-EXT] Bates. T., Chandra, R., Katz, D. and Y. Rekhter, “Multiprotocol Extensions for BGP-4”, RFC 2283, February 1998.

[DHCP-OPTIONS] Alexander, S. and R. Droms, “DHCP Options and BOOTP Vendor Extensions”, RFC 2132, March 1997.

[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 2434, October 1998.

[IETF-PROCESS] Bradner, S., “The Internet Standards Process — Revision 3”, BCP 9, RFC 2026⁸, October 1996.

[IP] Postel, J., “Internet Protocol”, STD 5, RFC 791, September 1981.

[IPSEC] Atkinson, R., “Security Architecture for the Internet Protocol”, RFC 1825⁹, August 1995.

[KEYWORDS] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[MIME-LANG] Freed, N. and K. Moore, “MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations”, RFC 2184, August 1997.

[MIME-REG] Freed, N., Klensin, J. and J. Postel, “Multipurpose Internet Mail Extension (MIME) Part Four: Registration Procedures”, RFC 2048, November 1996.

[SCSP] Luciani, J., Armitage, G. and J. Halpern, “Server Cache Synchronization Protocol (SCSP)”, RFC 2334, April 1998.

[SMTP-EXT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, “SMTP Service Extensions”, RFC 1869, November 1995.

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

Thomas Narten

IBM Corporation

3039 Cornwallis Ave.

PO Box 12195 – BRQA/502

Research Triangle Park, NC 27709-2195

Phone: 919-254-7798

EMail: narten@raleigh.ibm.com

 

Harald Tveit Alvestrand

Maxware

Pirsenteret

N-7005 Trondheim

Norway

Phone: +47 73 54 57 97

EMail: Harald@Alvestrand.no

---

 

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

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

nmalykh@gmail.com

10. Полное заявление авторских прав

Copyright (C) The Internet Society (1998). Все права защищены.

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

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

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

---

1Документ заменен RFC 5226. Прим. перев.