Internet DRAFT - draft-leiba-iana-policy-update
draft-leiba-iana-policy-update
Network Working Group B. Leiba
Internet-Draft Huawei Technologies
Updates: 5226 (if approved) April 24, 2012
Intended status: BCP
Expires: October 26, 2012
Update of and Clarification to IANA Policy Definitions in BCP 26
draft-leiba-iana-policy-update-02
Abstract
Section 4.1 of BCP 26 (RFC 5226) discusses possible IANA registration
policies that might be used in documents with IANA actions, and
defines some well-known policy terms. This document clarifies the
usage of these terms, and discourages the use of overly restrictive
registration policies.
The author is working with IANA on an update to BCP 26, and this
document's contents will be folded into that effort. While that's in
process, this draft will be kept alive for reference.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on October 26, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Leiba Expires October 26, 2012 [Page 1]
Internet-Draft IANA Policy Definitions Update April 2012
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Best Practice . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
Leiba Expires October 26, 2012 [Page 2]
Internet-Draft IANA Policy Definitions Update April 2012
1. Introduction
BCP 26 [RFC5226] presents a number of guidelines for IANA
considerations in RFCs. Section 4.1, in particular, is devoted to
registration policies, and the policy terminology it defines is
widely used. Whether or not RFCs use the specific terms defined
therein, there is a habit of applying the more restrictive policies
across the board, resulting in registries that require RFC, and even
Standards Track RFCs, for registries for which lighter weight
policies might be more appropriate.
2. Discussion
BCP 26 section 4.1 defines this set of registration policies:
1. Private Use
2. Experimental Use
3. Hierarchical Allocation
4. First Come First Served
5. Expert Review (or Designated Expert)
6. Specification Required
7. RFC Required
8. IETF Review
9. Standards Action
10. IESG Approval
Beginning with "First Come First Served", they are in approximately
increasing order of strictness:
4. No review, minimal documentation.
5. Expert review, sufficient documentation for review.
6. Expert review, significant and stable documentation.
7. Any RFC publication, perhaps in Independent stream.
8. RFC publication, IETF stream only.
9. Standards-Track RFC publication.
In considering which of policies 4 through 9 to apply, it's important
to get the right balance of review and ease of registration. In many
cases, those needing to register items will not be IETF participants;
requests often come from other standards organizations, from
organizations not directly involved in standards, from ad-hoc
community work (from an open-source project, for example), and so on.
We must not make registration policies and procedures unnecessarily
difficult to navigate, unnecessarily costly (in terms of time and
other resources), nor unnecessarily subject to denial.
While it is sometimes necessary to restrict what gets registered (for
Leiba Expires October 26, 2012 [Page 3]
Internet-Draft IANA Policy Definitions Update April 2012
limited resources such as bits in a byte or numbers within a
relatively small range, or for items for which unsupported values can
be damaging to protocol operation), in many cases having items
registered is more important than putting restrictions on the
registration. A pattern of denial through overly strict review
criteria, or because of excessive cost in time and effort to get
through the process, discourages people from even attempting to
register their items. And failure to have in-use items registered
adversely affects the protocols in use on the Internet.
In particular, because policies 7 through 9 require involvement of
working groups, directorates, and/or communities of former working-
group participants to be actively involved and to support the effort,
requests frequently run into concerns that "it's not worth doing a
Standards-Track RFC for something this trivial," when, in fact, that
requirement was created by the working group in the first place, with
its choice of a Standards Action policy for the registry. Indeed,
publishing any RFC is costly, and a Standards Track RFC is especially
so, requiring a great deal of community time for review and
discussion, IETF-wide last call, involvement of the entire IESG as
well a concentrated time and review from the sponsoring AD, review
and action by IANA, and RFC-Editor processing.
3. Best Practice
Working groups and other document developers should use care in
selecting appropriate registration policies when their documents
create registries. They should select the least strict policy that
suits a registry's needs, and look for specific justification for
policies stricter than Specification Required. Examples of
situations that might merit RFC Required, IETF Review, or Standards
Action include
o Registries of limited resources, such as bits in a byte (or in two
bytes, or four), or numbers in a limited range. In these cases,
allowing registrations that haven't been carefully reviewed and
agreed by community consensus could too quickly deplete the
allowable values.
o Registries for which thorough community review is necessary to
avoid extending or modifying the protocol in ways that could be
damaging. One example is in defining new command codes, as
opposed to options that use existing command codes: the former
might require a strict policy, where a more relaxed policy could
be adequate for the latter. Another example is in defining things
that change the semantics of existing operations.
Leiba Expires October 26, 2012 [Page 4]
Internet-Draft IANA Policy Definitions Update April 2012
There will be other cases, as well, of course; must assessment and
judgment is needed. It's not the intent, here, to put limits on the
applicability of particular registration policies, but to recommend
laxity, rather than strictness, in general, and to encourage document
developers to think carefully about each registry before deciding on
policies.
BCP 26, in its description of "IESG Approval", suggests that the IESG
"can (and should) reject a request if another path for registration
is available that is more appropriate and there is no compelling
reason to use that path." The IESG should give similar consideration
to any registration policy more stringent than Specification
Required, asking for justification and ensuring that more relaxed
policies have been considered, and the strict policy is the right
one. This is a situation that will -- and should -- involve a
substantive discussion between the IESG and the working group,
chairs, document editors, and/or document shepherd. The important
point, again, is not to relax the registration policy just to get the
document through quickly, but to carefully choose the right policy
for each registry.
Accordingly, document developers need to anticipate this and document
their considerations for choosing the specified policy. Ideally,
they should include that in the document. At the least, it should be
included in the shepherd writeup for the document, and in any case
the document shepherd should ensure that the selected policies have
been justified before sending the document to the IESG.
When specifications are revised, registration policies should be
reviewed in light of experience since the policies were set. It is
also possible to produce a small document at any time, which
"updates" the original specification and changes registration
policies. In either case, a policy can be relaxed or made more
strict, as appropriate to the actual situation.
Once again, it cannot be stressed enough that this must not be a
mechanical process, but one to which the document developers apply
thought, consideration, assessment, and judgment in choosing the
right policy for each registry.
The recommendations in this section apply whether the terms defined
in BCP 26 are used, or whether the document contains its own policy
definitions. The point, again, is not to limit registration
policies, but to ensure that the policies selected are appropriate,
and that proper consideration has been given to the level of
strictness required by them.
Leiba Expires October 26, 2012 [Page 5]
Internet-Draft IANA Policy Definitions Update April 2012
4. Security Considerations
See the Security Considerations section in BCP 26 [RFC5226], and note
that improper definition and application of IANA registration
policies can introduce both interoperability and security issues. It
is critical that registration policies be considered carefully and
separately for each registry. Overly restrictive policies can result
in the lack of registration of code points and parameters that need
to be registered, while overly permissive policies can result in
inappropriate registrations. Striking the right balance is an
important part of document development.
5. IANA Considerations
This document has no IANA actions.
6. Acknowledgements
Cyrus Daboo, Alexey Melnikov, Thomas Narten, Pete Resnick, and Peter
St. Andre were involved in early discussion of these issues.
7. Normative References
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Author's Address
Barry Leiba
Huawei Technologies
Phone: +1 646 827 0648
Email: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/
Leiba Expires October 26, 2012 [Page 6]
