Assigning Experimental and Testing Numbers Considered Useful
RFC 3692 рекомендует авторам разделов IANA Considerations рассматривать резервирование небольших диапазонов номеров для экспериментов с расширениями протоколов и новыми функциями. Такие значения позволяют тестировать изменения без получения постоянного назначения, но не предназначены для общего развёртывания или включения по умолчанию в продуктах. Продукт, использующий экспериментальный номер, должен требовать от конечного пользователя явного включения экспериментальной функции и предоставлять ему возможность выбрать и назначить конкретное значение, чтобы избежать конфликтов. Документ резервирует для поля IP Protocol значения 253 и 254 и обновляет RFC 2434.
Рабочая группа сети T. Narten
Запрос комментариев: 3692 IBM
BCP: 82 Январь 2004
Обновляет: 2434
Категория: Лучшая современная практика
Выделение экспериментальных и тестовых номеров, признанных полезными
Статус этого меморандума
Этот документ устанавливает Лучшую современную практику Интернета для
Интернет-сообщества и запрашивает обсуждение и предложения по
улучшению. Распространение этого меморандума не ограничено.
Уведомление об авторских правах
Copyright (C) The Internet Society (2004). All Rights Reserved.
Аннотация
При экспериментировании с протоколами или их расширении часто необходимо
использовать некоторый номер протокола или константу, чтобы фактически
тестировать или экспериментировать с новой функцией, даже при тестировании
в закрытой среде. Например, для тестирования новой опции DHCP нужен номер
опции для идентификации новой функции. Этот документ рекомендует, чтобы при
написании разделов IANA Considerations авторы рассматривали возможность
выделения небольшого диапазона номеров для экспериментальных целей, который
реализаторы могут использовать при тестировании расширений протоколов или
других новых возможностей. Этот документ резервирует некоторые диапазоны
номеров для экспериментальных целей в конкретных протоколах, для которых
выявлена необходимость поддержки экспериментирования.
Содержание
1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Рекомендация для протоколов . . . . . . . . . . . . . . . 4
2. Соображения IANA. . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Поле IP Protocol. . . . . . . . . . . . . . . . . . . . 5
2.2. Существующие пространства имён . . . . . . . . . . . . . 5
3. Соображения безопасности. . . . . . . . . . . . . . . . . . . 5
4. Благодарности. . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Ссылки . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Нормативные ссылки . . . . . . . . . . . . . . . . . . . 5
5.2. Информационные ссылки . . . . . . . . . . . . . . . . . 6
6. Адрес автора . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Полное заявление об авторских правах . . . . . . . . . . . . . 7
Narten Лучшая современная практика [Страница 1]
RFC 3692 Выделение экспериментальных и тестовых номеров Январь 2004
1. Введение
При экспериментировании с протоколами или их расширении часто необходимо
иметь номер протокола как часть реализации [RFC2434]. Например, для
разработки протокола, работающего непосредственно над IP, нужен номер IP
Protocol, помещаемый в поле Protocol заголовка IP [RFC791]. В некоторых
случаях получение нового номера не представляет сложности (например,
общеизвестный порт TCP или UDP) либо вообще не требуется (например, номера
портов TCP и UDP для целей тестирования). В других случаях получить номер
сложнее. Например, число доступных и неназначенных значений в пространстве
имён может быть настолько малым, что есть опасение: при неосторожном
назначении все доступные номера будут исчерпаны. Даже в случаях, когда
номеров потенциально много, назначение номеров может быть нежелательным,
если предлагаемое использование не было надлежащим образом рассмотрено
более широким сообществом. Поэтому некоторые пространства номеров
устанавливают, что IANA делает назначения только в случаях, когда
предлагаемый протокол имеет сильную поддержку сообщества. Например,
значения из некоторых пространств имён назначаются только посредством
«IETF Standards Action» [RFC2434], что требует, чтобы предполагаемое
использование было описано в RFC IETF Standards Track.
Для эксперимента с новым протоколом может потребоваться экспериментальное
значение, которое не будет конфликтовать с существующим или будущим
использованием.
Один из подходов заключается в том, чтобы разрешить IANA делать временные
назначения для таких целей. Идея состоит в том, что значение протокола
может быть назначено для проведения эксперимента, но после завершения
эксперимента номер был бы возвращён IANA. Однако этот подход имеет несколько
недостатков. Во-первых, опыт показал, что после назначения номера может
быть трудно вернуть. Например, контактная информация устаревает, и может
стать трудно выяснить, каков фактический статус эксперимента. Во-вторых,
если происходит развёртывание с временно назначенным номером (например, он
включён в состав продукта), становится очень трудно определить, приведёт ли
повторное использование этого номера к неблагоприятному воздействию на уже
развёрнутые устройства. Наконец, может быть трудно определить, когда
эксперимент завершился и нужно ли вернуть номер.
Альтернативный подход, рекомендуемый в этом документе, состоит в выделении
диапазона номеров, специально предназначенных для целей тестирования и
экспериментирования. Устройства, взаимно согласившиеся на это, могли бы
использовать эти номера для любых желаемых целей, но с пониманием, что они
зарезервированы для общих целей тестирования и другие реализации могут
использовать те же номера для иных экспериментальных применений.
Narten Лучшая современная практика [Страница 2]
RFC 3692 Выделение экспериментальных и тестовых номеров Январь 2004
Номера в диапазоне для экспериментирования подобны тем, которые в RFC 2434
[IANA-CONSIDERATIONS] называются «Private Use». Они не предназначены для
использования в общих развёртываниях или для включения по умолчанию в
продуктах либо иных общедоступных выпусках. В тех случаях, когда продукт или
выпуск использует экспериментальный номер, от конечного пользователя должно
требоваться явное включение экспериментальной возможности, а также должна
быть возможность выбирать и назначать, какой номер из экспериментального
диапазона будет использоваться для конкретной цели (то есть чтобы конечный
пользователь мог обеспечить, что использование конкретного номера не
конфликтует с другими продолжающимися применениями). Поставка продукта с
предварительно включённым конкретным значением была бы неуместна и может
приводить к проблемам совместимости, когда выбранное значение конфликтует с
другим применением, как это когда-нибудь наверняка произойдёт.
Из сказанного выше следует, что группе поставщиков, консорциуму или другой
Организации по разработке стандартов было бы неуместно договориться между
собой использовать конкретное значение для определённой цели, а затем
договориться развёртывать устройства, использующие эти значения. По
определению экспериментальные номера не гарантируются как уникальные ни в
какой среде, кроме той, в которой локальный системный администратор выбрал
использовать конкретный номер для конкретной цели и может обеспечить, что
конкретное значение ещё не используется для какой-либо другой цели.
После того как расширение протестировано и признано полезным, постоянный
номер можно было бы получить через обычные процедуры назначения.
Большинство реализаций не будет делать ничего особенного с номерами,
назначенными для целей тестирования. В частности, если пакет или другая
единица данных протокола (PDU) специально не направлена устройству, это
устройство даже не будет просматривать это поле при обработке PDU.
Например, IP-маршрутизаторам не требуется исследовать или понимать поле
Protocol Type IP-дейтаграмм, чтобы знать, как правильно их пересылать. В тех
случаях, когда пакет или PDU направлен устройству и это устройство не было
настроено на распознавание расширения, устройство либо проигнорирует PDU,
либо отбросит его, либо сообщит об ошибке — в зависимости от
протокольно-специфичных правил, указывающих, как обрабатывать неизвестные
опции или возможности. В тех случаях, когда протокол предусматривает разные
способы обработки нераспознанных расширений (например, молча отбросить или
сообщить об ошибке), этому протоколу необходимо резервировать значения для
целей тестирования из всех соответствующих диапазонов. Только те реализации,
которые специально включены или настроены для использования расширения или
возможности, с которыми проводится эксперимент, будут обрабатывать данные
далее.
Narten Лучшая современная практика [Страница 3]
RFC 3692 Выделение экспериментальных и тестовых номеров Январь 2004
1.1. Рекомендация для протоколов
Чтобы сделать возможным безопасное экспериментирование с расширениями
протоколов, в документах протоколов следует рассматривать резервирование
небольшого набора номеров протоколов для экспериментирования. Такие
резервирования могут быть сделаны посредством явного резервирования в
разделе IANA Considerations.
Точное число значений, резервируемых для экспериментирования, будет зависеть
от конкретного протокола и факторов, специфичных для этого протокола.
Например, в случаях, когда значения поля подразделяются на диапазоны, к
которым применяется различная обработка (например, «молча игнорировать» или
«вернуть ошибку», если значение не понято), может потребоваться резервировать
одно или несколько значений из каждого поддиапазона.
Для протоколов, возвращающих коды ошибок, также может быть уместно
резервировать небольшое число экспериментальных значений ошибок, которые
могут использоваться совместно с возможными экспериментальными применениями.
Например, экспериментальное сообщение может приводить (даже при нормальных
условиях) к ошибке, при этом специальный код ошибки (или подкод) указывает
тип условия ошибки.
Во многих, если не в большинстве, случаев будет достаточно резервировать
одно значение для экспериментального использования. Хотя может возникнуть
соблазн резервировать больше, чтобы было легко тестировать много вещей
одновременно, резервирование многих значений также может усилить соблазн
для лица, использующего конкретное значение, предполагать, что определённое
экспериментальное значение можно использовать исключительно для заданной
цели. Значения, зарезервированные для экспериментального использования,
никогда не должны становиться постоянными; постоянные назначения следует
получать посредством стандартных процессов. Как описано выше,
экспериментальные номера предназначены для экспериментирования и
тестирования и не предназначены для широких или общих развёртываний.
Когда протоколы, использующие экспериментальные номера, включаются в
продукты, поставляемые версии продуктов должны по умолчанию отключать
распознавание экспериментальных номеров протокола — то есть конечный
пользователь продукта должен явно «включить» экспериментальную
функциональность протокола. В большинстве случаев реализация продукта должна
требовать от конечного пользователя явной настройки значения до включения
его использования. Если продукт не имеет пользовательского интерфейса для
такой настройки конечным пользователем, продукт должен требовать явного
перепрограммирования (например, специальной загрузки встроенного ПО или
установки карты возможности), чтобы неявно настроить экспериментальный
номер(а) протокола(ов).
Narten Лучшая современная практика [Страница 4]
RFC 3692 Выделение экспериментальных и тестовых номеров Январь 2004
2. Соображения IANA
2.1. Поле IP Protocol
Назначение новых значений для поля IP Protocol требует IETF Standards Action
согласно [RFC2780]. Для целей экспериментирования и тестирования IANA
назначила для этой цели два значения: 253 и 254. Эти значения были выделены
из верхней части доступного пространства номеров, чтобы их было легко
идентифицировать благодаря их заметному отличию от уже произведённых
назначений.
2.2. Существующие пространства имён
Существует множество пространств имён, для которых не зарезервированы
значения для целей экспериментирования или тестирования. Экспериментальные
значения для таких протоколов, разумеется, могут назначаться обычным
процессом публикации RFC, документирующего подробности такого выделения.
Чтобы упростить процесс в тех случаях, когда публикация документации только
для назначения экспериментального выделения представляется чрезмерной,
экспериментальные значения могут быть назначены через IESG Approval
[RFC2434].
3. Соображения безопасности
Этот документ не имеет известных последствий для безопасности.
4. Благодарности
Улучшения в этот документ были внесены в результате конкретной обратной
связи от Steve Bellovin, Scott Bradner, Randy Bush, Bill Fenner, Steve
Hanna, Paul Hoffman, Henrik Levkowetz, John Loughney, Allison Mankin и
Richard Woundy.
5. Ссылки
5.1. Нормативные ссылки
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", BCP
37, RFC 2780, March 2000.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
Narten Лучшая современная практика [Страница 5]
RFC 3692 Выделение экспериментальных и тестовых номеров Январь 2004
5.2. Информационные ссылки
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
6. Адрес автора
Thomas Narten
IBM Corporation
P.O. Box 12195
Research Triangle Park, NC 27709-2195
USA
Phone: +1 919 254 7798
EMail: narten@us.ibm.com
Narten Лучшая современная практика [Страница 6]
RFC 3692 Выделение экспериментальных и тестовых номеров Январь 2004
7. Полное заявление об авторских правах
Copyright (C) The Internet Society (2004). All Rights Reserved.
Этот документ и его переводы могут копироваться и предоставляться
другим лицам, а производные работы, содержащие комментарии к нему,
иным образом объясняющие его или содействующие его реализации, могут
подготавливаться, копироваться, публиковаться и распространяться
полностью или частично без каких-либо ограничений при условии, что
приведённое выше уведомление об авторском праве и настоящий абзац
включены во все такие копии и производные работы. Однако сам этот
документ не может быть каким-либо образом изменён, например путём
удаления уведомления об авторском праве или ссылок на Internet Society
либо другие интернет-организации, за исключением случаев, когда это
необходимо для разработки интернет-стандартов, при которой должны
соблюдаться процедуры в отношении авторских прав, определённые
процессом Internet Standards, либо когда это требуется для его
перевода на языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и
не будут отозваны Internet Society или её правопреемниками либо
лицами, которым она передала права.
Этот документ и содержащаяся в нём информация предоставляются на
условиях «КАК ЕСТЬ», И INTERNET SOCIETY И INTERNET ENGINEERING TASK
FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ЯВНЫХ И ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ,
ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ
СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, А ТАКЖЕ
ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ
ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Благодарность
Финансирование функции RFC Editor в настоящее время предоставляется
Internet Society.
Narten Лучшая современная практика [Страница 7]
Network Working Group T. Narten
Request for Comments: 3692 IBM
BCP: 82 January 2004
Updates: 2434
Category: Best Current Practice
Assigning Experimental and Testing Numbers Considered Useful
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
When experimenting with or extending protocols, it is often necessary
to use some sort of protocol number or constant in order to actually
test or experiment with the new function, even when testing in a
closed environment. For example, to test a new DHCP option, one
needs an option number to identify the new function. This document
recommends that when writing IANA Considerations sections, authors
should consider assigning a small range of numbers for
experimentation purposes that implementers can use when testing
protocol extensions or other new features. This document reserves
some ranges of numbers for experimentation purposes in specific
protocols where the need to support experimentation has been
identified.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Recommendation for Protocols . . . . . . . . . . . . . . 4
2. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 5
2.1. IP Protocol Field. . . . . . . . . . . . . . . . . . . . 5
2.2. Existing Name Spaces . . . . . . . . . . . . . . . . . . 5
3. Security Considerations. . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . 6
6. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
7. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7
Narten Best Current Practice [Page 1]
RFC 3692 Assigning Experimental and Testing Numbers January 2004
1. Introduction
When experimenting with or extending protocols, it is often necessary
to have a protocol number as part of the implementation [RFC2434].
For example, to develop a protocol that runs directly above IP, one
needs an IP Protocol Number to place in the Protocol field of the IP
header [RFC791]. In some cases, obtaining a new number is
straightforward (e.g., a well-known TCP or UDP port) or not even
necessary (e.g., TCP and UDP port numbers for testing purposes). In
other cases, obtaining a number is more difficult. For example, the
number of available and unassigned values in a name space may be
small enough that there is concern that all available numbers will be
used up if assigned carelessly. Even in cases where numbers are
potentially plentiful, it may be undesirable to assign numbers unless
the proposed usage has been adequately reviewed by the broader
community. Consequently, some number spaces specify that IANA only
make assignments in cases where there is strong community support for
a proposed protocol. For example, values out of some name spaces are
only assigned through an "IETF Standards Action" [RFC2434], which
requires that the proposed use be in an IETF Standards Track RFC.
In order to experiment with a new protocol, an experimental value may
be needed that won't collide with an existing or future usage.
One approach is to allow IANA to make temporary assignments for such
purposes. The idea is that a protocol value can be assigned to allow
experimentation, but after the experiment ends, the number would be
returned to IANA. There are several drawbacks to this approach,
however. First, experience has shown that it can be difficult to
reclaim numbers once assigned. For example, contact information
becomes outdated and it can become difficult to find out what the
status of an experiment actually is. Second, should deployment with
the temporarily assigned number take place (e.g., it is included as
part of a product), it becomes very difficult to determine whether or
not reuse of that number would lead to adverse impact with regards to
deployed devices. Finally, it can be difficult to determine when an
experiment has ended and whether the number needs to be returned.
An alternate approach, and the one recommended in this document, is
to assign a range of numbers specifically earmarked for testing and
experimentation purposes. Mutually consenting devices could use
these numbers for whatever purposes they desire, but under the
understanding that they are reserved for generic testing purposes,
and other implementations may use the same numbers for different
experimental uses.
Narten Best Current Practice [Page 2]
RFC 3692 Assigning Experimental and Testing Numbers January 2004
Numbers in the experimentation range are similar to those called
"Private Use" in RFC 2434 [IANA-CONSIDERATIONS]. They are not
intended to be used in general deployments or be enabled by default
in products or other general releases. In those cases where a
product or release makes use of an experimental number, the end user
must be required to explicitly enable the experimental feature and
likewise have the ability to chose and assign which number from the
experimental range will be used for a specific purpose (i.e., so the
end user can ensure that use of a particular number doesn't conflict
with other on-going uses). Shipping a product with a specific value
pre-enabled would be inappropriate and can lead to interoperability
problems when the chosen value collides with a different usage, as it
someday surely will.
From the above, it follows that it would be inappropriate for a group
of vendors, a consortia, or another Standards Development
Organization to agree among themselves to use a particular value for
a specific purpose and then agree to deploy devices using those
values. By definition, experimental numbers are not guaranteed to be
unique in any environment other than one where the local system
administrator has chosen to use a particular number for a particular
purpose and can ensure that a particular value is not already in use
for some other purpose.
Once an extension has been tested and shown to be useful, a permanent
number could be obtained through the normal assignment procedures.
Most implementations will not do anything special with numbers
assigned for testing purposes. In particular, unless a packet or
other Protocol Data Unit (PDU) is specifically directed at a device,
that device will not even look at the field while processing the PDU.
For example, IP routers do not need to examine or understand the
Protocol Type field of IP datagrams in order to know how to correctly
forward them. In those cases where a packet or PDU is directed at a
device, and that device has not been configured to recognize the
extension, the device will either ignore the PDU, discard it, or
signal an error, depending on the protocol-specific rules that
indicate how to process unknown options or features. In those cases
where a protocol has different ways of handling unrecognized
extensions (e.g., silently discard vs. signal an error), that
protocol needs to reserve values for testing purposes from all the
appropriate ranges. Only those implementations specifically enabled
or configured to make use of an extension or feature that is being
experimented with would process the data further.
Narten Best Current Practice [Page 3]
RFC 3692 Assigning Experimental and Testing Numbers January 2004
1.1. Recommendation for Protocols
To make it possible to experiment with protocol extensions safely,
protocol documents should consider reserving a small set of protocol
numbers for experimentation. Such reservations can be made through
an explicit reservation in an IANA Considerations section.
The exact number of values to reserve for experimentation will depend
on the specific protocol and factors specific to that protocol. For
example, in cases where the values of a field are subdivided into
ranges that are treated differently (e.g., "silently ignore" vs.
"return an error" if the value is not understood), one or more values
from each sub-range may need to be reserved.
For protocols that return error codes, it may also be appropriate to
reserve a small number of experimental error values that can be used
in conjunction with possible experimental uses. For example, an
experimental message might result (even under normal conditions) in
an error, with a special error code (or sub-code) indicating the type
of error condition.
In many, if not most cases, reserving a single value for experimental
use will suffice. While it may be tempting to reserve more in order
to make it easy to test many things at once, reserving many may also
increase the temptation for someone using a particular value to
assume that a specific experimental value can be used for a given
purpose exclusively. Values reserved for experimental use are never
to be made permanent; permanent assignments should be obtained
through standard processes. As described above, experimental numbers
are intended for experimentation and testing and are not intended for
wide or general deployments.
When protocols that use experimental numbers are included in
products, the shipping versions of the products must disable
recognition of protocol experimental numbers by default -- that is,
the end user of the product must explicitly "turn on" the
experimental protocol functionality. In most cases, a product
implementation must require the end user to configure the value
explicitly prior to enabling its usage. Should a product not have a
user interface for such end user configuration, the product must
require explicit re-programming (e.g., a special firmware download,
or installation of a feature card) to configure the experimental
number(s) of the protocol(s) implicitly.
Narten Best Current Practice [Page 4]
RFC 3692 Assigning Experimental and Testing Numbers January 2004
2. IANA Considerations
2.1. IP Protocol Field
Assignment of new values for the IP Protocol field requires an IETF
Standards Action per [RFC2780]. For the purposes of experimentation
and testing, IANA has assigned the two values 253 and 254 for this
purpose. These values have been allocated from the upper end of the
available number space in order to make them easy to identify by
having them stand out relative to the existing assignments that have
been made.
2.2. Existing Name Spaces
Numerous name spaces exist for which no values have been reserved for
experimentation or testing purpose. Experimental values for such
protocols can of course be assigned through the normal process of
publishing an RFC that documents the details of such an allocation.
To simplify the process in those cases where the publication of a
documentation just for the purpose of assigning an experimental
allocation seems overkill, experimental values can be made through
IESG Approval [RFC2434].
3. Security Considerations
This document has no known security implications.
4. Acknowledgments
Improvements to this document came as a result of specific feedback
from Steve Bellovin, Scott Bradner, Randy Bush, Bill Fenner, Steve
Hanna, Paul Hoffman, Henrik Levkowetz, John Loughney, Allison Mankin,
and Richard Woundy.
5. References
5.1. Normative References
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", BCP
37, RFC 2780, March 2000.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
Narten Best Current Practice [Page 5]
RFC 3692 Assigning Experimental and Testing Numbers January 2004
5.2. Informative References
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
6. Author's Address
Thomas Narten
IBM Corporation
P.O. Box 12195
Research Triangle Park, NC 27709-2195
USA
Phone: +1 919 254 7798
EMail: narten@us.ibm.com
Narten Best Current Practice [Page 6]
RFC 3692 Assigning Experimental and Testing Numbers January 2004
7. Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Narten Best Current Practice [Page 7]