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".
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)
=5= |