One document matched: draft-klensin-iana-reg-policy-00.txt
Network Working Group J. Klensin
Internet-Draft
Expires: December 29, 2005 V. Cerf
MCI
S. Bradner
Harvard University
June 27, 2005
Registration Policies for the IETF and IANA
draft-klensin-iana-reg-policy-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 29, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
For many years, the IETF has maintained, via the IANA, registries of
protocol and parameter names and numbers. The primary purpose of
these registries is to ensure that different methods and options are
properly identified and distinguished. Registration of such names or
numbers generally does not necessarily imply approval of the
Klensin, et al. Expires December 29, 2005 [Page 1]
Internet-Draft Registration Policies June 2005
technology in the corresponding protocol. Instead, registration
represents the desire to keep distinct options identified, separated,
and public to avoid conflicts in use. In recent years, various
changes in the nature of the instructions given to the IANA,
increased perceptions of scarcity in the number spaces associated
with some of the parameters, and other issues have led to a shift in
emphasis from "registration to keep identifiers unique" toward
evaluations of the quality of proposals of and preferences among
protocols. This document argues that shift is undesirable. It
articulates and clarifies the principles that the reasons for
evaluation of registration requests is to ensure a minimum quality of
definition, that any assertions of scarcity to restrict registrations
must be accompanied by a plan for eliminating the scarcity problem,
and that, if such a plan is not possible, to establish criteria for
making decisions that are as specific and objective as possible.
This document is intended to update the general considerations of RFC
2434, the specific allocation rules of RFC 2780, and the evaluation
criteria associated with other documents that condition an IANA
registration on Expert Review with IESG oversight or on IESG or IETF
action.
[[NOTE IN DRAFT: The length of this abstract exceeds the RFC Editor's
recommended limits. It will be shortened in future versions, but the
longer one is believed to be helpful for I-D announcements, etc.]]
Klensin, et al. Expires December 29, 2005 [Page 2]
Internet-Draft Registration Policies June 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Registration Principle: Clarity of Definition . . . . . . . 6
3. Registration Principle: Allocating Scarcity . . . . . . . . 6
3.1 Scarcity in Parameter Spaces . . . . . . . . . . . . . . . 6
3.2 Scaling and Scarcity Reduction . . . . . . . . . . . . . . 7
4. Multiple category or arc registrations . . . . . . . . . . . 7
5. Interpretation of Requirements for IESG Review or
Standards Action . . . . . . . . . . . . . . . . . . . . . . 8
6. Internationalization Considerations . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 8
8. Security considerations . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1 Normative References . . . . . . . . . . . . . . . . . . 9
10.2 Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . 12
Klensin, et al. Expires December 29, 2005 [Page 3]
Internet-Draft Registration Policies June 2005
1. Introduction
For many years, the IETF has maintained, via the IANA registries of
protocol and parameter names and numbers. The original purpose of
these registries was to ensure that different methods and options are
properly identified and distinguished. Registration did not imply
approval of the technology in the corresponding protocol. Instead,
registration represented only the desire to keep distinct options
identified, separated, and public to avoid conflicts.
In recent years, the previous very general instructions to the IANA
about registrations have been superceded by the inclusion of specific
instructions in RFCs that define IETF protocols. These instructions
have included rules for the establishment of the relevant registries
themselves and details on how requests should be submitted, and new
values defined, for any paramaters defined by the RFC. In addition a
number of RFCs have been produced to provide instructions for IETF
protocols that were defined before such instructions began to be
included. Examples of those RFCs of registration instructions
include [RFC2780], [RFC2939], [RFC3171], [RFC3228], [RFC3383],
[RFC3438], [RFC3474], [RFC3475], [RFC3476], [RFC3575], [RFC3737],
[RFC3818], [RFC3968], and [RFC3969]. These instructions, coupled
with increased perceptions of scarcity in the number spaces
associated with some parameters, have led to a shift in emphasis from
"registration to keep identifiers unique" and toward evaluations of
the quality of proposals and preferences about protocol design.
The distinction between requiring clarity and lack of obvious
conflict in a registration and blocking on unless the quality of the
underlying protocol was adequate was, in retrospect, further muddied
by [RFC2434] (which describes elements of the registration model) in
different places, as
o "To insure that such quantities have consistent values and
interpretations in different implementations, their assignment
must be administered by a central authority." (abstract, repeated
in first paragraph of section 1)
o "... preferred way of insuring review, and is particularly
important if any potential interoperability issues can arise.
[...] 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." (section 2)
o "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." (section 2)
Klensin, et al. Expires December 29, 2005 [Page 4]
Internet-Draft Registration Policies June 2005
RFC 2434 was used as the primary guideline for the RFCs listed above
that define IANA considerations for particular protocols. All three
of the above statements are consistent with other text in RFC 2434,
but the intent of the review is left open. In other words, it
specifies how a review is to be performed, but not the criteria to be
used. The present document argues that the apparent recent shift
from "evaluate a registration request for clarity and to avoid
interoperability problems" is undesirable and explicitly sets out
evaluation principles for registrations. While it may be completely
reasonable to require some specific level of approval of a protocol
with an associated parameter value, especially when the specification
for that allocation explicitly designates IETF approval and
endorsement (see Section 4), this should not be used as a
justification to require "approval" of registrations in general. For
registrations, the principal reasons for review are to ensure
adequate quality in the definitions to permit interoperability, to
avoid redundant or spurious registrations, and to provide those who
request the registrations an opportunity for non-binding IETF
community advice on the nature of the parameters being proposed for
registration or the protocol elements associated with them. A
secondary, but still important, reason involves verification that the
proposed protocol does not contain elements that are likely to cause
serious harm to the Internet. However, the threshold for rejecting a
registration on the basis of "serious harm" should be very high and
represent broad and obvious community consensus. This is the case
first because there might otherwise be suspicion that a claim of harm
was being used to try to block an unpopular protocol or to give a
favored one some advantage. Second, from a registration standpoint,
the best way to handle a dangerous protocol may be to give it clear
and distinct parameter values so its effects can be easily and
accurately identified and quarantined.
This document articulates and clarifies the principles that (i) the
reasons for evaluation of registration requests is to ensure a
minimum quality of definition, (ii) any assertion of a danger to the
Internet or to the stable operation of other protocols (especially
IETF Standards Track ones) must by supported by a public discussion
to which all relevant parties can contribute, and (iii) that any
assertions of scarcity to restrict registrations MUST be accompanied
by a plan for eliminating the scarcity problem or a conclusion,
supported by IETF consensus, that it is not possible to do so and a
corresponding rationing plan for the remaining space. These
principles derive from the assumption that growth and innovation on
the Internet continue to be core values of the IETF and the Internet
community.
In summary, unless the "scarcity" rules of Section 3 apply, this
document updates all "IANA registration" documents and "IANA
Klensin, et al. Expires December 29, 2005 [Page 5]
Internet-Draft Registration Policies June 2005
considerations" sections of documents to clarify the point that
registration review is to focus on the issues above, rather than on
concerns about, e.g., whether one protocol approach is better than
another one.
2. Registration Principle: Clarity of Definition
By longstanding IANA tradition, almost all protocol number or
parameter registrations must be associated with a description of what
the parameter represents. As mentioned in RFC 2434, while those
descriptions are normally public, the IETF and IANA have sometimes
made provisions for non-public definitions. But, in all cases, the
definitions must be sufficiently clear to avoid any interoperability
problems. Over the years, IANA has regularly sent registration
requests back to the originator for clarification. Today, part of
the purpose of review of registration requests in the IETF is to make
determinations about whether an appropriate level of clarity has been
achieved and about whether the documentation supplied is adequate.
3. Registration Principle: Allocating Scarcity
As suggested in section 2 of [RFC2434], the size of a name space in
which parameters are to be allocated determines whether care must be
taken "to insure that the space doesn't become exhausted". However,
that level of care MUST NOT be interpreted or implemented in an
attempt to apply a single standard of taste or style to the Internet
or otherwise as a mechanism for attempting to suppress innovation. A
limited space requires diligent evaluation of requests to avoid
spurious or vanity registrations and unnecessary ones, including
registrations that are unlikely to ever be used. However, unless
extraordinary circumstances arise, such evaluation must be carried
out on the assumption that the size of the name space is, and will
remain, adequate for all legitimate registrations of values that will
be used with the associated protocols.
3.1 Scarcity in Parameter Spaces
The size requirements for a particular name space may occasionally be
underestimated, creating a requirement to minimize allocations and
registrations in that particular name space to avoid a clear danger
of running out of the space. If that situation arises for a
particular name space, and its existence is confirmed by the IESG
after an IETF review and Last Call as described in [RFC2026], then
new registrations may be temporarily restricted to those required to
meet the needs of IETF protocol development. However, such
restrictions MUST NOT be applied without initiation of a plan to
eliminate the scarcity, as discussed in the next subsection.
Klensin, et al. Expires December 29, 2005 [Page 6]
Internet-Draft Registration Policies June 2005
3.2 Scaling and Scarcity Reduction
Difficulties with scaling are always a significant risk factor on the
Internet, with regard to both protocol design and administrative
procedures. When a parameter field is of fixed length, estimates
must be made, sometimes under considerable uncertainty and with high
costs associated with incremental size, as to how much parameter
capacity is needed. If such an estimate is incorrect and a
significant danger arises of running out of space, "conservation",
i.e., restrictions on registrations or allocations to save space,
will delay the date on which no further space is available, but will
not eliminate the risk of that occurring. Because of the damaging
effects on Internet innovation of rejecting otherwise-legitimate
registrations because of name space exhaustion, a decision that a
name space is facing a capacity crisis MUST BE made explicitly by the
community, as outlined above, and MUST BE associated with a plan to
expand the relevant name space unless that is deemed to be infeasible
(see below). A plan to expand the name space MAY take the form of
chartering a Working Group or creating an IAB workshop to develop a
plan within an appropriate time, or other approaches may be used.
A determination that the expansion of a name space is infeasible MUST
include criteria for making allocations in the balance of the
existing space and those criteria must be fair and balanced. The
determination of infeasbility and the allocation plan MUST represent
the consensus of the IETF community, determined through the same
mechanisms used to approve a document as a BCP (see [RFC2026]).
It is the explicit intent of this specification that registration
requests not be rejected for reasons of name space shortages unless
either an effort has been initiated to eliminate the shortage or a
formal determination has been made by the community that it is
infeasible to do so.
4. Multiple category or arc registrations
In a number of cases, registration procedures or protocols have
provided for registrations in a number of different categories, where
those categories are associated with different levels of requirements
for registration but where interoperability may be achieved by the
use of any of the categories. Examples of this approach include the
distinction between "user" and "system" port numbers most recently
described in [RFC2780] and the distinctions among the various
registration arcs for media type registrations described in
[RFC2048].
A decision by the IESG or other designated party to require that a
registration be made in a different arc or subsidiary name space than
Klensin, et al. Expires December 29, 2005 [Page 7]
Internet-Draft Registration Policies June 2005
was proposed is not to be considered a rejection of the registration
request under the terms of this document.
5. Interpretation of Requirements for IESG Review or Standards Action
A requirement for IESG approval, Standards Action, or RFC Publication
implies that IESG approval is an acceptable alternative to the other
two, not an exceptional case unless the requirement contains
additional provisions specifying the conditions for IESG review and
approval. Because, for reasons discussed above, the action on a
registration request SHOULD BE to permit the registration unless
special circumstances apply, the IESG MUST NOT deny a registration
request for other than reasons of clarity without an IETF Last Call
and IETF consensus that the rejection is appropriate for identified
reasons consistent with those discussed in this document. If a
registration request is denied for any reason, that reason must be
stated explicitly and the decision may be appealed under the
procedures specified in [RFC2026] or its successor(s). Of course,
nothing in this document prevents an applicant from voluntarily
withdrawing a registration request should that be deemed appropriate.
6. Internationalization Considerations
This document specifies IETF procedures and does not interact with
internationalization.
7. IANA Considerations
This document specifies IETF and IESG considerations in recommending
actions to IANA. It recommends that, when the IETF concludes that
the protocol, extension, or option associated with a registration
request is problematic or dangerous, the entry in the IANA registry
should be annotated to identify the concern and, when appropriate,
point to documentation or other materials that will better explain
the concern or alternatives that might be less problematic. While
this document specifies no particular registry actions for IANA, IANA
should be prepared for requests from the IETF to annotate registry
entries in that way.
8. Security considerations
This document specifies IETF procedures. It should have no direct
impact on Internet security. It does, however, firmly advocate the
principle that it is preferable for options or extensions that could
pose security or operational risks to be throughly documented and
carefully identified in preference to hiding them and hoping that
they will disappear.
Klensin, et al. Expires December 29, 2005 [Page 8]
Internet-Draft Registration Policies June 2005
9. Acknowledgements
Comments were received on discussion leading to this document, or on
a preliminary draft, from Bob Braden, Dave Crocker, Spencer Dawkins,
Ned Freed, John Loughney, and others that contributed to text in this
document and are greatly appreciated.
10. References
10.1 Normative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels'", RFC 2119, March 1997.
10.2 Informative References
[RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedures", BCP 13, RFC 2048, November 1996.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers",
BCP 37, RFC 2780, March 2000.
[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition
of New DHCP Options and Message Types", BCP 43, RFC 2939,
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.
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP)
Klensin, et al. Expires December 29, 2005 [Page 9]
Internet-Draft Registration Policies June 2005
Internet Assigned Numbers Authority (IANA) Considerations
Update", BCP 68, RFC 3438, December 2002.
[RFC3474] Lin, Z. and D. Pendarakis, "Documentation of IANA
assignments for Generalized MultiProtocol Label Switching
(GMPLS) Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) Usage and Extensions for
Automatically Switched Optical Network (ASON)", RFC 3474,
March 2003.
[RFC3475] Aboul-Magd, O., "Documentation of IANA assignments for
Constraint-Based LSP setup using LDP (CR-LDP) Extensions
for Automatic Switched Optical Network (ASON)", RFC 3475,
March 2003.
[RFC3476] Rajagopalan, B., "Documentation of IANA Assignments for
Label Distribution Protocol (LDP), Resource ReSerVation
Protocol (RSVP), and Resource ReSerVation Protocol-Traffic
Engineering (RSVP-TE) Extensions for Optical UNI
Signaling", RFC 3476, March 2003.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575,
July 2003.
[RFC3737] Wijnen, B. and A. Bierman, "IANA Guidelines for the
Registry of Remote Monitoring (RMON) MIB modules",
RFC 3737, April 2004.
[RFC3818] Schryver, V., "IANA Considerations for the Point-to-Point
Protocol (PPP)", BCP 88, RFC 3818, June 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.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Uniform Resource Identifier (URI) Parameter
Registry for the Session Initiation Protocol (SIP)",
BCP 99, RFC 3969, December 2004.
Klensin, et al. Expires December 29, 2005 [Page 10]
Internet-Draft Registration Policies June 2005
Authors' Addresses
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 491 5735
Email: john-ietf@jck.com
Vinton G. Cerf
MCI
22001 Loudoun County Parkway, F2-4115
Ashburn, VA 20147
USA
Phone: +1 703 886 1690
Email: vinton.g.cerf@mci.com
Scott Bradner
Harvard University
29 Oxford St
Cambridge, MA 02138
US
Phone: +1 617 495 3864
Email: sob@harvard.edu
Klensin, et al. Expires December 29, 2005 [Page 11]
Internet-Draft Registration Policies June 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Klensin, et al. Expires December 29, 2005 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-26 11:24:36 |