diff options
Diffstat (limited to 'doc/rfc/rfc5226.txt')
| -rw-r--r-- | doc/rfc/rfc5226.txt | 1515 |
1 files changed, 1515 insertions, 0 deletions
diff --git a/doc/rfc/rfc5226.txt b/doc/rfc/rfc5226.txt new file mode 100644 index 0000000..fa07145 --- /dev/null +++ b/doc/rfc/rfc5226.txt @@ -0,0 +1,1515 @@ + + + + + + +Network Working Group T. Narten +Request for Comments: 5226 IBM +BCP: 26 H. Alvestrand +Obsoletes: 2434 Google +Category: Best Current Practice May 2008 + + + Guidelines for Writing an IANA Considerations Section in RFCs + +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. + +Abstract + + Many protocols make use of identifiers consisting of constants and + other well-known values. Even after a protocol has been defined and + deployment has begun, new values may need to be assigned (e.g., for a + new option type in DHCP, or a new encryption or authentication + transform for IPsec). To ensure that such quantities have consistent + values and interpretations across all implementations, their + assignment must be administered by a central authority. For IETF + protocols, that role is provided by the Internet Assigned Numbers + Authority (IANA). + + In order for IANA to manage a given namespace prudently, it needs + guidelines describing the conditions under which new values can be + assigned or when modifications to existing values can be made. If + IANA is expected to play a role in the management of a namespace, + IANA must be given clear and concise instructions describing that + role. This document discusses issues that should be considered in + formulating a policy for assigning values to a namespace and provides + guidelines for authors on the specific text that must be included in + documents that place demands on IANA. + + This document obsoletes RFC 2434. + + + + + + + + + + + + + +Narten & Alvestrand Best Current Practice [Page 1] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Why Management of a Namespace May Be Necessary ..................3 + 3. Designated Experts ..............................................4 + 3.1. The Motivation for Designated Experts ......................4 + 3.2. The Role of the Designated Expert ..........................5 + 3.3. Designated Expert Reviews ..................................7 + 4. Creating a Registry .............................................8 + 4.1. Well-Known IANA Policy Definitions .........................9 + 4.2. What to Put in Documents That Create a Registry ...........12 + 4.3. Updating IANA Guidelines for Existing Registries ..........15 + 5. Registering New Values in an Existing Registry .................15 + 5.1. What to Put in Documents When Registering Values ..........15 + 5.2. Updating Registrations ....................................17 + 5.3. Overriding Registration Procedures ........................17 + 6. Miscellaneous Issues ...........................................18 + 6.1. When There Are No IANA Actions ............................18 + 6.2. Namespaces Lacking Documented Guidance ....................19 + 6.3. After-the-Fact Registrations ..............................19 + 6.4. Reclaiming Assigned Values ................................19 + 7. Appeals ........................................................20 + 8. Mailing Lists ..................................................20 + 9. Security Considerations ........................................20 + 10. Changes Relative to RFC 2434 ..................................21 + 11. Acknowledgments ...............................................22 + 12. References ....................................................22 + 12.1. Normative References .....................................22 + 12.2. Informative References ...................................22 + +1. Introduction + + Many protocols make use of fields that contain constants and other + well-known values (e.g., the Protocol field in the IP header [IP] or + MIME media types [MIME-REG]). Even after a protocol has been defined + and deployment has begun, new values may need to be assigned (e.g., a + new option type in DHCP [DHCP-OPTIONS] or a new encryption or + authentication transform for IPsec [IPSEC]). To ensure that such + fields have consistent values and interpretations in different + implementations, their assignment must be administered by a central + authority. For IETF protocols, that role is provided by the Internet + Assigned Numbers Authority (IANA) [IANA-MOU]. + + In this document, we call the set of possible values for such a field + a "namespace"; its actual value may be a text string, a number, or + another kind of value. The binding or association of a specific + value with a particular purpose within a namespace is called an + assigned number (or assigned value, or sometimes a "code point", + + + +Narten & Alvestrand Best Current Practice [Page 2] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + + "protocol constant", or "protocol parameter"). Each assignment of a + value in a namespace is called a registration. + + In order for IANA to manage a given namespace prudently, it needs + guidelines describing the conditions under which new values should be + assigned or when (and how) modifications to existing values can be + made. This document provides guidelines to authors on what sort of + text should be added to their documents in order to provide IANA + clear guidelines, and it reviews issues that should be considered in + formulating an appropriate policy for assigning numbers to name + spaces. + + Not all namespaces require centralized administration. In some + cases, it is possible to delegate a namespace in such a way that + further assignments can be made independently and with no further + (central) coordination. In the Domain Name System, for example, IANA + only deals with assignments at the higher levels, while subdomains + are administered by the organization to which the space has been + delegated. As another example, Object Identifiers (OIDs) as defined + by the ITU are also delegated [ASSIGNED]; IANA manages the subtree + rooted at "iso.org.dod.internet" (1.3.6.1) . When a namespace is + delegated, the scope of IANA is limited to the parts of the namespace + where IANA has authority. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [KEYWORDS]. + For this document, "the specification" as used by RFC 2119 refers to + the processing of protocol documents within the IETF standards + process. + +2. Why Management of a Namespace May Be Necessary + + One issue to consider in managing a namespace is its size. If the + space is small and limited in size, assignments must be made + carefully to prevent exhaustion of the space. If the space is + essentially unlimited, on the other hand, potential exhaustion will + probably not be a practical concern at all. Even when the space is + essentially unlimited, however, it is usually desirable to have at + least a minimal review prior to assignment in order to: + + - prevent the hoarding of or unnecessary wasting of values. For + example, if the space consists of text strings, it may be + desirable to prevent entities from obtaining large sets of + strings that correspond to desirable names (e.g., existing + company names). + + + + + +Narten & Alvestrand Best Current Practice [Page 3] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + + - provide a sanity check that the request actually makes sense and + is necessary. Experience has shown that some level of minimal + review from a subject matter expert is useful to prevent + assignments in cases where the request is malformed or not + actually needed (i.e., an existing assignment for an essentially + equivalent service already exists). + + A second consideration is whether it makes sense to delegate the + namespace in some manner. This route should be pursued when + appropriate, as it lessens the burden on IANA for dealing with + assignments. + + A third, and perhaps most important, consideration concerns potential + impact on the interoperability of unreviewed extensions. Proposed + protocol extensions generally benefit from community review; indeed, + review is often essential to avoid future interoperability problems + [PROTOCOL-EXT]. + + When the namespace is essentially unlimited and there are no + potential interoperability issues, assigned numbers can safely be + given out to anyone without any subjective review. In such cases, + IANA can make assignments directly, provided that IANA is given + specific instructions on what types of requests it should grant, and + what information must be provided as part of a well-formed request + for an assigned number. + +3. Designated Experts + +3.1. The Motivation for Designated Experts + + It should be noted that IANA does not create or define assignment + policy itself; rather, it carries out policies that have been defined + by others and published in RFCs. IANA must be given a set of + guidelines that allow it to make allocation decisions with minimal + subjectivity and without requiring any technical expertise with + respect to the protocols that make use of a registry. + + In many cases, some review of prospective allocations is appropriate, + and the question becomes who should perform the review and what is + the purpose of the review. One might think that an IETF working + group (WG) familiar with the namespace at hand should be consulted. + In practice, however, WGs eventually disband, so they cannot be + considered a permanent evaluator. It is also possible for namespaces + to be created through individual submission documents, for which no + WG is ever formed. + + + + + + +Narten & Alvestrand Best Current Practice [Page 4] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + + One way to ensure community review of prospective assignments is to + have the requester submit a document for publication as an RFC. Such + an action helps ensure that the specification is publicly and + permanently available, and it allows some review of the specification + prior to publication and assignment of the requested code points. + This is the preferred way of ensuring review, and is particularly + important if any potential interoperability issues can arise. For + example, some assignments are not just assignments, but also involve + an element of protocol specification. A new option may define fields + that need to be parsed and acted on, which (if specified poorly) may + not fit cleanly with the architecture of other options or the base + protocols on which they are built. + + In some cases, however, the burden of publishing an RFC in order to + get an assignment is excessive. However, it is generally still + useful (and sometimes necessary) to discuss proposed additions on a + mailing list dedicated to the purpose (e.g., the ietf-types@iana.org + for media types) or on a more general mailing list (e.g., that of a + current or former IETF WG). Such a mailing list provides a way for + new registrations to be publicly reviewed prior to getting assigned, + or gives advice to persons wanting help in understanding what a + proper registration should contain. + + While discussion on a mailing list can provide valuable technical + feedback, opinions may vary and discussions may continue for some + time without clear resolution. In addition, IANA cannot participate + in all of these mailing lists and cannot determine if or when such + discussions reach consensus. Therefore, IANA relies on a "designated + expert" for advice regarding the specific question of whether an + assignment should be made. The designated expert is an individual + who is responsible for carrying out an appropriate evaluation and + returning a recommendation to IANA. + + It should be noted that a key motivation for having designated + experts is for the IETF to provide IANA with a subject matter expert + to whom the evaluation process can be delegated. IANA forwards + requests for an assignment to the expert for evaluation, and the + expert (after performing the evaluation) informs IANA as to whether + or not to make the assignment or registration. + +3.2. The Role of the Designated Expert + + The designated expert is responsible for initiating and coordinating + the appropriate review of an assignment request. The review may be + wide or narrow, depending on the situation and the judgment of the + designated expert. This may involve consultation with a set of + technology experts, discussion on a public mailing list, consultation + with a working group (or its mailing list if the working group has + + + +Narten & Alvestrand Best Current Practice [Page 5] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + + disbanded), etc. Ideally, the designated expert follows specific + review criteria as documented with the protocol that creates or uses + the namespace. (See the IANA Considerations sections of [RFC3748] + and [RFC3575] for examples that have been done for specific + namespaces.) + + Designated experts are expected to be able to defend their decisions + to the IETF community, and the evaluation process is not intended to + be secretive or bestow unquestioned power on the expert. Experts are + expected to apply applicable documented review or vetting procedures, + or in the absence of documented criteria, follow generally accepted + norms, e.g., those in Section 3.3. + + Section 5.2 discusses disputes and appeals in more detail. + + Designated experts are appointed by the IESG (normally upon + recommendation by the relevant Area Director). They are typically + named at the time a document creating or updating a namespace is + approved by the IESG, but as experts originally appointed may later + become unavailable, the IESG will appoint replacements if necessary. + + For some registries, it has proven useful to have multiple designated + experts. Sometimes those experts work together in evaluating a + request, while in other cases additional experts serve as backups. + In cases of disagreement among those experts, it is the + responsibility of those experts to make a single clear recommendation + to IANA. It is not appropriate for IANA to resolve disputes among + experts. In extreme situations (e.g., deadlock), the IESG may need + to step in to resolve the problem. + + In registries where a pool of experts evaluates requests, the pool + should have a single chair responsible for defining how requests are + to be assigned to and reviewed by experts. In some cases, the expert + pool may consist of a primary and backups, with the backups involved + only when the primary expert is unavailable. In other cases, IANA + might assign requests to individual members in sequential or + approximate random order. In the event that IANA finds itself having + received conflicting advice from its experts, it is the + responsibility of the pool's chair to resolve the issue and provide + IANA with clear instructions. + + Since the designated experts are appointed by the IESG, they may be + removed by the IESG. + + + + + + + + +Narten & Alvestrand Best Current Practice [Page 6] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + +3.3. Designated Expert Reviews + + In the eight years since RFC 2434 was published and has been put to + use, experience has led to the following observations: + + - A designated expert must respond in a timely fashion, normally + within a week for simple requests to a few weeks for more + complex ones. Unreasonable delays can cause significant + problems for those needing assignments, such as when products + need code points to ship. This is not to say that all reviews + can be completed under a firm deadline, but they must be + started, and the requester and IANA should have some + transparency into the process if an answer cannot be given + quickly. + + - If a designated expert does not respond to IANA's requests + within a reasonable period of time, either with a response or + with a reasonable explanation for the delay (e.g., some requests + may be particularly complex), and if this is a recurring event, + IANA must raise the issue with the IESG. Because of the + problems caused by delayed evaluations and assignments, the IESG + should take appropriate actions to ensure that the expert + understands and accepts his or her responsibilities, or appoint + a new expert. + + - The designated expert is not required to personally bear the + burden of evaluating and deciding all requests, but acts as a + shepherd for the request, enlisting the help of others as + appropriate. In the case that a request is denied, and + rejecting the request is likely to be controversial, the expert + should have the support of other subject matter experts. That + is, the expert must be able to defend a decision to the + community as a whole. + + In the case where a designated expert is used, but there are no + specific documented criteria for performing an evaluation, the + presumption should be that a code point should be granted, unless + there is a compelling reason to the contrary. Possible reasons to + deny a request include: + + - scarcity of code points, where the finite remaining code points + should be prudently managed, or when a request for a large + number of code points is made, when a single code point is the + norm. + + - documentation is not of sufficient clarity to evaluate or ensure + interoperability. + + + + +Narten & Alvestrand Best Current Practice [Page 7] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + + - the code point is needed for a protocol extension, but the + extension is not consistent with the documented (or generally + understood) architecture of the base protocol being extended, + and would be harmful to the protocol if widely deployed. It is + not the intent that "inconsistencies" refer to minor differences + "of a personal preference nature". Instead, they refer to + significant differences such as inconsistencies with the + underlying security model, implying a change to the semantics of + an existing message type or operation, requiring unwarranted + changes in deployed systems (compared with alternate ways of + achieving a similar result), etc. + + - the extension would cause problems with existing deployed + systems. + + - the extension would conflict with one under active development + by the IETF, and having both would harm rather than foster + interoperability. + +4. Creating a Registry + + Creating a registry involves describing the namespaces to be created, + an initial set of assignments (if appropriate), and guidelines on how + future assignments are to be made. + + Once a registry has been created, IANA records assignments that have + been made. The following labels describe the status of an individual + (or range) of assignments: + + Private Use: Private use only (not assigned), as described in + Section 4.1. + + Experimental: Available for experimental use as described in + [EXPERIMENTATION]. IANA does not record specific + assignments for any particular use. + + Unassigned: Unused and available for assignment via documented + procedures. + + Reserved: Not to be assigned. Reserved values are held for + special uses, such as to extend the namespace when it become + exhausted. Reserved values are not available for general + assignment. + + + + + + + + +Narten & Alvestrand Best Current Practice [Page 8] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + +4.1. Well-Known IANA Policy Definitions + + The following are some defined policies, some of which are in use + today. These cover a range of typical policies that have been used + to date to describe the procedure for assigning new values in a + namespace. It is not required that documents use these terms; the + actual requirement is that the instructions to IANA are clear and + unambiguous. However, use of these terms is RECOMMENDED where + possible, since their meaning is widely understood. + + Private Use - For private or local use only, with the type and + purpose defined by the local site. No attempt is made to + prevent multiple sites from using the same value in + different (and incompatible) ways. There is no need for + IANA to review such assignments (since IANA does not record + them) and assignments are not generally useful for broad + interoperability. It is the responsibility of the sites + making use of the Private Use range to ensure that no + conflicts occur (within the intended scope of use). + + Examples: Site-specific options in DHCP [DHCP-IANA], Fibre + Channel Port Type Registry [RFC4044], Exchange Types in the + IKEv2 header [RFC4306]. + + Experimental Use - Similar to private or local use only, with the + purpose being to facilitate experimentation. See + [EXPERIMENTATION] for details. + + Example: Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, + UDP, and TCP Headers [RFC4727]. + + Hierarchical Allocation - Delegated managers can assign values + provided they have been given control over that part of the + namespace. IANA controls the higher levels of the namespace + according to one of the other policies. + + Examples: DNS names, Object Identifiers, IP addresses. + + First Come First Served - Assignments are made to anyone on a + first come, first served basis. There is no substantive + review of the request, other than to ensure that it is + well-formed and doesn't duplicate an existing assignment. + However, requests must include a minimal amount of clerical + information, such as a point of contact (including an email + address) and a brief description of how the value will be + used. Additional information specific to the type of value + requested may also need to be provided, as defined by the + namespace. For numbers, the exact value is generally + + + +Narten & Alvestrand Best Current Practice [Page 9] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + + assigned by IANA; with names, specific text strings can + usually be requested. + + Examples: SASL mechanism names [RFC4422], LDAP Protocol + Mechanisms, and LDAP Syntax [RFC4520]. + + Expert Review (or Designated Expert) - approval by a Designated + Expert is required. The required documentation and review + criteria for use by the Designated Expert should be provided + when defining the registry. For example, see Sections 6 and + 7.2 in [RFC3748]. + + Examples: EAP Method Types [RFC3748], HTTP Digest AKA + algorithm versions [RFC4169], URI schemes [RFC4395], GEOPRIV + Location Types [RFC4589]. + + Specification Required - Values and their meanings must be + documented in a permanent and readily available public + specification, in sufficient detail so that interoperability + between independent implementations is possible. When used, + Specification Required also implies use of a Designated + Expert, who will review the public specification and + evaluate whether it is sufficiently clear to allow + interoperable implementations. The intention behind + "permanent and readily available" is that a document can + reasonably be expected to be findable and retrievable long + after IANA assignment of the requested value. Publication + of an RFC is an ideal means of achieving this requirement, + but Specification Required is intended to also cover the + case of a document published outside of the RFC path. For + RFC publication, the normal RFC review process is expected + to provide the necessary review for interoperability, though + the Designated Expert may be a particularly well-qualified + person to perform such a review. + + Examples: Diffserv-aware TE Bandwidth Constraints Model + Identifiers [RFC4124], TLS ClientCertificateType Identifiers + [RFC4346], ROHC Profile Identifiers [RFC4995]. + + RFC Required - RFC publication (either as an IETF submission or as + an RFC Editor Independent submission [RFC3932]) suffices. + Unless otherwise specified, any type of RFC is sufficient + (e.g., Informational, Experimental, Standards Track, etc.). + + + + + + + + +Narten & Alvestrand Best Current Practice [Page 10] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + + IETF Review - (Formerly called "IETF Consensus" in + [IANA-CONSIDERATIONS]) New values are assigned only through + RFCs that have been shepherded through the IESG as AD- + Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The + intention is that the document and proposed assignment will + be reviewed by the IESG and appropriate IETF WGs (or + experts, if suitable working groups no longer exist) to + ensure that the proposed assignment will not negatively + impact interoperability or otherwise extend IETF protocols + in an inappropriate or damaging manner. + + To ensure adequate community review, such documents are + shepherded through the IESG as AD-sponsored (or WG) + documents with an IETF Last Call. + + Examples: IPSECKEY Algorithm Types [RFC4025], + Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS + Handshake Hello Extensions [RFC4366]. + + Standards Action - Values are assigned only for Standards Track + RFCs approved by the IESG. + + Examples: BGP message types [RFC4271], Mobile Node + Identifier option types [RFC4283], DCCP Packet Types + [RFC4340]. + + IESG Approval - New assignments may be approved by the IESG. + Although there is no requirement that the request be + documented in an RFC, the IESG has discretion to request + documents or other supporting materials on a case-by-case + basis. + + IESG Approval is not intended to be used often or as a + "common case"; indeed, it has seldom been used in practice + during the period RFC 2434 was in effect. Rather, it is + intended to be available in conjunction with other policies + as a fall-back mechanism in the case where one of the other + allowable approval mechanisms cannot be employed in a timely + fashion or for some other compelling reason. IESG Approval + is not intended to circumvent the public review processes + implied by other policies that could have been employed for + a particular assignment. IESG Approval would be + appropriate, however, in cases where expediency is desired + and there is strong consensus for making the assignment + (e.g., WG consensus). + + + + + + +Narten & Alvestrand Best Current Practice [Page 11] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + + The following guidelines are suggested for any evaluation + under IESG Approval: + + - The IESG can (and should) reject a request if another path + for registration is available that is more appropriate and + there is no compelling reason to use that path. + + - Before approving a request, the community should be + consulted, via a "call for comments" that provides as much + information as is reasonably possible about the request. + + Examples: IPv4 Multicast address assignments [RFC3171], IPv4 + IGMP Type and Code values [RFC3228], Mobile IPv6 Mobility + Header Type and Option values [RFC3775]. + + It should be noted that it often makes sense to partition a namespace + into multiple categories, with assignments within each category + handled differently. For example, many protocols now partition + namespaces into two (or even more) parts, where one range is reserved + for Private or Experimental Use, while other ranges are reserved for + globally unique assignments assigned following some review process. + Dividing a namespace into ranges makes it possible to have different + policies in place for different ranges. + + Examples: LDAP [RFC4520], Pseudowire Edge to Edge Emulation (PWE3) + [RFC4446]. + +4.2. What to Put in Documents That Create a Registry + + The previous sections presented some issues that should be considered + in formulating a policy for assigning values in namespaces. It is + the working group and/or document author's job to formulate an + appropriate policy and specify it in the appropriate document. In + almost all cases, having an explicit "IANA Considerations" section is + appropriate. The following and later sections define what is needed + for the different types of IANA actions. + + Documents that create a new namespace (or modify the definition of an + existing space) and that expect IANA to play a role in maintaining + that space (e.g., serving as a repository for registered values) MUST + provide clear instructions on details of the namespace. In + particular, instructions MUST include: + + 1) The name of the registry (or sub-registry) being created and/or + maintained. The name will appear on the IANA web page and will + be referred to in future documents that need to allocate a + value from the new space. The full name (and abbreviation, if + appropriate) should be provided. It is highly desirable that + + + +Narten & Alvestrand Best Current Practice [Page 12] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + + the chosen name not be easily confusable with the name of + another registry. When creating a sub-registry, the registry + that it is a part of should be clearly identified. When + referring to an already existing registry, providing a URL to + precisely identify the registry is helpful. All such URLs, + however, will be removed from the RFC prior to final + publication. For example, documents could contain: [TO BE + REMOVED: This registration should take place at the following + location: http://www.iana.org/assignments/foobar-registry] + + 2) What information must be provided as part of a request in order + to assign a new value. This information may include the need + to document relevant security considerations, if any. + + 3) The review process that will apply to all future requests for a + value from the namespace. + + Note: When a Designated Expert is used, documents MUST NOT name + the Designated Expert in the document itself; instead, the name + should be relayed to the appropriate Area Director at the time + the document is sent to the IESG for approval. + + If the request should also be reviewed on a specific public + mailing list (such as the ietf-types@iana.org for media types), + that mailing address should be specified. Note, however, that + when mailing lists are specified, the requirement for a + Designated Expert MUST also be specified (see Section 3). + + If IANA is expected to make assignments without requiring an + outside review, sufficient guidance MUST be provided so that + the requests can be evaluated with minimal subjectivity. + + 4) The size, format, and syntax of registry entries. When + creating a new name/number space, authors must describe any + technical requirements on registry (and sub-registry) values + (e.g., valid ranges for integers, length limitations on + strings, etc.) as well as the exact format in which registry + values should be displayed. For number assignments, one should + specify whether values are to be recorded in decimal, + hexadecimal, or some other format. For strings, the encoding + format should be specified (e.g., ASCII, UTF8, etc.). Authors + should also clearly specify what fields to record in the + registry. + + 5) Initial assignments and reservations. Clear instructions + should be provided to identify any initial assignments or + registrations. In addition, any ranges that are to be reserved + + + + +Narten & Alvestrand Best Current Practice [Page 13] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + + for "Private Use", "Reserved", "Unassigned", etc. should be + clearly indicated. + + When specifying the process for making future assignments, it is + quite acceptable to pick one (or more) of the example policies listed + in Section 4.1 and refer to it by name. Indeed, this is the + preferred mechanism in those cases where the sample policies provide + the desired level of review. It is also acceptable to cite one of + the above policies and include additional guidelines for what kind of + considerations should be taken into account by the review process. + For example, RADIUS [RFC3575] specifies the use of a Designated + Expert, but includes specific additional criteria the Designated + Expert should follow. + + For example, a document could say something like: + + This document defines a new DHCP option, entitled "FooBar" (see + Section y), assigned a value of TBD1 from the DHCP Option space + [to be removed upon publication: + http://www.iana.org/assignments/bootp-dhcp-parameters] + [DHCP-OPTIONS] [DHCP-IANA]: + + Data + Tag Name Length Meaning + ---- ---- ------ ------- + TBD1 FooBar N FooBar server + + The FooBar option also defines an 8-bit FooType field, for which + IANA is to create and maintain a new sub-registry entitled + "FooType values" under the FooBar option. Initial values for the + DHCP FooBar FooType registry are given below; future assignments + are to be made through Expert Review [IANA-CONSIDERATIONS]. + Assignments consist of a DHCP FooBar FooType name and its + associated value. + + Value DHCP FooBar FooType Name Definition + ---- ------------------------ ---------- + 0 Reserved + 1 Frobnitz See Section y.1 + 2 NitzFrob See Section y.2 + 3-254 Unassigned + 255 Reserved + + For examples of documents that provide detailed guidance to IANA + on the issue of assigning numbers, consult [RFC2929], [RFC3575], + [RFC3968], and [RFC4520]. + + + + + +Narten & Alvestrand Best Current Practice [Page 14] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + +4.3. Updating IANA Guidelines for Existing Registries + + Updating the registration process for an already existing (i.e., + previously created) namespace (whether created explicitly or + implicitly) follows a process similar to that used when creating a + new namespace. That is, a document is produced that makes reference + to the existing namespace and then provides detailed guidelines for + handling assignments in each individual namespace. Such documents + are normally processed as Best Current Practices (BCPs) + [IETF-PROCESS]. + + Example documents that updated the guidelines for managing (then) + pre-existing registries include: [RFC2929], [RFC3228], and [RFC3575]. + +5. Registering New Values in an Existing Registry + +5.1. What to Put in Documents When Registering Values + + Often, documents request an assignment from an already existing + namespace (i.e., one created by a previously published RFC). In such + cases: + + - Documents should clearly identify the namespace in which each + value is to be registered. If the registration goes into a + sub-registry, the author should clearly describe where the + assignment or registration should go. It is helpful to use the + exact namespace name as listed on the IANA web page (and + defining RFC), and cite the RFC where the namespace is defined. + + Note 1: There is no need to mention what the assignment policy + for new assignments is, as that should be clear from the + references. + + Note 2: When referring to an existing registry, providing a URL + to precisely identify the registry is helpful. Such URLs, + however, should usually be removed from the RFC prior to final + publication, since IANA URLs are not guaranteed to be stable in + the future. In cases where it is important to include a URL in + the document, IANA should concur on its inclusion. + + As an example, documents could contain: [TO BE REMOVED: This + registration should take place at the following location: + http://www.iana.org/assignments/foobar-registry] + + - Each value requested should be given a unique reference. When + the value is numeric, use the notation: TBD1, TBD2, etc. + Throughout the document where an actual IANA-assigned value + should be filled in, use the "TBDx" notation. This helps ensure + + + +Narten & Alvestrand Best Current Practice [Page 15] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + + that the final RFC has the correct assigned values inserted in + all of the relevant places where the value is expected to appear + in the final document. For values that are text strings, a + specific name can be suggested. IANA will normally assign the + name, unless it conflicts with a name already in use. + + - Normally, the values to be used are chosen by IANA and documents + should specify values of "TBD". However, in some cases, a value + may have been used for testing or in early implementations. In + such cases, it is acceptable to include text suggesting what + specific value should be used (together with the reason for the + choice). For example, one might include the text "the value XXX + is suggested as it is used in implementations". However, it + should be noted that suggested values are just that; IANA will + attempt to assign them, but may find that impossible, if the + proposed number has already been assigned for some other use. + + For some registries, IANA has a long-standing policy prohibiting + assignment of names or codes on a vanity or organization name + basis, e.g., codes are always assigned sequentially unless there + is a strong reason for making an exception. Nothing in this + document is intended to change those policies or prevent their + future application. + + - The IANA Considerations section should summarize all of the IANA + actions, with pointers to the relevant sections elsewhere in the + document as appropriate. When multiple values are requested, it + is generally helpful to include a summary table. It is also + helpful for this table to be in the same format as it should + appear on the IANA web site. For example: + + Value Description Reference + -------- ------------------- --------- + TBD1 Foobar [RFCXXXX] + + Note: In cases where authors feel that including the full table is + too verbose or repetitive, authors should still include the table, + but may include a note asking that the table be removed prior to + publication of the final RFC. + + As an example, the following text could be used to request assignment + of a DHCPv6 option number: + + IANA has assigned an option code value of TBD1 to the DNS + Recursive Name Server option and an option code value of TBD2 to + the Domain Search List option from the DHCP option code space + defined in Section 24.3 of RFC 3315. + + + + +Narten & Alvestrand Best Current Practice [Page 16] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + +5.2. Updating Registrations + + Registrations are a request to assign a new value, including the + related information needed to evaluate and document the request. + Even after a number has been assigned, some types of registrations + contain additional information that may need to be updated over time. + For example, MIME media types, character sets, and language tags, + etc. typically include more information than just the registered + value itself. Example information can include point-of-contact + information, security issues, pointers to updates, literature + references, etc. In such cases, the document defining the namespace + must clearly state who is responsible for maintaining and updating a + registration. In different cases, it may be appropriate to specify + one or more of the following: + + - Let the author update the registration, subject to the same + constraints and review as with new registrations. + + - Allow some mechanism to attach comments to the registration, for + cases where others have significant objections to claims in a + registration, but the author does not agree to change the + registration. + + - Designate the IESG, a Designated Expert, or another entity as + having the right to change the registrant associated with a + registration and any requirements or conditions on doing so. + This is mainly to get around the problem when a registrant + cannot be reached in order to make necessary updates. + +5.3. Overriding Registration Procedures + + Since RFC 2434 was published, experience has shown that the + documented IANA considerations for individual protocols do not always + adequately cover the reality after the protocol is deployed. For + example, many older routing protocols do not have documented, + detailed IANA considerations. In addition, documented IANA + considerations are sometimes found to be too stringent to allow even + working group documents (for which there is strong consensus) to + obtain code points from IANA in advance of actual RFC publication. + In other cases, the documented procedures are unclear or neglected to + cover all the cases. In order to allow assignments in individual + cases where there is strong IETF consensus that an allocation should + go forward, but the documented procedures do not support such an + assignment, the IESG is granted authority to approve assignments in + such cases. The intention is not to overrule properly documented + procedures, or to obviate the need for protocols to properly document + their IANA considerations. Instead, the intention is to permit + assignments in individual cases where it is obvious that the + + + +Narten & Alvestrand Best Current Practice [Page 17] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + + assignment should just be made, but updating the IANA process just to + assign a particular code point is viewed as too heavy a burden. + + In general, the IETF would like to see deficient IANA registration + procedures for a namespace revised through the IETF standards + process, but not at the cost of unreasonable delay for needed + assignments. If the IESG has had to take the action in this section, + it is a strong indicator that the IANA registration procedures should + be updated, possibly in parallel with ongoing protocol work. + +6. Miscellaneous Issues + +6.1. When There Are No IANA Actions + + Before an Internet-Draft can be published as an RFC, IANA needs to + know what actions (if any) it needs to perform. Experience has shown + that it is not always immediately obvious whether a document has no + IANA actions, without reviewing the document in some detail. In + order to make it clear to IANA that it has no actions to perform (and + that the author has consciously made such a determination), such + documents should include an IANA Considerations section that states: + + This document has no IANA actions. + + This statement, or an equivalent, must only be inserted after the WG + or individual submitter has carefully verified it to be true. Using + such wording as a matter of "boilerplate" or without careful + consideration can lead to incomplete or incorrect IANA actions being + performed. + + If a specification makes use of values from a namespace that is not + managed by IANA, it may be useful to note this fact, e.g., with + wording such as: + + 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. + + In some cases, the absence of IANA-assigned values may be considered + valuable information for future readers; in other cases, it may be + considered of no value once the document has been approved, and may + be removed before archival publication. This choice should be made + clear in the draft, for example, by including a sentence such as + + [RFC Editor: please remove this section prior to publication.] + + or + + + + +Narten & Alvestrand Best Current Practice [Page 18] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + + [RFC Editor: please do not remove this section.] + +6.2. Namespaces Lacking Documented Guidance + + For all existing RFCs that either explicitly or implicitly rely on + IANA to evaluate assignments without specifying a precise evaluation + policy, IANA (in consultation with the IESG) will continue to decide + what policy is appropriate. Changes to existing policies can always + be initiated through the normal IETF consensus process. + + All future RFCs that either explicitly or implicitly rely on IANA to + register or otherwise manage namespace assignments MUST provide + guidelines for managing the namespace. + +6.3. After-the-Fact Registrations + + Occasionally, IANA becomes aware that an unassigned value from a + managed namespace is in use on the Internet or that an assigned value + is being used for a different purpose than originally registered. + IANA will not condone such misuse; i.e., procedures of the type + described in this document MUST be applied to such cases. In the + absence of specifications to the contrary, values may only be + reassigned for a different purpose with the consent of the original + assignee (when possible) and with due consideration of the impact of + such a reassignment. In cases of likely controversy, consultation + with the IESG is advised. + +6.4. Reclaiming Assigned Values + + Reclaiming previously assigned values for reuse is tricky, because + doing so can lead to interoperability problems with deployed systems + still using the assigned values. Moreover, it can be extremely + difficult to determine the extent of deployment of systems making use + of a particular value. However, in cases where the namespace is + running out of unassigned values and additional ones are needed, it + may be desirable to attempt to reclaim unused values. When + reclaiming unused values, the following (at a minimum) should be + considered: + + - Attempts should be made to contact the original party to which a + value is assigned, to determine if the value was ever used, and + if so, the extent of deployment. (In some cases, products were + never shipped or have long ceased being used. In other cases, + it may be known that a value was never actually used at all.) + + + + + + + +Narten & Alvestrand Best Current Practice [Page 19] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + + - Reassignments should not normally be made without the + concurrence of the original requester. Reclamation under such + conditions should only take place where there is strong evidence + that a value is not widely used, and the need to reclaim the + value outweighs the cost of a hostile reclamation. In any case, + IESG Approval is needed in this case. + + - It may be appropriate to write up the proposed action and + solicit comments from relevant user communities. In some cases, + it may be appropriate to write an RFC that goes through a formal + IETF process (including IETF Last Call) as was done when DHCP + reclaimed some of its "Private Use" options [RFC3942]. + +7. Appeals + + Appeals of registration decisions made by IANA can be made using the + normal IETF appeals process as described in Section 6.5 of + [IETF-PROCESS]. Specifically, appeals should be directed to the + IESG, followed (if necessary) by an appeal to the IAB, etc. + +8. Mailing Lists + + All IETF mailing lists associated with evaluating or discussing + assignment requests as described in this document are subject to + whatever rules of conduct and methods of list management are + currently defined by Best Current Practices or by IESG decision. + +9. Security Considerations + + Information that creates or updates a registration needs to be + authenticated and authorized. IANA updates registries according to + instructions in published RFCs and from the IESG. It also may accept + clarifications from document authors, relevant WG chairs, Designated + Experts, and mail list participants, too. + + Information concerning possible security vulnerabilities of a + protocol may change over time. Likewise, security vulnerabilities + related to how an assigned number is used (e.g., if it identifies a + protocol) may change as well. As new vulnerabilities are discovered, + information about such vulnerabilities may need to be attached to + existing registrations, so that users are not misled as to the true + security issues surrounding the use of a registered number. + + An analysis of security issues is generally required for all + protocols that make use of parameters (data types, operation codes, + keywords, etc.) used in IETF protocols or registered by IANA. Such + security considerations are usually included in the protocol document + [RFC3552]. It is the responsibility of the IANA considerations + + + +Narten & Alvestrand Best Current Practice [Page 20] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + + associated with a particular registry to specify what (if any) + security considerations must be provided when assigning new values, + and the process for reviewing such claims. + +10. Changes Relative to RFC 2434 + + Changes include: + + - Major reordering of text to expand descriptions and to better + group topics such as "updating registries" vs. "creating new + registries", in order to make it easier for authors to find the + text most applicable to their needs. + + - Numerous editorial changes to improve readability. + + - Changed the term "IETF Consensus" to "IETF Review" and added + more clarifications. History has shown that people see the + words "IETF Consensus" (without consulting the actual + definition) and are quick to make incorrect assumptions about + what the term means in the context of IANA Considerations. + + - Added "RFC Required" to list of defined policies. + + - Much more explicit directions and examples of "what to put in + RFCs". + + - "Specification Required" now implies use of a Designated Expert + to evaluate specs for sufficient clarity. + + - Significantly changed the wording in Section 3. Main purpose is + to make clear that Expert Reviewers are accountable to the + community, and to provide some guidance for review criteria in + the default case. + + - Changed wording to remove any special appeals path. The normal + RFC 2026 appeals path is used. + + - Added a section about reclaiming unused value. + + - Added a section on after-the-fact registrations. + + - Added a section indicating that mailing lists used to evaluate + possible assignments (e.g., by a Designated Expert) are subject + to normal IETF rules. + + + + + + + +Narten & Alvestrand Best Current Practice [Page 21] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + +11. Acknowledgments + + This document has benefited from specific feedback from 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, and Bert Wijnen. + + The original acknowledgments section in RFC 2434 was: + + Jon Postel and Joyce Reynolds provided a detailed explanation on what + IANA needs in order to manage assignments efficiently, and patiently + provided comments on multiple versions of this document. Brian + Carpenter provided helpful comments on earlier versions of the + document. One paragraph in the Security Considerations section was + borrowed from [MIME-REG]. + +12. References + +12.1. Normative References + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to + Indicate Requirement Levels", BCP 14, RFC 2119, + March 1997. + +12.2. Informative References + + [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. + + + + + + +Narten & Alvestrand Best Current Practice [Page 22] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + + [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. + + + + + + + +Narten & Alvestrand Best Current Practice [Page 23] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + + [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. + + + +Narten & Alvestrand Best Current Practice [Page 24] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + + [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. + + + +Narten & Alvestrand Best Current Practice [Page 25] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + +Authors' Addresses + + 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Narten & Alvestrand Best Current Practice [Page 26] + +RFC 5226 IANA Considerations Section in RFCs May 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Narten & Alvestrand Best Current Practice [Page 27] + |