Skip to main content

Defining the Role and Function of IETF Protocol Parameter Registry Operators
draft-ietf-iasa2-rfc6220bis-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8722.
Authors Danny R. McPherson , Olaf Kolkman , Dr. John C. Klensin , Geoff Huston
Last updated 2018-10-10
RFC stream Internet Engineering Task Force (IETF)
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 8722 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-iasa2-rfc6220bis-01
Internet Architecture Board(IAB)                       D. McPherson, Ed.
Internet-Draft                                           O. Kolkman, Ed.
Obsoletes: 6220 (if approved)                                       ISOC
Intended status: Informational                           J. Klensin, Ed.
Expires: April 13, 2019
                                                          G. Huston, Ed.
                                                                   APNIC
                                                                     IAB
                                                        October 10, 2018

   Defining the Role and Function of IETF Protocol Parameter Registry
                               Operators
                     draft-ietf-iasa2-rfc6220bis-01

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.

Cover Note

   [The IASA2 WG asks the IAB to publish this replacement for RFC 6220.
   This document is changed for alignment with the new structure for the
   IETF Administrative Support Activity (IASA). ]

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 https://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

McPherson, et al.        Expires April 13, 2019                 [Page 1]
Internet-Draft         Role of Registry Operators           October 2018

   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 April 13, 2019.

Copyright Notice

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

Table of Contents

   1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Roles and Responsibilities Concerning IETF Protocol Parameter
       Registries  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Protocol Parameter Registry Operator Role . . . . . . . .   4
     2.2.  IAB Role  . . . . . . . . . . . . . . . . . . . . . . . .   7
     2.3.  IESG Role . . . . . . . . . . . . . . . . . . . . . . . .   8
     2.4.  Role of the IETF Trust  . . . . . . . . . . . . . . . . .   8
     2.5.  Role of the IETF Administration Limited         Liability
           Company . . . . . . . . . . . . . . . . . . . . . . . . .   8
   3.  Miscellaneous Considerations  . . . . . . . . . . . . . . . .   9
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  Informative References  . . . . . . . . . . . . . . . . . . .  10
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  11
   Appendix B.  IAB members  . . . . . . . . . . . . . . . . . . . .  11
   Appendix C.  Document Editing Details . . . . . . . . . . . . . .  11
     C.1.  Version Information . . . . . . . . . . . . . . . . . . .  11
       C.1.1.  draft-iab-iasa2-rfc6220-00  . . . . . . . . . . . . .  12
       C.1.2.  draft-iab-iasa2-rfc6220-01  . . . . . . . . . . . . .  12
       C.1.3.  TODO/Open issues  . . . . . . . . . . . . . . . . . .  12
     C.2.  RCS information . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

McPherson, et al.        Expires April 13, 2019                 [Page 2]
Internet-Draft         Role of Registry Operators           October 2018

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
   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 IETF
   Administration Limited Liability Company (LLC), and others as needed,
   under guidance from the IAB.

McPherson, et al.        Expires April 13, 2019                 [Page 3]
Internet-Draft         Role of Registry Operators           October 2018

   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)
   [I-D.ietf-iasa2-struct].  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, 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

McPherson, et al.        Expires April 13, 2019                 [Page 4]
Internet-Draft         Role of Registry Operators           October 2018

         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

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

McPherson, et al.        Expires April 13, 2019                 [Page 5]
Internet-Draft         Role of Registry Operators           October 2018

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

   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 [MoU_SUPP2018] 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 LLC, the
         Registry Operator will undertake periodic reports to IETF

McPherson, et al.        Expires April 13, 2019                 [Page 6]
Internet-Draft         Role of Registry Operators           October 2018

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

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

McPherson, et al.        Expires April 13, 2019                 [Page 7]
Internet-Draft         Role of Registry Operators           October 2018

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.

   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 he IETF Administration Limited Liability Company (LLC)
   [I-D.ietf-iasa2-struct] is responsible for identifying a potential
   vendor in a manner of its choosing, based on IAB consultation, and

McPherson, et al.        Expires April 13, 2019                 [Page 8]
Internet-Draft         Role of Registry Operators           October 2018

   for managing the various aspects of the relationships with that
   vendor.

   In addition, the 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 [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 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.

McPherson, et al.        Expires April 13, 2019                 [Page 9]
Internet-Draft         Role of Registry Operators           October 2018

6.  Informative References

   [I-D.ietf-iasa2-struct]
              Haberman, B., Hall, J., and J. Livingood, "Record of
              Proposed Structure of the IETF Administrative Support
              Activity (IASA), Version 2.0", draft-ietf-iasa2-struct-06
              (work in progress), September 2018.

   [MoU_SUPP2018]
              "ICANN/IANA-IETF MoU Supplemental Agreement, 2018".

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
              <https://www.rfc-editor.org/info/rfc2026>.

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

   [RFC4844]  Daigle, L., Ed. and Internet Architecture Board, "The RFC
              Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844,
              July 2007, <https://www.rfc-editor.org/info/rfc4844>.

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

   [RFC5620]  Kolkman, O., Ed. and IAB, "RFC Editor Model (Version 1)",
              RFC 5620, DOI 10.17487/RFC5620, August 2009,
              <https://www.rfc-editor.org/info/rfc5620>.

McPherson, et al.        Expires April 13, 2019                [Page 10]
Internet-Draft         Role of Registry Operators           October 2018

Appendix A.  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.

Appendix B.  IAB members

   Internet Architecture Board Members at the time this document was
   approved for publication were [To Be Confirmed]:

      Jari Arkko,
      Alissa Cooper,
      Ted Hardie,
      Christian Huitema,
      Gabriel Montenegro,
      Erik Nordmark,
      Mark Nottingham,
      Melinda Shore,
      Robert Sparks,
      Jeff Tantsura,
      Martin Thomson,
      Brian Trammell, and
      Suzanne Woolf.

Appendix C.  Document Editing Details

   [Text between square brackets starting with initials are editor
   notes.  Any other text between square brackets assumes an action by
   the RFC editor prior to publication as an RFC.  In most cases this
   will be removal, sometimes a stylistic or editorial choices ore
   question is indicated]

   [This section and its subsections should be removed at publication as
   RFC, so should the Cover Note]

C.1.  Version Information

McPherson, et al.        Expires April 13, 2019                [Page 11]
Internet-Draft         Role of Registry Operators           October 2018

C.1.1.  draft-iab-iasa2-rfc6220-00

      Original RFC text backported into XML.  With only Editor
      affiliaton changed and IAB members section emptied

C.1.2.  draft-iab-iasa2-rfc6220-01

      Changed references to IAOC to LLC
      While reviewing the section on the Trust: Modified reference to
      RFC 4748 to reference to RFC4371, as that document estabishes the
      Trust while 4748 is technically an update of RFC 3978 (now
      obsoleted).
      Updated reference to ICANN-IETF MoU to most recent version (2018).

C.1.3.  TODO/Open issues

   o  In the Overview under "Reporting" [MoU_SUPP2018] is refered to as
      an example i.e. an informative document.  Updated to a more recent
      version.  The reference is not IAOC specific, is it appropriate?
   o  Editorial question: Is the prefered abbriviation IETF
      Administrational LLC or just LLC?

C.2.  RCS information

   $Id: rfc6220bis.xml,v 1.4 2018/10/02 12:07:52 olaf Exp $

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

McPherson, et al.        Expires April 13, 2019                [Page 12]
Internet-Draft         Role of Registry Operators           October 2018

   Geoff Huston (editor)
   APNIC

   EMail: gih@apnic.net

   Internet Architecture Board

   EMail: iab@iab.org

McPherson, et al.        Expires April 13, 2019                [Page 13]