Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 6220

Defining the Role and Function of IETF Protocol Parameter Registry Operators

Pages: 11
Obsoleted by:  8722

Top   ToC   RFC6220 - Page 1
Internet Architecture Board (IAB)                      D. McPherson, Ed.
Request for Comments: 6220                               O. Kolkman, Ed.
Category: Informational                                  J. Klensin, Ed.
ISSN: 2070-1721                                           G. Huston, Ed.
                                                              April 2011


            Defining the Role and Function of IETF Protocol
                      Parameter Registry Operators

Abstract

Many Internet Engineering Task Force (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 intentions. 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. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6220.
Top   ToC   RFC6220 - Page 2
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.

Table of Contents

1. Overview ........................................................2 2. Roles and Responsibilities Concerning IETF Protocol Parameter Registries ...................................3 2.1. Protocol Parameter Registry Operator Role ..................4 2.2. IAB Role ...................................................7 2.3. IESG Role ..................................................7 2.4. Role of the IETF Trust .....................................8 2.5. Role of the IAOC ...........................................8 3. Miscellaneous Considerations ....................................8 4. Security Considerations .........................................9 5. IANA Considerations .............................................9 6. Informative References ..........................................9 7. Acknowledgements ...............................................10 8. IAB Members ....................................................10

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 Considerations" 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. These functions have been separated into different organizations for several reasons. They include dealing with administrative issues, addressing concerns about maintaining an adequate distance between basic policy and specific
Top   ToC   RFC6220 - Page 3
   allocations, and avoiding any potential conflicts of interest that
   might arise from commercial or organizational relationships.  For
   example, most ISO and ISO/IEC JTC1 standards that require
   registration activities specify a Registration Authority (RA) or
   Maintenance Agency (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.

   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
   needed, under guidance from the IAB.

   Below we provide a description of the requirements 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 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
Top   ToC   RFC6220 - Page 4
   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, and 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.

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 the 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
Top   ToC   RFC6220 - Page 5
       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

       + 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 as 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
Top   ToC   RFC6220 - Page 6
       Parameter Registry Operator should maintain a mailing list that
       enables the registry staff of the Registry Operator to be
       contacted by email.

   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 each Internet-Draft that is
       being reviewed for publication as an RFC.  Where appropriate the
       IESG will appoint an expert to advise the Registry Operator.

   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 provides service level
       agreement (SLA) guidelines under which ICANN, the current
       protocol parameter registry, 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].
Top   ToC   RFC6220 - Page 7

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 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 Stream RFCs or through stand- alone "IANA Considerations" RFCs. 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.
Top   ToC   RFC6220 - Page 8
   At its discretion, the IESG will organize the liaison activities with
   the Registry Operator's liaison point of contact so as to facilitate
   clear communications and effective operation of the registry
   function.

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 the Internet Society (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 for 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

While this document has focused on the creation of protocols by the IETF, the requirements provided are generically applicable to the extended IETF community as well (e.g., Internet Research Task Force (IRTF)). 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 associated with 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
Top   ToC   RFC6220 - Page 9
   current published guidelines.  In the case that IANA considerations
   in non-IETF document streams lead to a dispute, the IAB makes the
   final decision.

   This document talks about "Registry Operator" (singular), and while
   there are stability and economy-of-scale advantages for one single
   Operator, this document does not exclude having different Operators
   for different protocol registries when justified by the
   circumstances.

4. Security Considerations

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

5. 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 protocol parameter registration functions for the IETF.

6. Informative References

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [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., Ed., and B. Wijnen, Ed., "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, April 2005. [RFC4748] Bradner, S., Ed., "RFC 3978 Update to Recognize the IETF Trust", RFC 4748, October 2006. [RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
Top   ToC   RFC6220 - Page 10
   [RFC5620]   Kolkman, O., Ed., and IAB, "RFC Editor Model (Version
               1)", RFC 5620, August 2009.

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

7. 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 drafts of this document, including Scott Bradner, Brian Carpenter, Leslie Daigle, Adrian Farrel, Alfred Hoenes, Paul Hoffman, Alexey Melnikov, Thomas Narten, and Ray Pelletier.

8. IAB Members

Internet Architecture Board Members at the time this document was approved for publication were: Marcelo Bagnulo Ross Callon Spencer Dawkins Russ Housley John Klensin Olaf Kolkman Danny McPherson Jon Peterson Andrei Robachevsky Dave Thaler Hannes Tschofenig
Top   ToC   RFC6220 - Page 11

Authors' Addresses

Danny McPherson, Editor Verisign, Inc. EMail: dmcpherson@verisign.com Olaf M. Kolkman, Editor NLnet Labs EMail: olaf@NLnetLabs.nl John C Klensin, Editor EMail: john+ietf@jck.com Geoff Huston, Editor APNIC EMail: gih@apnic.net Internet Architecture Board EMail: iab@iab.org