| Network Working Group | B. Leiba |
| Internet-Draft | Huawei Technologies |
| Updates: 5226 (if approved) | September 27, 2011 |
| Intended status: Best Current Practice | |
| Expires: March 30, 2012 |
Update of and Clarification to IANA Policy Definitions in BCP 26
draft-leiba-iana-policy-update-00
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.
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 March 30, 2012.
Copyright (c) 2011 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 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.
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.
BCP 26 section 4.1 defines this set of registration policies:
Beginning with "First Come First Served", they are in approximately increasing order of strictness:
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 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.
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
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 include a justification for the chosen policy in the document along with the documentation of the choice. At the least, a justification 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.
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.
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.
This document has no IANA actions.
Cyrus Daboo, Alexey Melnikov, Pete Resnick, and Peter St. Andre were involved in early discussion of these issues.
| [RFC5226] | Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. |