RFC 4020 Early IANA Allocation of Standards Track Code Points

Network Working Group                                    K. Kompella
Request for Comments: 4020                          Juniper Networks
BCP: 100                                                    A. Zinin
Category: Best Current Practice                              Alcatel
                                                       February 2005

Предварительное распределение IANA кодов для проектов стандартов

Early IANA Allocation of Standards Track Code Points

PDF

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

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

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

Copyright (C) The Internet Society (2005).

Аннотация

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

1. Введение

В RFC, содержащих проекты стандартов (Standards Track RFC), зачастую требуется получить коды или идентификаторы (code points¹) для некоторых объектов, сообщений или других элементов протокола так, чтобы обеспечивалась интероперабельность реализаций. Многие из таких кодов хранятся в реестрах, обслуживаемых агентством IANA². Некоторые правила распределения IANA описаны в документе RFC 2434 [2434]. Часть этих правил (например, First Come First Served³ или Expert Review⁴) не требует формальных действий IETF для того, чтобы агентство IANA могло произвести нужное распределение. Однако в ситуациях, когда выделяемые коды относятся к числу дефицитных ресурсов и/или IETF желает сохранить за собой контроль над протоколом, могут использоваться правила типа IESG Approval⁵, IETF Consensus⁶, Standards Action⁷. Правило Standards Action вызывает проблемы в тех случаях, когда желательно или требуется наличие реализации и/или практического использования для выполнения процедур стандартизации.

Для решения этой проблемы предварительные (pre-RFC) реализации иногда просто выбирают некоторые коды, которые представляются неиспользуемыми. Однако впоследствии IANA может выделить другие коды. Достаточно часто такие предварительные реализации развертываются на практике. Это создает потенциальные проблемы интероперабельности между предварительными стандартными (более поздними0 реализациями, как описано ниже:

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

Это ведет к невыполнению основной задачи стандартизации – обеспечению интероперабельности реализаций.

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

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

Данный документ относится только к распределению кодов из пространств, для которых требуется стандартизация (правила “Standards Action” [2434]), И вносит поправки, связанные с возможностью предварительного распределения. Такая возможность должна быть предоставлено IESG и кодовые пространства с возможностью предварительного распределения должны быть соответствующим образом помечены в реестре IANA.

2. Условия предварительно распределения

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

1. Коды должны относиться к пространству, обозначенному как Standards Action и имеется одобрение IESG на предварительное распределение.
2. Формат, семантика, обработка и другие правила, относящиеся к работе с протокольными элементами, определяемыми кодами (далее, называемые спецификациями), должны быть аккуратно описаны в документе Internet draft, предложенном в качестве проекта стандарта (Standards Track).
3. Спецификации этих кодов должны быть стабильными, т. е., при их изменении реализации, основанные на старых и новых спецификациях, должны быть полностью совместимы.
4. Имеется достаточные интерес в предварительной (до RFC) реализации и развертывании.

При невыполнении условия (a) или (b) описываемый в этом документе процесс неприменим.

3. Процесс предварительного распределения

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

Описанные ниже процессы предполагают, что рассматриваемый документ является результатом рабочей группы IETF. Если это не так, слова “руководитель группы” (WG chairs) следует заменить на слова “руководитель направления” (shepherding Area Director).

3.1. Запрос

Процесс запроса и получения предварительно выделяемых кодов состоит из нескольких этапов.

1. Авторы (редакторы) документа подают запрос на предварительное распределение руководителям рабочей группы, указывая для каких кодов требуется предварительное распределение и в какие документы следует включить эти коды.
2. Руководители группы проверяют выполнение условий предварительного распределения, приведенных в главе 2 (в частности, условий c и d).
3. Руководители группы проверяют наличие согласия между членами группы по вопросу предварительного выделения кодов.
4. При выполнении предыдущих условий и одобрении директора(ов) направления⁹ руководители группы запрашивают в IANA предварительное распределение кодов.
5. IANA выделяет коды из соответствующего реестра, помечая это выделение как временное (temporary), сроком на один год с момента выделения. Дату выделения кодов следует вносить в реестр и делать публично доступной.

Отметим, что в Internet Draft не следует включать конкретные значения кодов, пока они формально не будут выделены IANA.

3.2. Контроль

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

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

Если документ доходит до стадии нормального распределения кодов через IANA, на авторов и руководство группы ложиться ответственность за напоминание IANA о том, что имело место предварительное распределение кодов и эти коды будут перечислены в главе IANA Considerations¹⁰ окончательного RFC. Окончательное выделение в таких случаях сводится к удалению пометки “temporary” из соответствующих реестров.

3.3. Завершение срока

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

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

Если контрольный запрос не был сделан или документ не прошел процедуру стандартизации, руководство группы отвечает за информирование IANA о том, что выделенные коды должны быть помечены как “отозванные” (deprecated) и не выделялись окончательно. Руководство группы также отвечает за информирование IANA о сроках окончательного прекращения использования таких кодов (чтобы обеспечить возможность их использования для других целей).

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

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

4. Согласование с IANA

Этот документ определяет процедуры предварительного выделения кодов в реестрах, для которых требуется стандартизация (Standards Action) и, следовательно, оказывает прямое влияние на функции IANA.

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

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

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

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

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

Большое спасибо Bert Wijnen, Adrian Farrel и Bill Fenner за их помощь.

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

Kireeti Kompella

Juniper Networks

1194 N. Mathilda Ave

Sunnyvale, CA 94089 USA

EMail: kireeti@juniper.net

Alex Zinin

Alcatel

701 E Middlefield Rd

Mountain View, CA 94043

EMail: zinin@psg.com

---

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

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

nmalykh@protokols.ru

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

Copyright (C) The Internet Society (2005).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

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

Интеллектуальная собственность

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.