Перевод RFC 4020

На главную

Network Working Group Request for Comments: 4020 BCP: 100 Category: Best Current Practice

K. Kompella

Juniper Networks

A. Zinin

Alcatel

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

Early IANA Allocation of Standards Track Code Points

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

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

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

Тезисы

В этом документе описано предварительное выделение кодов 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]), И вносит поправки, связанные с возможностью предварительного распределения. Такая возможность

¹Далее для краткости будем называть их просто кодами. Прим. перев.

²Internet Assigned Number Authority

³Обслуживание в порядке поступления.

⁴Просмотр эксперта

⁵Одобрение IESG

⁶Согласие IETF

⁷Стандартизация

⁸Routing Area

rfc.com.ru

Перевод RFC 4020

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

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

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

a) Коды должны относиться к пространству, обозначенному как "Standards Action" и имеется одобрение IESG на предварительное распределение.

b) Формат, семантика, обработка и другие правила, относящиеся к работе с протокольными элементами, определяемыми кодами (далее, называемые "спецификациями"), должны быть аккуратно описаны в документе Internet draft, предложенном в качестве проекта стандарта (Standards Track).

c) Спецификации этих кодов должны быть стабильными, т. е., при их изменении реализации, основанные на старых и новых спецификациях, должны быть полностью интероперабельны.

d) Имеется достаточные интерес в предварительной (до 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 о сроках окончательного прекращения использования таких кодов (чтобы обеспечить возможность их использования для других целей).

⁹Area Director(s) ¹⁰Согласование с IANA.

rfc.com.ru 2 rfc.com.ru

Перевод RFC 4020

В частности, 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

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

BiLiM Systems nmalykh@bilim.com тел. (812) 4490770

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

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

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

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

rfc.com.ru 3 rfc.com.ru


На главную



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

February 2005 Предварительное распределение IANA кодов для проектов стандартов Early IANA Allocation of Standards Track Code Points *Статус документа* Этот документ относится к категории обмена опытом (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]), И вносит поправки, связанные с возможностью предварительного распределения. Такая возможность

¹Далее для краткости будем называть их просто кодами. Прим. перев. ²Internet Assigned Number Authority ³Обслуживание в порядке поступления. ⁴Просмотр эксперта ⁵Одобрение IESG ⁶Согласие IETF ⁷Стандартизация ⁸Routing Area rfc.com.ru		rfc.com.ru



	Перевод RFC 4020

	В частности, 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

	Перевод на русский язык Николай Малых BiLiM Systems nmalykh@bilim.com тел. (812) 4490770 *Полное заявление авторских прав* Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

	*Интеллектуальная собственность* The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. *Подтверждение* Финансирование функций RFC Editor обеспечено Internet Society. rfc.com.ru 3 rfc.com.ru