Defining the Role and Function of IETF Protocol Parameter Registry Operators
RFC 8722
Document | Type |
RFC - Informational
(February 2020; No errata)
Obsoletes RFC 6220
Was draft-ietf-iasa2-rfc6220bis (individual)
|
|
---|---|---|---|
Authors | Danny McPherson , Olaf Kolkman , John Klensin , Geoff Huston , IAB | ||
Last updated | 2020-03-09 | ||
Stream | IAB | ||
Formats | plain text html xml pdf htmlized bibtex | ||
Stream | IAB state | Published RFC | |
Consensus Boilerplate | Yes | ||
RFC Editor Note | (None) |
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 secretariatShow full document text