Network Working Group                                           B. Leiba
Internet-Draft                                       Huawei Technologies
Updates: 5226 (if approved)                           September 27, 2011
Intended status: BCP
Expires: March 30, 2012


    Update of and Clarification to IANA Policy Definitions in BCP 26
                   draft-leiba-iana-policy-update-00

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.

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 March 30, 2012.

Copyright Notice

   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



Leiba                    Expires March 30, 2012                 [Page 1]


Internet-Draft       IANA Policy Definitions Update       September 2011


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3

   2.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . . . 3

   3.  Best Practice . . . . . . . . . . . . . . . . . . . . . . . . . 4

   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5

   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6

   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6

   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6

       Author's Address  . . . . . . . . . . . . . . . . . . . . . . . 6































Leiba                    Expires March 30, 2012                 [Page 2]


Internet-Draft       IANA Policy Definitions Update       September 2011


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 March 30, 2012                 [Page 3]


Internet-Draft       IANA Policy Definitions Update       September 2011


   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 March 30, 2012                 [Page 4]


Internet-Draft       IANA Policy Definitions Update       September 2011


   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.


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



Leiba                    Expires March 30, 2012                 [Page 5]


Internet-Draft       IANA Policy Definitions Update       September 2011


   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, 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 March 30, 2012                 [Page 6]