GENWiki

Internet Architecture Board (IAB) D. McPherson, Ed. Request for Comments: 8722 Verisign, Inc. Obsoletes: 6220 O. Kolkman, Ed. Category: Informational ISOC ISSN: 2070-1721 J. Klensin, Ed.

                                                                      
                                                        G. Huston, Ed.
                                                                 APNIC
                                                         February 2020

 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.  This document obsoletes RFC 6220 to replace all
 references to the IETF Administrative Support Activity (IASA) and
 related structures with those defined by the IASA 2.0 Model.

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.  It represents the consensus of the
 Internet Architecture Board (IAB).  Documents approved for
 publication by the IAB are not candidates for any level of Internet
 Standard; see Section 2 of RFC 7841.

 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 https://www.rfc-editor.org/info/rfc8722.

Copyright Notice

 Copyright (c) 2020 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
 (https://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.  Roles and Responsibilities Concerning IETF Protocol Parameter
         Registries
   2.1.  Protocol Parameter Registry Operator Role
   2.2.  IAB Role
   2.3.  IESG Role
   2.4.  Role of the IETF Trust
   2.5.  Role of the IETF Administration Limited Liability Company
 3.  Miscellaneous Considerations
 4.  Security Considerations
 5.  IANA Considerations
 6.  Informative References
 IAB Members at the Time of Approval
 Acknowledgements
 Authors' Addresses

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 Protocol
 Parameter 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 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 Parameter 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 (see RFC 6410 [BCP9]) to allow for an orderly implementation
 by the IETF Administration Limited Liability Company (IETF LLC), and
 others as needed, under guidance from the IAB.  This document
 obsoletes RFC 6220 to replace all references to the IASA and related
 structures with those defined by the IASA 2.0 Model [RFC8711].

 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., [RFC8728]).  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)
 [RFC8711].  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 Protocol Parameter Registry 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 (Registry
 Operator) are as follows:

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.

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 Standards Track
       documents [BCP9], 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 Registry 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:

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

       o  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

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

       o  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"
       [RFC8126].

Mailing Lists

The Registry Operator maintains public mailing lists as

specified in IANA Considerations [RFC8126]. Such lists are

       designated for the purpose of review of assignment proposals in
       conjunction with a designated expert review function.  In
       addition, each Registry Operator should maintain a mailing list
       that enables the registry staff of the Registry Operator to be
       contacted by email.

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.

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 [MoU_SUPP2019] 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 or IAB, or the IETF

Executive Director [RFC8711], the Registry Operator will

       undertake periodic reports to IETF Plenary meetings or
       elsewhere as directed, 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.

Intellectual Property Rights and the Registry Operator

    Unless special circumstances apply (see above):

All assigned values are to be published and made available free

of any charges.

The assignment values may be redistributed without

modification.

    In any case,

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
       [RFC8711] [RFC8714].

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 Registry Operator for each
 IETF protocol parameter.  Specifically, the IAB defines the role and
 requirements for the desired functions.  The IETF LLC 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 IETF
 LLC.

 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 [RFC8729] 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.

 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 [RFC4371] 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 IETF Administration Limited Liability Company

 The IETF Administration Limited Liability Company (IETF LLC)
 [RFC8711] is responsible for identifying a potential vendor in a
 manner of its choosing, based on IAB consultation, and for managing
 the various aspects of the relationships with that vendor.

 In addition, the IETF LLC 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 [RFC8729], 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 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
 Registry Operator, this document does not exclude having different
 Registry 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

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

            Dusseault, L. and R. Sparks, "Guidance on Interoperation
            and Implementation Reports for Advancement to Draft
            Standard", BCP 9, RFC 5657, September 2009.

            Housley, R., Crocker, D., and E. Burger, "Reducing the
            Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
            October 2011.

            Resnick, P., "Retirement of the "Internet Official
            Protocol Standards" Summary Document", BCP 9, RFC 7100,
            December 2013.

            Kolkman, O., Bradner, S., and S. Turner, "Characterization
            of Proposed Standards", BCP 9, RFC 7127, January 2014.

            Dawkins, S., "Increasing the Number of Area Directors in
            an IETF Area", BCP 9, RFC 7475, March 2015.

            <https://www.rfc-editor.org/info/bcp9>

 [MoU_SUPP2019]
            IETF Administration LLC, "2019 ICANN-IETF MoU Supplemental
            Agreement", 31 July 2019,
            <https://www.ietf.org/media/documents/FINAL_2019-IETF_MoU_
            Supplemental_Agreement_Signed_31July19.pdf>.

 [RFC2860]  Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
            Understanding Concerning the Technical Work of the
            Internet Assigned Numbers Authority", RFC 2860,
            DOI 10.17487/RFC2860, June 2000,
            <https://www.rfc-editor.org/info/rfc2860>.

 [RFC4371]  Carpenter, B., Ed. and L. Lynch, Ed., "BCP 101 Update for
            IPR Trust", BCP 101, RFC 4371, DOI 10.17487/RFC4371,
            January 2006, <https://www.rfc-editor.org/info/rfc4371>.

 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", RFC 5226,
            DOI 10.17487/RFC5226, May 2008,
            <https://www.rfc-editor.org/info/rfc5226>.

 [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
            Writing an IANA Considerations Section in RFCs", BCP 26,
            RFC 8126, DOI 10.17487/RFC8126, June 2017,
            <https://www.rfc-editor.org/info/rfc8126>.

 [RFC8711]  Haberman, B., Hall, J., and J. Livingood, "Structure of
            the IETF Administrative Support Activity, Version 2.0",
            BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020,
            <https://www.rfc-editor.org/info/rfc8711>.

 [RFC8714]  Arkko, J. and T. Hardie, "Update to the Process for
            Selection of Trustees for the IETF Trust", BCP 101,
            RFC 8714, DOI 10.17487/RFC8714, February 2020,
            <https://www.rfc-editor.org/info/rfc8714>.

 [RFC8728]  Kolkman, O., Ed., Halpern, J., Ed., and R. Hinden, Ed.,
            "RFC Editor Model (Version 2)", RFC 8728,
            DOI 10.17487/RFC8728, February 2020,
            <https://www.rfc-editor.org/info/rfc8729>.

 [RFC8729]  Housley, R., Ed. and L. Daigle, Ed., "The RFC Series and
            RFC Editor", RFC 8729, DOI 10.17487/RFC8729, February
            2020, <https://www.rfc-editor.org/info/rfc8729>.

IAB Members at the Time of Approval

 Internet Architecture Board Members at the time this document was
 approved for publication were:

    Jari Arkko
    Alissa Cooper
    Stephen Farrell
    Wes Hardaker
    Ted Hardie
    Christian Huitema
    Zhenbin Li
    Erik Nordmark
    Mark Nottingham
    Melinda Shore
    Jeff Tantsura
    Martin Thomson
    Brian Trammell

Acknowledgements

 This document was originally 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 document was updated under auspices of the IASA2 working group to
 reflect the reorganization of IETF Administrative Support Activity.

 The Internet Architecture Board acknowledges the assistance provided
 by reviewers of drafts of this document, including Scott Bradner,
 Brian Carpenter, Leslie Daigle, Adrian Farrel, Bob Hinden, Alfred
 Hoenes, Paul Hoffman, Benjamin Kaduk, Alexey Melnikov, Thomas Narten,
 and Ray Pelletier.

Authors' Addresses

 Danny McPherson (editor)
 Verisign, Inc.

 Email: dmcpherson@verisign.com

 Olaf Kolkman (editor)
 Internet Society

 Email: kolkman@isoc.org

 John C Klensin (editor)

 Email: john-ietf@jck.com

 Geoff Huston (editor)
 APNIC

 Email: gih@apnic.net