Internet Architecture Board (IAB)                    R. Housley (editor)
Internet-Draft                                            Vigil Security
Intended status: Informational                       O. Kolkman (editor)
                                                        Internet Society
Expires: 22 May 2015                                    18 November 2014


                      Principles for Operation of
         Internet Assigned Numbers Authority (IANA) Registries

                      draft-iab-iana-principles-00

Abstract


   This document provides principles for the operation of Internet
   Assigned Numbers Authority (IANA) registries.

   Note: This is Internet-Draft was developed by the IAB IANA Evolution
   Program, and it should be discussed on the InternetGovtech@iab.org
   mail list.  See http://www.iab.org/mailman/listinfo/internetgovtech
   for subscription details.

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 21 May 2015.

Copyright Notice

   Copyright (c) 2014 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



Housley & Kolkman          Expires 21 May 2015                  [Page 1]


Internet-Draft               IANA Principles               November 2014


   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.

0.  Document Background

   {{{ RFC Editor: Please delete this section prior to publication. }}}

   This document is a split off from draft-iab-iana-framework-02.  This
   document contains principles that were scattered in various places in
   the IANA Framework, pulling them into one place.

   The IANA Framework has been under discussion since February 2011.

1.  Introduction

   The Internet Engineering Task Force (IETF) and its predecessors have
   traditionally separated the publication of protocol specifications in
   immutable Request for Comments (RFCs) and the registries containing
   protocol parameters.  The latter is maintained by a set of functions
   traditionally known collectively as the Internet Assigned Numbers
   Authority (IANA).  Dating back to the earliest days of the Internet,
   specification publication and the registry operations were tightly
   coupled: Jon Postel of the Information Sciences Institute (ISI) of
   the University of Southern California (USC) was responsible for both
   RFC publication and IANA registry operation.  This tight coupling has
   advantages, but it has never been a requirement.  Indeed, today the
   RFC Editor and IANA registry operation are provided by different
   entities.

   Internet registries are critical to the operation of the Internet,
   since they provide a definitive record of the value and meaning of
   identifiers that protocols use when communicating with each other.
   Almost every Internet protocol makes use of registries in some form.
   At the time of writing, the IANA maintains more than two thousand
   protocol parameter registries.

   Internet registries hold protocol identifiers consisting of constants
   and other well-known values used by Internet protocols.  These values
   can be numbers, strings, addresses, and so on.  They are uniquely
   assigned for one particular purpose or use.  Identifiers can be
   maintained in a central list (such as a list of cryptographic
   algorithms) or they can be hierarchically allocated and assigned by
   separate entities at different points in the hierarchy (such as IP
   addresses and domain names).



Housley & Kolkman          Expires 21 May 2015                  [Page 2]


Internet-Draft               IANA Principles               November 2014


   The registry system is built on trust and mutual cooperation.  The
   use of the registries is voluntary and is not enforced by mandates or
   certification policies.  While the use of registries is voluntary, it
   is noted that the success of the Internet creates enormous pressure
   to use Internet protocols and the registries associated with them.

   This document provides principles for the operation of IANA
   registries, ensuring that protocol identifiers have consistent
   meanings and interpretations across all implementations and
   deployments, and thus providing the necessary trust in the
   registries.

2.  Principles for the Operation of IANA Registries

   The following key principles underscore the successful functioning of
   the IANA registries, and they provide a foundation for trust in those
   registries:

   Unique:  The same protocol identifier must not be used for more than
      one purpose.

   Stable:  Protocol identifier assignment must be lasting.

   Predictable:  The process for making assignments must be predictable.

   Public Publication:  The protocol identifiers must be published in a
      manner that makes them available to everyone in selected well-
      known locations.

   Open:  The process that sets the policy for protocol identifier
      assignment and registration must be open to all interested
      parties.

   Transparent:  The protocol registries and their associated policies
      should be developed in a transparent manner.

   Accountable:  Registry policy development and registry operations
      need to be accountable to the affected community.

3.  Discussion

   The principles discussed in Section 2 provide trust and confidence in
   the IANA registries.

3.1.  Unique, Stable, and Predictable

   Protocol identifier assignment and registration must be unique,
   stable, and predictable.  Developers, vendors, customers, and users



Housley & Kolkman          Expires 21 May 2015                  [Page 3]


Internet-Draft               IANA Principles               November 2014


   depend on the registries for unique protocol identifiers that are
   assigned in a stable and predictable manner.  A protocol identifier
   may only be reassigned for a different purpose after due
   consideration of the impact of such a reassignment, and if possible,
   with the consent of the original assignee.

3.2.  Public Publication

   Once assigned, the protocol identifiers must be published in a manner
   that makes them available to everyone.  The use of a consistent
   publication location builds confidence in the registry.  This does
   not mean that the publication location can never change, but it does
   mean that it must change infrequently and only after adequate prior
   notice.

3.3.  Open and Transparent

   The process that sets the policy for protocol identifier assignment
   and registration must be open to all interested parties and operate
   in a transparent manner.

   For many registries there is a de-facto separation of the policy
   setting and the evaluation of the policy that takes place at
   implementation.  Splitting those roles can expose instances where
   policies lack of clarity, which provides helpful feedback to allow
   those policies to be improved.  In addition, this separation
   prevents the risks of the policy evaluation from being burdened with
   (perceptions of) favoritism and unfairness.

3.4.  Accountable

   The process that sets the policy for protocol identifiers and the
   operation of the registries must be accountable to the parties that
   rely on the protocol identifiers.  Oversight is needed to ensure
   these are properly serving the affected community.

   In practice accountability mechanisms may be defined by contract,
   memoranda of understanding, or service level agreements (SLAs).  An
   oversight body is held accountable to the wider community by
   different mechanisms, for instance recall and appeal processes.

   For protocol parameters [RFC6220], the general oversight over the
   IANA function is performed by the IAB as a chartered responsibility
   from [RFC2850] (also see Section 5.4).  In addition the IAOC, a body
   responsible for IETF administrative and financial matters [RFC4071],
   maintains an SLA with ICANN, thereby specifying the operational
   requirements with respect to the coordination of evaluation, and the
   maintenance and publication of the registries. Both the IAB and the



Housley & Kolkman          Expires 21 May 2015                  [Page 4]


Internet-Draft               IANA Principles               November 2014


   IAOC are accountable to the larger Internet community and are being
   held accountable through the IETF Nomcom process [BCP10].

4.  Security Considerations

   Internet Registries are critical to elements of Internet security.
   The principles described in this document are necessary for the
   Internet community to place trust in the IANA registries..

5.  Contributors and Acknowledgements

   This text has been developed within the IAB IANA Evolution Program.
   The ideas and many text fragments, and corrections came from or were
   inspired on comments from: Bernard Aboba, Jaap Akkerhuis, Jari Arkko,
   Marcelo Bagnulo, Mark Blanchet, Brian Carpenter, David Conrad, Steve
   Crocker, John Curran, Alissa Cooper, Leslie Daigle, Elise Gerich,
   John Klensin, Bertrand de La Chapelle, Danny McPherson, George
   Michaelson, Thomas Narten, Andrei Robachevsky, and Greg Wood.
   Further inspiration and input was drawn from various meetings with
   IETF and other Internet community (RIRs, ISOC, W3C, IETF, and IAB)
   leadership.

   It should not be assumed that those acknowledged endorse the
   resulting text.

6.  IANA Considderations

   This document does not contain updates to any registries.

7.  Informative References

   [BCP10]    Galvin, J., Ed., "IAB and IESG Selection, Confirmation,
              and Recall Process: Operation of the Nominating and Recall
              Committees", BCP 10, RFC 3777, June 2004.

              Dawkins, S., "Nominating Committee Process: Earlier
              Announcement of Open Positions and Solicitation of
              Volunteers", BCP 10, RFC 5633, August 2009.

   [RFC2850]  Internet Architecture Board and B. Carpenter, "Charter of
              the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
              May 2000.

   [RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
              Understanding Concerning the Technical Work of the
              Internet Assigned Numbers Authority", RFC 2860, June 2000.

   [RFC4071]  Austein, R. and B. Wijnen, "Structure of the IETF



Housley & Kolkman          Expires 21 May 2015                  [Page 5]


Internet-Draft               IANA Principles               November 2014


              Administrative Support Activity (IASA)", BCP 101, RFC
              4071, April 2005.

   [RFC6220]  McPherson, D., Kolkman, O., Klensin, J., Huston, G., and
              Internet Architecture Board, "Defining the Role and
              Function of IETF Protocol Parameter Registry Operators",
              RFC 6220, April 2011.

Authors' Addresses

   Russ Housley
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA
   Email: housley@vigilsec.com

   Olaf Kolkman
   Science Park 400
   Amsterdam  1098 XH
   The Netherlands
   EMail: kolkman@isoc.org






























Housley & Kolkman          Expires 21 May 2015                  [Page 6]