summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2434.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2434.txt')
-rw-r--r--doc/rfc/rfc2434.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc2434.txt b/doc/rfc/rfc2434.txt
new file mode 100644
index 0000000..2146148
--- /dev/null
+++ b/doc/rfc/rfc2434.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group T. Narten
+Request for Comments: 2434 IBM
+BCP: 26 H. Alvestrand
+Category: Best Current Practice Maxware
+ October 1998
+
+
+ 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.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1998). All Rights Reserved.
+
+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
+ algorithm for IPSec). To insure that such quantities 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).
+
+ In order for the IANA to manage a given name space prudently, it
+ needs guidelines describing the conditions under which new values can
+ be assigned. If the IANA is expected to play a role in the management
+ of a name space, the 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 name space and provides guidelines to document authors on
+ the specific text that must be included in documents that place
+ demands on the IANA.
+
+
+
+
+
+
+
+
+
+
+
+Narten & Alvestrand Best Current Practice [Page 1]
+
+RFC 2434 Guidelines for IANA Considerations October 1998
+
+
+Table of Contents
+
+ Status of this Memo.......................................... 1
+ 1. Introduction............................................. 2
+ 2. Issues To Consider....................................... 3
+ 3. Registration maintenance................................. 6
+ 4. What To Put In Documents................................. 7
+ 5. Applicability to Past and Future RFCs.................... 8
+ 6. Security Considerations.................................. 8
+ 7. Acknowledgments.......................................... 9
+ 8. References............................................... 9
+ 9. Authors' Addresses....................................... 10
+ 10. Full Copyright Statement................................. 11
+
+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 types in mail messages [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] or a new encryption
+ or authentication algorithm for IPSec [IPSEC]). To insure 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).
+
+ In this document, we call the set of possible values for such a field
+ a "name space"; its actual content may be a name, a number or another
+ kind of value. The assignment of a specific value to a name space is
+ called an assigned number (or assigned value). Each assignment of a
+ number in a name space is called a registration.
+
+ In order for the IANA to manage a given name space prudently, it
+ needs guidelines describing the conditions under which new values
+ should be assigned. This document provides guidelines to authors on
+ what sort of text should be added to their documents, and reviews
+ issues that should be considered in formulating an appropriate policy
+ for assigning numbers to name spaces.
+
+ Not all name spaces require centralized administration. In some
+ cases, it is possible to delegate a name space in such a way that
+ further assignments can be made independently and with no further
+ (central) coordination. In the Domain Name System, for example, the
+ 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]. When a name space
+
+
+
+Narten & Alvestrand Best Current Practice [Page 2]
+
+RFC 2434 Guidelines for IANA Considerations October 1998
+
+
+ can be delegated, the IANA only deals with assignments at the top
+ level.
+
+ This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their
+ negatives, in the way described in RFC 2119 [KEYWORDS]. In this case,
+ "the specification" as used by RFC 2119 refers to the processing of
+ protocols being submitted to the IETF standards process.
+
+2. Issues To Consider
+
+ The primary issue to consider in managing a name space is its size.
+ If the space is small and limited in size, assignments must be made
+ carefully to insure that the space doesn't become exhausted. If the
+ space is essentially unlimited, on the other hand, it may be
+ perfectly reasonable to hand out new values to anyone that wants one.
+ Even when the space is essentially unlimited, however, it is usually
+ desirable to have a minimal review to prevent the hoarding of or
+ unnecessary wasting of a space. For example, if the space consists of
+ text strings, it may be desirable to prevent organizations from
+ obtaining large sets of strings that correspond to the "best" names
+ (e.g., existing company names).
+
+ A second consideration is whether it makes sense to delegate the name
+ space in some manner. This route should be pursued when appropriate,
+ as it lessens the burden on the IANA for dealing with assignments.
+
+ In some cases, the name space is essentially unlimited, and assigned
+ numbers can safely be given out to anyone. When no subjective review
+ is needed, the IANA can make assignments directly, provided that the
+ IANA is given specific instructions on what types of requests it
+ should grant, and what information must be provided before a request
+ for an assigned number will be considered. Note that the IANA will
+ not define an assignment policy; it should be given a set of
+ guidelines that allow it to make allocation decisions with little
+ subjectivity.
+
+ In most cases, some review of prospective allocations is appropriate,
+ and the question becomes who should perform the review and how
+ rigorous the review needs to be. In many cases, one might think that
+ an IETF Working Group (WG) familiar with the name space at hand
+ should be consulted. In practice, however, WGs eventually disband, so
+ they cannot be considered a permanent evaluator. It is also possible
+ for name spaces to be created through individual submission
+ documents, for which no WG is ever formed.
+
+ One way to insure community review of prospective assignments is to
+ have the requester submit a document for publication as an RFC. Such
+ an action insures that the IESG and relevant WGs review the
+
+
+
+Narten & Alvestrand Best Current Practice [Page 3]
+
+RFC 2434 Guidelines for IANA Considerations October 1998
+
+
+ assignment. This is the preferred way of insuring review, and is
+ particularly important if any potential interoperability issues can
+ arise. For example, many 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 to give advice for persons who want help in understanding what a
+ proper registration should contain.
+
+ While discussion on a mailing list can provide valuable technical
+ expertise, opinions may vary and discussions may continue for some
+ time without resolution. In addition, the IANA cannot participate in
+ all of these mailing lists and cannot determine if or when such
+ discussions reach consensus. Therefore, the IANA cannot allow
+ general mailing lists to fill the role of providing definitive
+ recommendations regarding a registration question. Instead, the IANA
+ will use a designated subject matter expert. The IANA will rely on a
+ "designated expert" to advise it in assignment matters. That is, the
+ IANA forwards the requests it receives to a specific point-of-contact
+ (one or a small number of individuals) and acts upon the returned
+ recommendation from the designated expert. The designated expert can
+ initiate and coordinate as wide a review of an assignment request as
+ may be necessary to evaluate it properly.
+
+ Designated experts are appointed by the relevant Area Director of the
+ IESG. They are typically named at the time a document that creates a
+ new numbering space is published as an RFC, but as experts originally
+ appointed may later become unavailable, the relevant Area Director
+ will appoint replacements if necessary.
+
+ Any decisions made by the designated expert can be appealed using the
+ normal IETF appeals process as outlined in Section 6.5 of [IETF-
+ PROCESS]. Since the designated experts are appointed by the IESG,
+ they may be removed by the IESG.
+
+
+
+
+
+
+
+
+Narten & Alvestrand Best Current Practice [Page 4]
+
+RFC 2434 Guidelines for IANA Considerations October 1998
+
+
+ The following are example policies, some of which are in use today:
+
+ 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 and assignments are not generally useful for
+ interoperability.
+
+ Examples: Site-specific options in DHCP [DHCP] have
+ significance only within a single site. "X-foo:" header
+ lines in email messages.
+
+ Hierarchical allocation - Delegated managers can assign values
+ provided they have been given control over that part of the
+ name space. IANA controls the higher levels of the namespace
+ according to one of the other policies.
+
+ Examples: DNS names, Object Identifiers
+
+ First Come First Served - Anyone can obtain an assigned number, so
+ long as they provide a point of contact and a brief
+ description of what the value would be used for. For
+ numbers, the exact value is generally assigned by the IANA;
+ with names, specific names are usually requested.
+
+ Examples: vnd. (vendor assigned) MIME types [MIME-REG], TCP
+ and UDP port numbers.
+
+ Expert Review - approval by a Designated Expert is required.
+
+ Specification Required - Values and their meaning must be
+ documented in an RFC or other permanent and readily available
+ reference, in sufficient detail so that interoperability
+ between independent implementations is possible.
+
+ Examples: SCSP [SCSP]
+
+ IESG Approval - New assignments must be approved by the IESG, but
+ there is no requirement that the request be documented in an
+ RFC (though the IESG has discretion to request documents or
+ other supporting materials on a case-by-case basis).
+
+
+
+
+
+
+
+
+
+Narten & Alvestrand Best Current Practice [Page 5]
+
+RFC 2434 Guidelines for IANA Considerations October 1998
+
+
+ IETF Consensus - New values are assigned through the IETF
+ consensus process. Specifically, new assignments are made via
+ RFCs approved by the IESG. Typically, the IESG will seek
+ input on prospective assignments from appropriate persons
+ (e.g., a relevant Working Group if one exists).
+
+ Examples: SMTP extensions [SMTP-EXT], BGP Subsequent Address
+ Family Identifiers [BGP4-EXT].
+
+ Standards Action - Values are assigned only for Standards Track
+ RFCs approved by the IESG.
+
+ Examples: MIME top level types [MIME-REG]
+
+ It should be noted that it often makes sense to partition a name
+ space into several categories, with assignments out of each category
+ handled differently. For example, the DHCP option space [DHCP] is
+ split into two parts. Option numbers in the range of 1-127 are
+ globally unique and assigned according to the Specification Required
+ policy described above, while options number 128-254 are "site
+ specific", i.e., Local Use. Dividing the name space up makes it
+ possible to allow some assignments to be made with minimal review,
+ while simultaneously reserving some part of the space for future use.
+
+3. Registration maintenance
+
+ Registrations are a request for an assigned number, 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 types, character sets, 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 must clearly state who is responsible for
+ maintaining and updating a registration. It is appropriate to:
+
+ - 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.
+
+
+
+
+
+
+
+Narten & Alvestrand Best Current Practice [Page 6]
+
+RFC 2434 Guidelines for IANA Considerations October 1998
+
+
+ - Designate the IESG or another authority as having the right to
+ reassign ownership of a registration. This is mainly to get
+ around the problem when some registration owner cannot be
+ reached in order to make necessary updates.
+
+4. What To Put In Documents
+
+ The previous sections presented some issues that should be considered
+ in formulating a policy for assigning well-known numbers and other
+ protocol constants. It is the Working Group and/or document author's
+ job to formulate an appropriate policy and specify it in the
+ appropriate document. In some cases, having an "IANA Considerations"
+ section may be appropriate. Specifically, documents that create an
+ name space (or modify the definition of an existing space) and that
+ expect the IANA to play a role in maintaining that space (e.g.,
+ serving as a repository for registered values) MUST document the
+ process through which future assignments are made. Such a section
+ MUST state clearly:
+
+ - whether or not an application for an assigned number needs to be
+ reviewed. If review is necessary, the review mechanism MUST be
+ specified. 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 IESG 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
+ use of a Designated Expert MUST also be specified.
+
+ - if the 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.
+
+ Authors SHOULD attempt to provide guidelines that allow the IANA to
+ assign new values directly without requiring review by a Designated
+ Expert. This can be done easily in many cases by designating a range
+ of values for direct assignment by the IANA while simultaneously
+ reserving a sufficient portion of the name space for future use by
+ requiring that assignments from that space be made only after a more
+ stringent review.
+
+ Finally, it is quite acceptable to pick one of the example policies
+ cited above and refer to it by name. For example, a document could
+ say something like:
+
+
+
+
+
+Narten & Alvestrand Best Current Practice [Page 7]
+
+RFC 2434 Guidelines for IANA Considerations October 1998
+
+
+ Following the policies outlined in [IANA-CONSIDERATIONS],
+ numbers in the range 0-63 are allocated as First Come First
+ Served, numbers between 64-240 are allocated through an IETF
+ Consensus action and values in the range 241-255 are reserved
+ for Private Use.
+
+ For examples of documents that provide good and detailed guidance to
+ the IANA on the issue of assigning numbers, consult [MIME-REG, MIME-
+ LANG].
+
+5. Applicability to Past and Future RFCs
+
+ For all existing RFCs that either explicitly or implicitly rely on
+ the IANA to evaluate assignments without specifying a precise
+ evaluation policy, the IANA will continue to decide what policy is
+ appropriate. The default policy has been first come, first served.
+ Changes to existing policies can always be initiated through the
+ normal IETF consensus process.
+
+ All future RFCs that either explicitly or implicitly rely on the IANA
+ to register or otherwise manage assignments MUST provide guidelines
+ for managing the name space.
+
+6. Security Considerations
+
+ Information that creates or updates a registration needs to be
+ authenticated.
+
+ 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 mislead as to the true
+ security issues surrounding the use of a registered number.
+
+ An analysis of security issues is required for all parameters (data
+ types, operation codes, keywords, etc.) used in IETF protocols or
+ registered by the IANA. All descriptions of security issues must be
+ as accurate as possible regardless of level of registration. In
+ particular, a statement that there are "no security issues associated
+ with this type" must not given when it would be more accurate to
+ state that "the security issues associated with this type have not
+ been assessed".
+
+
+
+
+
+
+
+Narten & Alvestrand Best Current Practice [Page 8]
+
+RFC 2434 Guidelines for IANA Considerations October 1998
+
+
+7. Acknowledgments
+
+ Jon Postel and Joyce K. Reynolds provided a detailed explanation on
+ what the 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].
+
+8. References
+
+ [ASSIGNED] Reynolds, J., and J. Postel, "Assigned
+ Numbers", STD 2, RFC 1700, October 1994. See
+ also: http://www.iana.org/numbers.html
+
+ [BGP4-EXT] Bates. T., Chandra, R., Katz, D. and Y.
+ Rekhter, "Multiprotocol Extensions for BGP-4",
+ RFC 2283, February 1998.
+
+ [DHCP-OPTIONS] Alexander, S. and R. Droms, "DHCP Options and
+ BOOTP Vendor Extensions", RFC 2132, March 1997.
+
+ [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
+ Writing an IANA Considerations Section in
+ RFCs", BCP 26, RFC 2434, October 1998.
+
+ [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] Atkinson, R., "Security Architecture for the
+ Internet Protocol", RFC 1825, August 1995.
+
+ [KEYWORDS] Bradner, S., "Key words for use in RFCs to
+ Indicate Requirement Levels", BCP 14, RFC 2119,
+ March 1997.
+
+ [MIME-LANG] Freed, N. and K. Moore, "MIME Parameter Value
+ and Encoded Word Extensions: Character Sets,
+ Languages, and Continuations", RFC 2184, August
+ 1997.
+
+ [MIME-REG] Freed, N., Klensin, J. and J. Postel,
+ "Multipurpose Internet Mail Extension (MIME)
+ Part Four: Registration Procedures", RFC 2048,
+ November 1996.
+
+
+
+Narten & Alvestrand Best Current Practice [Page 9]
+
+RFC 2434 Guidelines for IANA Considerations October 1998
+
+
+ [SCSP] Luciani, J., Armitage, G. and J. Halpern,
+ "Server Cache Synchronization Protocol (SCSP)",
+ RFC 2334, April 1998.
+
+ [SMTP-EXT] Klensin, J., Freed, N., Rose, M., Stefferud, E.
+ and D. Crocker, "SMTP Service Extensions", RFC
+ 1869, November 1995.
+
+9. 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@raleigh.ibm.com
+
+
+ Harald Tveit Alvestrand
+ Maxware
+ Pirsenteret
+ N-7005 Trondheim
+ Norway
+
+ Phone: +47 73 54 57 97
+ EMail: Harald@Alvestrand.no
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Narten & Alvestrand Best Current Practice [Page 10]
+
+RFC 2434 Guidelines for IANA Considerations October 1998
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998). 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 assigns.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Narten & Alvestrand Best Current Practice [Page 11]
+