Рабочая группа по сетям R. Bush
Запрос комментариев: 3967 IIJ
BCP: 97 T. Narten
Категория: Лучшая современная практика (Best Current Practice) IBM Corporation
Декабрь 2004
Разъяснение случаев, когда документы категории Standards Track
могут нормативно ссылаться на документы более низкого уровня
Статус настоящего меморандума
Этот документ устанавливает Internet Best Current Practices для
интернет-сообщества и запрашивает обсуждение и предложения по
улучшениям. Распространение настоящего меморандума не ограничено.
Уведомление об авторских правах
Copyright (C) The Internet Society (2004).
Аннотация
Процедуры IETF в целом требуют, чтобы RFC категории Standards Track не
содержал нормативной ссылки на другой документ категории Standards Track
с более низким уровнем зрелости либо на спецификацию, не относящуюся к
категории Standards Track (кроме спецификаций других органов по
стандартизации). Например, документ категории Standards Track не может
содержать нормативную ссылку на информационный RFC. Исключения из этого
правила иногда необходимы, поскольку IETF использует информационные RFC
для описания стандартов, не относящихся к IETF, или определённых IETF
режимов использования таких стандартов. Настоящий документ разъясняет и
обновляет процедуру, применяемую в этих обстоятельствах.
1. Введение
Раздел 4.2.4 The Internet Standards Process [RFC2026] устанавливает
следующее:
Спецификации категории Standards Track обычно не должны зависеть от
других спецификаций категории Standards Track, находящихся на более
низком уровне зрелости, или от спецификаций, не относящихся к категории
Standards Track, кроме спецификаций других органов по стандартизации,
на которые имеются ссылки.
Одна из целей состоит в том, чтобы избежать создания впечатления, будто
стандарт более зрелый, чем он есть на самом деле.
Bush & Narten Лучшая современная практика (Best Current Practice) [Страница 1]
Следует также отметить, что документы Best Current Practice [RFC1818], как
правило, считались подобными документам категории Standards Track с точки
зрения того, на что они могут ссылаться. Например, нормативная ссылка на
экспериментальный RFC считалась ненадлежащей ссылкой согласно [RFC2026].
1.1. Нормативные ссылки
В RFC ссылки на другие документы относятся к двум общим категориям:
«нормативные» и «информационные». В широком смысле нормативная ссылка
определяет документ, который необходимо прочитать, чтобы полностью понять
или реализовать предмет новой RFC, либо содержимое которого фактически
является частью новой RFC, поскольку его отсутствие оставило бы новую RFC
неполностью специфицированной. Информационная ссылка не является
нормативной; напротив, она предоставляет только дополнительные фоновые
сведения.
На практике оказалось сложно дать точное и строгое определение того, что
является (и не является) нормативной ссылкой, поскольку детали и
последствия могут быть тонкими. Более того, необходимость нормативного
характера ссылки может зависеть от контекста, в котором конкретный RFC
вообще публикуется. Например, в контексте стандарта IETF важно, чтобы все
зависимые компоненты были чётко определены и доступны в архивной форме,
чтобы не возникало разногласий о том, что составляет стандарт. Для других
документов это не всегда так.
В оставшейся части этого раздела приводятся указания о том, что может (и
что может не) считаться нормативным в контексте процесса стандартизации
IETF.
В IETF основополагающим предположением является то, что разработчики
реализаций должны ясно понимать, что им необходимо реализовать для полного
соответствия стандарту и для способности взаимодействовать с другими
реализациями этого стандарта. Что касается документов, на которые имеются
ссылки, нормативным будет любой документ, содержащий ключевую информацию,
необходимую разработчику реализации. Например, если для полной реализации
спецификации необходимо понимать формат пакета, определённый в другом
документе, ссылка на этот формат будет нормативной. Аналогично, если дана
ссылка на требуемый алгоритм, эта ссылка будет нормативной.
Несколько конкретных примеров:
- Если протокол опирается на IPsec для обеспечения безопасности, нельзя
полностью реализовать протокол, пока не доступна спецификация IPsec;
следовательно, ссылка будет нормативной.
Bush & Narten Лучшая современная практика (Best Current Practice) [Страница 2]
Спецификация, на которую дана ссылка, вероятно, будет содержать
подробности о конкретных требованиях к управлению ключами, о том, какие
преобразования требуются и какие являются необязательными, и т. д.
- В документах MIB предложение IMPORTS по определению является
нормативной ссылкой.
- Когда даётся ссылка на пример, такая ссылка не обязательно должна быть
нормативной. Например, текст наподобие «алгоритм, такой как
определённый в [RFCxxxx], был бы приемлемым» указывает на
информационную ссылку, поскольку этот цитируемый алгоритм — лишь один
из нескольких возможных алгоритмов, которые могли бы использоваться.
2. Необходимость нисходящих ссылок
Существует ряд обстоятельств, в которых документу IETF может потребоваться
дать нормативную ссылку на документ с более низким уровнем зрелости, но
такая ссылка противоречит разделу 4.2.4 [RFC2026]. Например:
o Документу категории Standards Track может потребоваться сослаться на
протокол или алгоритм, разработанный внешним органом, но изменённый,
адаптированный или профилированный информационным RFC IETF, например
MD5 [RFC1321] и HMAC [RFC2104]. Обратите внимание, что это не отменяет
обязанность IETF обеспечить, чтобы спецификация действительно была
достаточно ясной для создания взаимодействующих реализаций.
o Документу стандарта может потребоваться сослаться на проприетарный
протокол, а IETF обычно документирует проприетарные протоколы с помощью
информационных RFC.
o Документу о миграции или сосуществовании может потребоваться определить
механизм категории Standards Track для миграции с исторического
протокола, проприетарного протокола или, возможно, протокола, не
относящегося к категории Standards Track, и/или для сосуществования с
историческим протоколом, проприетарным протоколом или, возможно,
протоколом, не относящимся к категории Standards Track.
o Имеются исключительные процедурные или юридические причины, вынуждающие
цель нормативной ссылки быть информационным или историческим RFC либо
находиться на более низком уровне стандартов, чем ссылающийся документ.
o Документ BCP может хотеть описать лучшие современные практики для
экспериментальных или информационных спецификаций.
Bush & Narten Лучшая современная практика (Best Current Practice) [Страница 3]
3. Применяемая процедура
Для документов категории Standards Track или BCP, которым требуется
нормативная ссылка на документы с более низким уровнем зрелости, будет
проведена обычная процедура IETF Last Call, причём необходимость
нисходящей ссылки будет явно задокументирована в самом Last Call. Любые
комментарии сообщества об уместности нисходящих ссылок будут рассмотрены
IESG в рамках его обсуждений.
После того как конкретная нисходящая ссылка на определённый документ была
принята сообществом (например, была упомянута в нескольких Last Call),
Area Director может отказаться от последующих уведомлений в Last Call о
нисходящих ссылках на него. Это должно происходить только тогда, когда
имеются ссылки на один и тот же документ (и версию) и когда AD считает,
что использование документа является признанной частью понимания
сообществом соответствующей технической области. Например, использование
MD5 [RFC1321] и HMAC [RFC2104] хорошо известно криптографам.
Эта процедура не должна использоваться, если надлежащим шагом является
перевод документа, на который даётся ссылка, в соответствующую категорию.
Она не предназначена как простой способ обойти обычный процесс. Напротив,
процедура предназначена для рассмотрения конкретных случаев, когда
отнесение определённых документов к требуемой категории проблематично и
вряд ли когда-либо произойдёт.
4. Соображения безопасности
Неизвестно, чтобы настоящий документ создавал какие-либо новые уязвимости
для Интернета. С другой стороны, неуместное или чрезмерное использование
процесса могло бы рассматриваться как атака понижения уровня качества
стандартов IETF или, что хуже, как атака на строгую проверку аспектов
безопасности стандартов.
5. Выражение признательности
Настоящий документ является результатом обсуждения в IESG, при особом
вкладе Harald Alvestrand, Steve Bellovin, Scott Bradner, Ned Freed,
Allison Mankin, Jeff Schiller и Bert Wijnen.
Bush & Narten Лучшая современная практика (Best Current Practice) [Страница 4]
6. Ссылки
6.1. Нормативные ссылки
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
6.2. Информационные ссылки
[RFC1818] Postel, J., Li, T., and Y. Rekhter, "Best Current
Practices", BCP 1, RFC 1818, August 1995.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
7. Адреса авторов
Randy Bush
IIJ
5147 Crystal Springs
Bainbridge Island, WA 98110
US
Phone: +1 206 780 0431
EMail: randy@psg.com
URI: http://psg.com/~randy/
Thomas Narten
IBM Corporation
P.O. Box 12195
Research Triangle Park, NC 27709-2195
US
Phone: +1 919 254 7798
EMail: narten@us.ibm.com
Bush & Narten Лучшая современная практика (Best Current Practice) [Страница 5]
8. Полное заявление об авторских правах
Copyright (C) The Internet Society (2004).
Настоящий документ регулируется правами, лицензиями и ограничениями,
содержащимися в BCP 78 и на www.rfc-editor.org, и, кроме предусмотренного
в них, авторы сохраняют все свои права.
Настоящий документ и содержащаяся в нём информация предоставляются на
условиях «КАК ЕСТЬ», И УЧАСТНИК, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА ПРЕДСТАВЛЯЕТ
ИЛИ КОТОРАЯ СПОНСИРУЕТ ЕГО/ЕЁ (ЕСЛИ ТАКОВАЯ ИМЕЕТСЯ), INTERNET SOCIETY И
INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ЯВНЫХ ИЛИ
ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ, ВКЛЮЧАЯ, В ЧАСТНОСТИ, ЛЮБЫЕ ГАРАНТИИ ТОГО, ЧТО
ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ,
ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ЛИБО ПРИГОДНОСТИ
ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Интеллектуальная собственность
IETF не занимает позиции относительно действительности или объёма каких-либо
прав интеллектуальной собственности либо иных прав, которые могут быть
заявлены как относящиеся к реализации или использованию технологии,
описанной в настоящем документе, или относительно того, может или не может
быть доступна какая-либо лицензия в рамках таких прав; также IETF не
заявляет, что приложила какие-либо независимые усилия для выявления любых
таких прав. Информацию о процедурах ISOC в отношении прав в документах
ISOC можно найти в BCP 78 и BCP 79.
Копии раскрытий IPR, направленных в Секретариат IETF, и любых обязательств
предоставить лицензии либо результат попытки получить общую лицензию или
разрешение на использование таких проприетарных прав разработчиками
реализаций или пользователями данной спецификации можно получить из
онлайнового репозитория IPR IETF по адресу
http://www.ietf.org/ipr.
IETF приглашает любую заинтересованную сторону довести до её сведения любые
авторские права, патенты или заявки на патенты либо иные проприетарные
права, которые могут охватывать технологию, которая может потребоваться
для реализации настоящего стандарта. Просьба направлять информацию в IETF
по адресу ietf-ipr@ietf.org.
Выражение признательности
Финансирование функции RFC Editor в настоящее время обеспечивается
Internet Society.
Bush & Narten Лучшая современная практика (Best Current Practice) [Страница 6]