INTERNET-DRAFT                          Danny McPherson, Ed.
                                        Olaf M. Kolkman, Ed.
                                           John Klensin, Ed.
                                           Geoff Huston, Ed.
                                 Internet Architecture Board
Expires: September 2011                       March 24, 2011
Intended Status: Informational

            Defining the Role and Function of IETF Protocol
                      Parameter Registry Operators
                        <draft-iab-iana-07.txt>



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."



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



McPherson, et al.                                               [Page 1]


INTERNET-DRAFT           Expires: September 2011              March 2011


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Abstract


   Many IETF protocols make use of commonly-defined values that are
   passed in messages or packets.  To ensure consistent interpretation
   of these values between independent implementations, there is a need
   to ensure that the values and associated semantic intent are uniquely
   defined.  The IETF uses registry functions to record assigned
   protocol parameter values and their associated semantic intent. For
   each IETF protocol parameter it is current practice for the IETF to
   delegate the role of protocol parameter registry operator to a
   nominated entity.  This document provides a description of, and the
   requirements for, these delegated functions.


































McPherson, et al.                                               [Page 2]


INTERNET-DRAFT           Expires: September 2011              March 2011



Table of Contents


   1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   2. Roles and Responsibilities Concerning IETF Proto-
   col Parameter Registries. . . . . . . . . . . . . . . . . . . . .   5
    2.1. Protocol Parameter Registry Operator Role . . . . . . . . .   6
    2.2. IAB Role. . . . . . . . . . . . . . . . . . . . . . . . . .   8
    2.3. IESG Role . . . . . . . . . . . . . . . . . . . . . . . . .   9
    2.4. Role of the IETF Trust. . . . . . . . . . . . . . . . . . .  10
    2.5. Role of the IAOC. . . . . . . . . . . . . . . . . . . . . .  10
   3. Miscellaneous Considerations . . . . . . . . . . . . . . . . .  10
   4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  11
   5. Security Considerations. . . . . . . . . . . . . . . . . . . .  11
   6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  11
   7. References . . . . . . . . . . . . . . . . . . . . . . . . . .  11
    7.1. Normative References. . . . . . . . . . . . . . . . . . . .  11
    7.2. Informative References. . . . . . . . . . . . . . . . . . .  12
   8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  13
   9. Appendix A: IAB Members. . . . . . . . . . . . . . . . . . . .  14






























McPherson, et al.                                               [Page 3]


INTERNET-DRAFT           Expires: September 2011              March 2011


1.  Overview


   Many IETF protocols make use of commonly-defined values that are
   passed within messages or packets. To ensure consistent
   interpretation of these values between independent implementations,
   there is a need to ensure that the values and associated semantic
   intent are uniquely defined.  The IETF uses registries to record each
   of the possible values of a protocol parameter and their associated
   semantic intent.  These registries, their registration policy, and
   the layout of their content are defined in the so called "IANA
   Consideration" sections of IETF documents.

   The organizational separation between the IETF and its registry
   operators parallels ones that are fairly common among standards
   development organizations (SDOs) although less common among
   technology consortia and similar bodies.   This organizational
   separation has been done for a number of reasons, ranging from the
   need to deal with administrative issus and concerns about maintaining
   arms-length separation of basic policy and specific allocations, to
   avoiding any potential conflicts of interest for commercial or
   organizational reasons.  For example, most ISO and ISO/IEC JTC1
   standards that require registration activities specify Registration
   Authorities (RA) or Maintenance Agencies (MA) that, in turn, control
   the actual registration decisions.   The databases of what is
   registered for each standard may then be maintained by a secretariat
   or database function associated with the RA or MA or, less
   frequently, by the secretariat of the body that created and maintains
   the standard itself.

   However, this structural separation of roles exists within several
   places in the IETF framework (e.g., the RFC Editor function). The
   Internet Architecture Board (IAB), on behalf of the IETF, has the
   responsibility to define and manage the relationship with the
   protocol registry operator role.  This responsibility includes the
   selection and management of the protocol parameter registry operator,
   as well as management of the parameter registration process and the
   guidelines for parameter allocation.

   As with other SDOs, although it may delegate authority for some
   specific decisions, the IETF asserts authority and responsibility for
   the management of all of its protocol parameters and their registries
   even while it generally remains isolated from the selection of
   particular values once a registration is approved. This document
   describes the function of these registries as they apply to
   individual protocol parameters defined by the IETF Internet Standards
   Process [RFC2026] to allow for an orderly implementation by the
   Internet Administrative Oversight Committee (IAOC), and others as



McPherson, et al.                                   Section 1.  [Page 4]


INTERNET-DRAFT           Expires: September 2011              March 2011


   needed, under guidance from the IAB.

   Below we provide a description of the requirement for these delegated
   functions, which the IETF traditionally refers to as the Internet
   Assigned Numbers Authority (IANA) function.




2.  Roles and Responsibilities Concerning IETF Protocol Parameter
Registries


   The IETF's longstanding practice is to outsource the management and
   implementation of some important functions (e.g., [RFC5620]). The
   protocol parameter registry function falls into this category of
   outsourced functions, and what follows here is the comprehensive and
   normative description of the roles and responsibilities with respect
   to the registration of IETF protocol parameters.

   Specifically, this document describes the operation and role of a
   delegated IETF Protocol Parameter Registry Operator, to be selected
   and administered by the IETF Administrative Support Activity (IASA)
   [RFC4071].  While there is generally a single Protocol Parameter
   Registry Operator, additional Operators may be selected to implement
   specific registries and that has been done occasionally.  Having a
   single operator facilitates coordination among registries, even those
   that are not obviously related.  It also makes it easier to have
   consistency of formats and registry structure, which aids users of
   the registries and assists with quality control.

   Many protocols make use of identifiers consisting of constants and
   other well-known values. Even after a protocol has been defined and
   deployment has begun, new values may need to be assigned (e.g., for a
   new option type in DHCP, or a new encryption or authentication
   algorithm for IPsec).  To ensure that such quantities have consistent
   values and interpretations in different implementations, their
   assignment must be administered by a central authority. For IETF
   protocols, that role is provided by a delegated Protocol Parameter
   Registry Operator.  For any particular protocol parameter there is a
   single delegated registry operator.










McPherson, et al.                                   Section 2.  [Page 5]


INTERNET-DRAFT           Expires: September 2011              March 2011


2.1.  Protocol Parameter Registry Operator Role


   The IETF Protocol Parameter registry function is undertaken under the
   auspices of the Internet Architecture Board.

   The roles of a Protocol Parameter registry operator are as follows:

   o Review and Advise

     * A registry operator may be requested to review
       Internet-Drafts that are being considered by the Internet
       Engineering Steering Group (IESG), with the objective of
       offering advice to the IESG regarding the contents of the
       "IANA Considerations" section, whether such a section,
       when required, is clear in terms of direction to the registry
       operator, and whether the section is consistent with the
       current published registry operator guidelines.


   o Registry

     * To operate a registry of protocol parameter assignments.

     * The delegated registry operator registers values for
       Internet protocol parameters only as directed by the
       criteria and procedures specified in RFCs, including
       Proposed, Draft and full Internet Standards, Best Current
       Practice documents, and other RFCs that require protocol
       parameter assignment.

       If values for Internet protocol parameters were not specified,
       or in case of ambiguity, the registry operator will continue
       to assign and register only those protocol parameters that
       have already been delegated to the operator, following past
       and current practice for such assignments, unless otherwise
       directed in terms of operating practice by the IESG.  In the
       case of ambiguity, the registry operator is expected to
       identify the ambiguity to the IAB or IESG as appropriate and
       either suggest better text or ask the appropriate parties for
       clarification.

     * For each protocol parameter, the associated registry
       includes:

       + a reference to the RFC document that describes the
         parameter and the associated "IANA Considerations"
         concerning the parameter, and



McPherson, et al.                                 Section 2.1.  [Page 6]


INTERNET-DRAFT           Expires: September 2011              March 2011


       + for each registration of a protocol parameter value,
         the source of the registration and the date of the
         registration, if the date of registration is known, and

       + any other information specified for being included in
         the registration data in the RFC document that
         describes the parameter.

       + If in doubt or in case of a technical dispute, the
         registry operator will seek and follow technical
         guidance exclusively from the IESG.  Where appropriate
         the IESG will appoint an expert to advise the registry
         operator.

     * The registry operator will work with the IETF to develop any
       missing criteria and procedures over time, which the registry
       operator will adopt when so instructed by the IESG.

     * Unless special circumstances apply to subsets of the data and
       specific rules are established by IETF consensus, each protocol
           parameter registry operates as a public registry, and the
           contents of the registry are openly available to the public,
           on-line and free of charge.

     * The registry operator assigns protocol parameter values in
       accordance with the policy associated with the protocol
       parameter, such as "First Come First Served" or "Expert
       Review" [RFC5226].

   o Mailing Lists

     * The registry operator maintains public mailing lists as
       specified in IANA Considerations [RFC5226]. Such lists are
       designated for the purpose of review of assignment proposals
       in conjunction with a designated expert review function.  In
       addition, each protocol parameter registry operator should
       maintain a mailing list that enables the registry staff of
       the registry operator to be contacted by email.  For example,
       iana@iana.org currently provides this function for IANA.

   o Liaison Activity

     * The registry operator will nominate a liaison point of contact.
       The registry operator, through this liaison, may be requested to
       provide advice to the IESG on IETF protocol parameters as well
       as the IANA Considerations section of Internet-Drafts that are
       being reviewed for publication as an RFC.  Where appropriate the
       IESG will appoint an expert to advise the registry operator.



McPherson, et al.                                 Section 2.1.  [Page 7]


INTERNET-DRAFT           Expires: September 2011              March 2011


   o Reporting

     * The registry operator will submit periodic reports to the IAB
       concerning the operational performance of the registry function.
       As an example of the requirements for such reports the reader is
       referred to a supplement [IAOC_SUPP] to the "Memorandum of
       Understanding Concerning the Technical Work of the Internet
       Assigned Numbers Authority" [RFC2860] that was established by
       the IAB and provides service level agreement (SLA) guidelines
       under which the protocol parameter registry, as implemented by
       ICANN, must operate.

     * At the request of the chair of the IETF, IAB, or IAOC, the
       registry operator will undertake periodic reports to IETF
       Plenary meetings concerning the status of the registry function.

     * The registry operator will publish an annual report describing
       the status of the function and a summary of performance
       indicators.

   o  Intellectual Property Rights and the Registry Operator

     * All assigned values are to be published and made available free
       of any charges.

     * The assignment values may be redistributed without modification.

     * Any intellectual property rights of the IETF Protocol Parameter
       assignment information, including the IETF Protocol Parameter
       registry and its contents, are to be held by the IETF Trust
       [RFC4748].



2.2.  IAB Role


   An operator of an IETF Protocol Parameter registry undertakes the
   role as a delegated function under the authority of the IAB.

   The IAB has the responsibility to review the current description of
   the registry function from time to time and direct the registry
   operator to adopt amendments relating to its role and mode of
   operation according to the best interests of the IETF, and the
   Internet community in general.

   The IAB has the responsibility to appoint an organization to
   undertake the delegated functions of the Protocol Parameter registry



McPherson, et al.                                 Section 2.2.  [Page 8]


INTERNET-DRAFT           Expires: September 2011              March 2011


   operator for each IETF protocol parameter.  Specifically, the IAB
   defines the role and requirements for the desired functions.  The
   IAOC is responsible for identifying a potential vendor, and once
   under agreement, managing the various aspects of the relationships
   with that vendor.  To be clear, the IAB is in the deciding role
   (e.g., for appointment and termination), but must work in close
   consultation with the IAOC.

   The IAB has the responsibility to determine the terms and conditions
   of this delegated role. Such terms and conditions should ensure that
   the registry operates in a manner that is fully conformant to the
   functions described in this document. In addition, such terms and
   conditions must not restrict the rights and interests of the IETF
   with respect to the registry contents and maintenance.



2.3.  IESG Role


   The IESG is responsible for the technical direction regarding entries
   into IETF Protocol Parameter registries and maintaining the policies
   by which such technical directions are given.  Technical direction
   itself is provided through the adoption of directives within the
   "IANA Considerations" section of IETF RFC documents, or through
   stand-alone "IANA Considerations" RFC documents.

   The IESG shall verify that Internet-Drafts that are offered for
   publication as IETF Stream RFCs [RFC4844] include IANA Considerations
   sections when needed, and that IANA Considerations sections conform
   to the current published guidelines.

   Since technical assessment is not generally a responsibility of the
   registry operator, as part of providing the technical direction, the
   IESG is responsible for identifying the technical experts that are
   required to, where appropriate, review registration requests or
   resolve open technical questions that relate to the registration of
   parameters.

   The IESG will at its discretion organize the liaison activities with
   the registry operator's liaison point of contact as to facilitate
   clear communications and effective operation of the registry
   function.








McPherson, et al.                                 Section 2.3.  [Page 9]


INTERNET-DRAFT           Expires: September 2011              March 2011


2.4.  Role of the IETF Trust


   The IETF Trust [RFC4748] was formed to act as the administrative
   custodian of all copyrights and other intellectual property rights
   relating to the IETF Standards Process, a function that had
   previously been performed by ISOC and the Corporation for National
   Research Initiatives (CNRI).

   Any intellectual property rights of IETF Protocol Parameter
   assignment information, including the registry and its contents, and
   all registry publications, are to be held by the IETF Trust on behalf
   of the IETF.

   The IETF Trust may make such regulations as appropriate for the
   redistribution of assignment values and registry publications.



2.5.  Role of the IAOC


   The IAOC is responsible for identifying a potential vendor in a
   manner of their choosing based on IAB consultation, and managing the
   various aspects of the relationships with that vendor.

   In addition, the IAOC has the responsibility to ensure long-term
   access, stability, and uniqueness across all such registries . This
   responsibility is of particular significance in the event that a
   relation with a protocol parameter registry operator is terminated.



3.  Miscellaneous Considerations


   The IESG is responsible for the technical direction of the IETF
   Protocol Parameter registries and maintaining the policies by which
   such technical directions are given. The IESG is responsible, as part
   of the document approval process for the IETF-stream RFCs [RFC4844],
   for 'IANA Considerations' verification. For the other RFC streams the
   approval bodies are responsible for verifying that the documents
   include IANA Considerations sections when needed, and that IANA
   Considerations sections conform to the current published guidelines.
   In the case the that IANA considerations in non-IETF document streams
   lead to a dispute the IAB has the final word.





McPherson, et al.                                  Section 3.  [Page 10]


INTERNET-DRAFT           Expires: September 2011              March 2011


4.  Acknowledgements


   This document is adapted from "Guidelines for Writing an IANA
   Considerations Section in RFCs" [RFC5226], and has been modified to
   include explicit reference to Intellectual Property Rights, and the
   roles of the IAB and IESG in relation to the IETF Protocol Parameter
   registry function.

   The Internet Architecture Board acknowledges the assistance provided
   by reviewers of earlier drafts of this document, including Scott
   Bradner, Leslie Daigle, Alfred Hoenes, Thomas Narten, and Ray
   Pelletier.



5.  Security Considerations


   This document does not propose any new protocols, and does not
   introduce any new security considerations.



6.  IANA Considerations


   This document requires no direct IANA actions in terms of the
   creation or operation of a protocol parameter registry.  However,
   this document does define the roles and responsibilities of various
   bodies who are responsible for, and associated with, the operation of
   the protocol parameter registration functions for the IETF.



7.  References




7.1.  Normative References










McPherson, et al.                                Section 7.1.  [Page 11]


INTERNET-DRAFT           Expires: September 2011              March 2011


7.2.  Informative References


   [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              STD 2, October 1994.

   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
              3", RFC 2026, BCP 9, October 1996.

   [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines
              For Values In the Internet Protocol and Related Headers",
              RFC 2780, BCP 37, March 2000.

   [RFC2850] Carpenter, B., "Charter of the Internet Architecture
              Board", RFC 2850, BCP 39, 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.

   [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition
              of New DHCP Options and Message Types", RFC 2939, BCP 43,
              September 2000.

   [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
              Procedures", RFC 2978, BCP 19, October 2000.

   [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
              an On-line Database", RFC 3232, January 2002.

   [RFC4071] Austein, R., Wijnen, B., "Structure of the IETF
              Administrative Support Activity (IASA)", RFC 4071,
              April 2005.

   [RFC4748] Bradner, S., "RFC 3978 Update to Recognize the IETF
              Trust", RFC 4748, BCP 78, October 2006.

   [RFC4844] Daigle, L., Ed. and IAB, "The RFC Series and RFC
              Editor", RFC 4844, July 2007.



   [RFC5226] Narten, T., Alvestrand, H., "Guidelines for Writing
              an IANA Considerations Section in RFCs", RFC 5226,
              May 2008.

   [RFC5620] Kolkman, O., IAB,  "RFC Editor Model (Version 1)",



McPherson, et al.                                Section 7.2.  [Page 12]


INTERNET-DRAFT           Expires: September 2011              March 2011


                  RFC 5620, August 2009.


   [IANA] Reynolds, J., "IANA Protocol Numbers and Assignment
          Services", October 1994, <http://www.iana.org/numbers.htm>.

   [IAOC_SUPP] ICANN/IANA-IETF MoU Supplemental Agreement
   <http://iaoc.ietf.org/documents/IETF-
   ICANN_Supplemental_Agreement.pdf>

   [CORR] Dyson, E., "Correspondence from Esther Dyson, Interim
          Chairman, ICANN to Scott Bradner, Brian Carpenter and
          Fred Baker of the IETF", February 1999,
        <http://www.icann.org/correspondence/bradner-dyson-25feb99.htm>.


   [ENUM_INSTR] IAB, "ENUM LIAISON ON IAB INSTRUCTIONS TO RIPE-NCC",
              September 2002,
       <http://www.iab.org/Documents/sg2-liaison-e164-sep-02.html>.

   [RIPE_ENUM]  RIPE NCC, "ENUM Registry", September 2002,
       <http://www.ripe.net/enum>.



8.  Authors' Addresses



   Danny McPherson, Editor
   Verisign, Inc.
   Email: dmcpherson@verisign.com

   Olaf M. Kolkman, Editor
   NLnet Labs
   Email: olaf@NLnetLabs.nl

   John C Klensin
   Email: john+ietf@jck.com

   Geoff Huston, Editor
   APNIC
   Email: gih@apnic.net

   Internet Architecture Board
   Email: iab@iab.org





McPherson, et al.                                  Section 8.  [Page 13]


INTERNET-DRAFT           Expires: September 2011              March 2011


9.  Appendix A: IAB Members


   Internet Architecture Board Members at the time this document was
   published were:


      Marcelo Bagnulo
      Gonzalo Camarillo
      Stuart Cheshire
      Russ Housley
      John Klensin
      Olaf Kolkman
      Gregory Lebovitz
      Andrew Malis
      Danny McPherson
      David Oran
      Jon Peterson
      Dave Thaler
































McPherson, et al.                                  Section 9.  [Page 14]