rfc2434.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 620 行 · 第 1/2 页

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 [e-mail] 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: [phone]
   EMail: [e-mail]


   Harald Tveit Alvestrand
   Maxware
   Pirsenteret
   N-7005 Trondheim
   Norway

   Phone: [phone]
   EMail: [e-mail]























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]