doc: Add RFC documents

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]
+