RFC 5226 Guidelines for Writing an IANA Considerations Section in RFCs

Network Working Group                                      T. Narten
Request for Comments: 5226                                       IBM
BCP: 26                                                H. Alvestrand
Obsoletes: 2434                                               Google
Category: Best Current Practice                             May 2008

 

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

Guidelines for Writing an IANA Considerations Section in RFCs

PDF

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

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

Аннотация

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

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

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

1. Введение

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

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

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

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

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

2. Зачем может потребоваться управление пространствами имен

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

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

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

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

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

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

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

3.1. Мотивация для экспертов

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

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

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

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

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

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

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

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

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

В параграфе 5.2 более подробно рассматриваются вопросы, связанные со спорами и апелляциями.

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

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

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

Поскольку экспертов назначает IESG, они могут быть отозваны IESG.

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

За восемь лет с момента публикации и вступления в силу RFC 2434 накопился рад наблюдений:

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

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

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

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

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

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

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

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

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

4. Создание реестра

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

После создания реестра IANA фиксирует все выделенные значения. Ниже приведены возможные значения статуса для отдельных выделенных значений (или диапазонов).

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

Только для приватного использования (без распределения), как описано в параграфе 4.1.

Experimental (для экспериментов)

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

Unassigned (не распределено)

Не выделено и доступно для распределения в соответствии с документированными процедурами.

Reserved (резерв)

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

4.1. Определения общеизвестных правил IANA

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

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

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

Примеры: специфические для сайта опции DHCP [DHCP-IANA], реестр Fibre Channel Port Type [RFC4044], типы обмена в заголовках IKEv2 [RFC4306].

Experimental Use (экспериментальное использование)

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

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

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

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

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

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

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

Примеры: имена механизмов SASL [RFC4422], имена механизмов LDAP, синтаксис LDAP Syntax [RFC4520].

Expert Review (Designated Expert) – рецензия экспертов (назначенный эксперт)

Требуется одобрение назначенного эксперта. Требуемую документацию и критерии рецензирования для назначенного эксперта следует задавать при создании реестра (см., например, разделы 6 и 7.2 в [RFC3748]).

Примеры: типы методов EAP [RFC3748], версии алгоритмов HTTP Digest AKA [RFC4169], схемы URI [RFC4395], типы расположения GEOPRIV [RFC4589].

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

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

Примеры: идентификаторы моделей ограничения полосы TE с поддержкой Diffserv [RFC4124], идентификаторы TLS ClientCertificateType [RFC4346], идентификаторы профилей ROHC [RFC4995].

RFC Required (требуется RFC)

Достаточно публикации RFC (с подачи IETF или RFC Editor Independent [RFC3932]). Если не указано иное, достаточно RFC любого типа (например, Informational, Experimental, Standards Track и т. д.).

IETF Review (рецензирование IETF)

(В [IANA-CONSIDERATIONS] эта процедура называлась IETF Consensus). Новые значения выделяются только через RFC, прошедшие через IESG, как AD-Sponsored или IETF WG [RFC3932] [RFC3978]. Предполагается, что документ и предложенное выделение значений рассмотрено в IESG и соответствующих рабочих группах IETF (или экспертами, если нужных групп уже нет), чтобы гарантировать отсутствие негативного влияния на совместимость, а также неподобающего расширения или нарушения работы протоколов IETF.

Для обеспечения надлежащего рассмотрения сообществом такие документы проходят через IESG, как AD-sponsored (или WG) с использованием процедуры IETF Last Call.

Примеры: типы алгоритмов IPSECKEY [RFC4025], значения Accounting-Auth-Method AVP в протоколе DIAMETER [RFC4005], расширения TLS Handshake Hello [RFC4366].

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

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

Примеры: типы сообщений BGP [RFC4271], типы опций Mobile Node Identifier [RFC4283], типы пакетов DCCP [RFC4340].

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

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

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

Ниже приведены рекомендации, предлагаемые для оценки запросов при использовании процедуры IESG Approval:

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

• до удовлетворения запроса следует провести консультации с сообществом (через запрос комментариев – call for comments) с целью получения максимально полной информации о запросе.

Примеры: распределение групповых адресов IPv4 [RFC3171], значения типов и кодов IPv4 IGMP [RFC3228], значения типов и опций заголовков Mobile IPv6 Mobility [RFC3775].

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

Примеры: LDAP [RFC4520], PWE3 [RFC4446].

4.2. Что нужно включать в документы для создания реестра

В предшествующих параграфах был отмечен ряд вопросов, которые следует принимать во внимание при формулировке правил распределения значений из пространства имен. Формулировка политики и подготовка соответствующего документа являются задачами рабочей группы и/или автора документа. Почти для всех случаев подходит явное включение в документ раздела «Согласование с IANA» (IANA Considerations). В последующих разделах даны определения того, что требуется включить для разных типов действий IANA.

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

1. Имя реестра (субреестра), который будет создаваться и/или поддерживаться. Имя будет указываться на web-странице IANA и в будущих документах, которые будут запрашивать выделения из этого пространства. Следует указывать полное имя реестра и его сокращение (если оно имеется). Желательно, чтобы имя реестра не порождало путаницы с именами других реестров. При создании субреестров следует четко указать имя родительского реестра. При указании существующих реестров полезно привести URL с точным указанием на реестр. Однако все такие URL будут удаляться из RFC перед его публикацией. Например, документ может содержать фразу: «TO BE REMOVED: This registration should take place at the following location: http://www.iana.org/assignments/foobar-registry⁵».

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

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

   Если запрос следует обсудить также в конкретной почтовой конференции (например, ietf-types@iana.org для типов media), для которой следует указать почтовый адрес. Отметим однако, что при указании списка рассылки должно также указываться требование назначения эксперта (см. раздел 3).

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

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

5. Исходное распределение и резервирование. Следует представить четкие инструкции по идентификации выделенных исходно значений или регистраций. В дополнение к этому следует четко указать все резервируемые диапазоны (Private Use, Reserved, Unassigned и т. п.).

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

Например, документ может включать что-то похожее на приведенный ниже пример.

 

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

 

Данный документ определяет новую опцию DHCP, названную FooBar (см. раздел y) в выделением значения TBD1 из пространства DHCP Option space [будет удалено перед публикацией: http://www.iana.org/assignments/bootp-dhcp-parameters] [DHCP-OPTIONS] [DHCP-IANA].

 

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

 

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

Примеры документов с подробными рекомендациями для IANA включают [RFC2929], [RFC3575], [RFC3968] и [RFC4520].

4.3. Обновление рекомендаций для IANA в существующих реестрах

Обновление процесса регистрации для существующего (т. е. созданного ранее) пространства имен (созданного явно или неявно) выполняется по процедурам, аналогичным тем, которые использовались при создании пространства имен. Т. е. разрабатываются документы со ссылкой на существующее пространство имен, обеспечивающие подробные рекомендации для распределения значений в каждом пространстве имен. Такие документы обычно относятся к категории BCP⁷ [IETF-PROCESS].

Примерами документов с обновлением рекомендаций по управлению существующими пространствами имен могут служить [RFC2929], [RFC3228] и [RFC3575].

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

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

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

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

  Примечание 1: Нет необходимости указывать, что используется политика распределения, заданная в приведенной ссылке.

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

  Например, документ может содержать фразу «TO BE REMOVED: This registration should take place at the following location: http://www.iana.org/assignments/foobar-registry⁸».

• Каждое запрашиваемое значение должно иметь уникальную ссылку. Для цифровых значений используется нотация TBD1, TBD2 и т. д. В тексте документа, вместо реально выделенного IANA значения используется обозначение TBDx. Это поможет поместить в законченный документ RFC все корректно выделенные значения, включив их в те места документа, где они ожидаются в финальной версии. Для тестовых строк можно предложить конкретное имя. IANA обычно будет выделять предложенное значение, если оно не вступает в конфликт с выделенными ранее.

• Обычно выделяемые значения выбирает IANA, а в документах следует указывать значения TBD. Однако в некоторых случаях значения могут использоваться для тестирования предварительных реализаций. В таких случаях допускается включение текста, предлагающего конкретное значение, которое следует использовать (вместе с обоснованием выбора значений). Например, можно включить текст: «the value XXX is suggested as it is used in implementations⁹». Однако следует отметить, что предложенные значения не обязательно будут выделены – IANA попытается это сделать, но выделение может оказаться невозможным, если предложенные значения уже используются.

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

   

  Значение	Описание	Документ
  TBD1	Foobar	[RFCXXXX]

   

• В разделе «Согласование с IANA (IANA Considerations) следует указать все действия IANA со ссылками на соответствующие разделы документов, если таковые имеются. При регистрации множества значений в общем случае полезно собрать их в таблицу¹⁰. В таблице имеет смысл использовать такой же формат, который применяется на web-сайте IANA. Пример показан на врезке справа.

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

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

5.2. Обновление регистрации

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

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

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

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

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

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

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

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

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

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

This document has no IANA actions¹¹.

Такое заявление или его эквивалент, должно включаться в документ лишь после того, как рабочая группа или представивший документ индивидуал убеждены в его истинности. Использование такой формулировки «по шаблону» может привести к неполным или некорректным действиям IANA.

Если в спецификации используются значения из пространств имен, которыми не управляет IANA, может оказаться полезным отметить это словами типа:

The values of the Foobar parameter are assigned by the Barfoo registry on behalf of the Rabfoo Forum. Therefore, this document has no IANA actions¹².

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

[RFC Editor: please remove this section prior to publication.]¹³

или

[RFC Editor: please do not remove this section.]¹⁴

6.2. Документирование управления пространством имен

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

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

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

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

6.4. Отзыв выделенных значений

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

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

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

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

7. Апелляции

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

8. Списки рассылок

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

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

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

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

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

10. Отличия от RFC 2434

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

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

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

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

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

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

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

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

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

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

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

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

В этот документ внесли существенный вклад отклики 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.

В разделе благодарностей RFC 2434 было сказано:

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

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

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

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

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

[ASSIGNED] Reynolds, J., Ed., “Assigned Numbers: RFC 1700 is Replaced by an On-line Database”, RFC 3232, January 2002.

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

[DHCP-IANA] Droms, R., “Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types”, BCP 43, RFC 2939, September 2000.

[EXPERIMENTATION] Narten, T., “Assigning Experimental and Testing Numbers Considered Useful”, BCP 82, RFC 3692, January 2004.

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

[IANA-MOU] Carpenter, B., Baker, F., and M. Roberts, “Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority”, RFC 2860, June 2000.

[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] Kent, S. and K. Seo, “Security Architecture for the Internet Protocol”, RFC 4301, December 2005.

[MIME-REG] Freed, N. and J. Klensin, “Media Type Specifications and Registration Procedures”, BCP 13, RFC 4288, December 2005.

[PROTOCOL-EXT] Carpenter, B. and B. Aboba, “Design Considerations for Protocol Extensions”, Work in Progress, December 2007.

[RFC2929] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, “Domain Name System (DNS) IANA Considerations”, BCP 42, RFC 2929, September 2000.

[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, “IANA Guidelines for IPv4 Multicast Address Assignments”, BCP 51, RFC 3171, August 2001.

[RFC3228] Fenner, B., “IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)”, BCP 57, RFC 3228, February 2002.

[RFC3552] Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations”, BCP 72, RFC 3552, July 2003.

[RFC3575] Aboba, B., “IANA Considerations for RADIUS (Remote Authentication Dial In User Service)”, RFC 3575, July 2003.

[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., “Extensible Authentication Protocol (EAP)”, RFC 3748, June 2004.

[RFC3775] Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6”, RFC 3775, June 2004.

[RFC3932] Alvestrand, H., “The IESG and RFC Editor Documents: Procedures”, BCP 92, RFC 3932, October 2004.

[RFC3942] Volz, B., “Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options”, RFC 3942, November 2004.

[RFC3968] Camarillo, G., “The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)”, BCP 98, RFC 3968, December 2004.

[RFC3978] Bradner, S., Ed., “IETF Rights in Contributions”, BCP 78, RFC 3978, March 2005.

[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, “Diameter Network Access Server Application”, RFC 4005, August 2005.

[RFC4025] Richardson, M., “A Method for Storing Ipsec Keying Material in DNS”, RFC 4025, March 2005.

[RFC4044] McCloghrie, K., “Fibre Channel Management MIB”, RFC 4044, May 2005.

[RFC4124] Le Faucheur, F., Ed., “Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering”, RFC 4124, June 2005.

[RFC4169] Torvinen, V., Arkko, J., and M. Naslund, “Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2”, RFC 4169, November 2005.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., “A Border Gateway Protocol 4 (BGP-4)”, RFC 4271, January 2006.

[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, “Mobile Node Identifier Option for Mobile IPv6 (MIPv6)”, RFC 4283, November 2005.

[RFC4306] Kaufman, C., Ed., “Internet Key Exchange (IKEv2) Protocol”, RFC 4306, December 2005.

[RFC4340] Kohler, E., Handley, M., and S. Floyd, “Datagram Congestion Control Protocol (DCCP)”, RFC 4340, March 2006.

[RFC4346] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1”, RFC 4346, April 2006.

[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, “Transport Layer Security (TLS) Extensions”, RFC 4366, April 2006.

[RFC4395] Hansen, T., Hardie, T., and L. Masinter, “Guidelines and Registration Procedures for New URI Schemes”, BCP 115, RFC 4395, February 2006.

[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., “Simple Authentication and Security Layer (SASL)”, RFC 4422, June 2006.

[RFC4446] Martini, L., “IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)”, BCP 116, RFC 4446, April 2006.

[RFC4520] Zeilenga, K., “Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)”, BCP 64, RFC 4520, June 2006.

[RFC4589] Schulzrinne, H. and H. Tschofenig, “Location Types Registry”, RFC 4589, July 2006.

[RFC4727] Fenner, B., “Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers”, RFC 4727, November 2006.

[RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, “The RObust Header Compression (ROHC) Framework”, RFC 4995¹⁶, July 2007.

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

Thomas Narten

IBM Corporation

3039 Cornwallis Ave.

PO Box 12195 – BRQA/502

Research Triangle Park, NC 27709-2195

Phone: 919-254-7798

EMail: narten@us.ibm.com

Harald Tveit Alvestrand

Google

Beddingen 10

Trondheim, 7014

Norway

EMail: Harald@Alvestrand.no

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

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

nmalykh@protokols.ru

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

Copyright (C) The IETF Trust (2008).

К этому документу применимы права, лицензии и ограничения, указанные в 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.

---