]> Registry policies “… with Expert Review” Universität Bremen TZI
Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org
RISE AB
Isafjordsgatan 22 Kista 16440 Stockholm Sweden marco.tiloca@ri.se
General General Area Dispatch IANA Designated Expert This document updates RFC 8126, adding registry policies that augment an existing policy that is based on a review body action with the additional requirement for a Designated Expert review. It also updates RFC 7120 with the necessary process to perform early allocations for registries with one of the augmented policies. To support its objectives for the period of time while the above updates have not yet been finalized, this document offers text that can be copy-pasted into specifications that want to make use of the augmented policies. —— Editors' note: ——
As to augmenting existing policies, the provided proposals have been considered in within the IANABIS Working Group.
This topic is covered by of our draft and there is a placeholder "ADD NEW PROCEDURE" about it at . However, compared to our draft, this is not augmenting the policy "IESG Approval".
On the topic of early registration covered by of our draft, we were under the impression that something similar could be argued about it too, but not quite (yet).
Looking at , there seems to be no text or placeholders on that topic yet. We expect such text to come in the future, to ensure that the early allocation procedure is fully specified also for registries that use the augmented policies. About This Document Status information for this document may be found at . Discussion of this document takes place on the gendispatch Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .
Introduction Section of RFC 8126 defines a number of well-known policies that can be referenced as registration policies from documents that set up IANA registries. Some of these policies involve a Designated Expert, who is intended to be aware of the fine points of what should or should not become a registration in that registry (Sections and of RFC 8126 ). Some other policies involve a review body that autonomously, not involving a Designated Expert, decide whether a registration should be accepted (Sections , , , and of RFC 8126 ). In the past, this has occasionally led to friction where a Designated Expert was not consulted by the review body before approving the registration, missing some finer point (such as certain consistency requirements) that would have been pointed out by the expert. As additional rationale that may be too detailed for the published version of this document, https://github.com/cabo/with-expert-review/issues/1 contains an example where the Designated Expert is needed to maintain overall consistency (and additional efficiency, if desired). (This editors' note will be deleted by the RFC editor.) This document updates Section of RFC 8126 , adding registry policies that augment an existing policy that is based on a review body action with the additional requirement for a Designated Expert review. It also updates Sections and of RFC 7120 with the necessary process to perform early allocations for registries with one of the augmented policies. To support its objectives for the period of time while the above updates have not yet been finalized, this document offers text that can be copy-pasted into specifications that want to make use of the augmented policies.
Augmented Registration Policies For each of the well-known policies defined in Sections , , , and of RFC 8126 , this document adds a parallel augmented policy that also specifies involving a Designated Expert. For the period of time while has not been updated to include the augmented registration policies, authors of specifications that want to make use of these can simply copy the pertinent section below, replace "This policy" with "The policy for this registry", and use the result in the individual sections that establish new registries.
RFC Required With Expert Review This policy is identical to a combination of Sections and of RFC 8126 . The RFC to be published serves as the documentation required by Section of RFC 8126 . It is the responsibility of the stream approving body (see ) to ensure that an approval for the registration by the Designated Expert is obtained before approving the RFC establishing the registration.
IETF Review With Expert Review This policy is identical to a combination of Sections and of RFC 8126 . The RFC to be published serves as the documentation required by Section of RFC 8126 . It is the responsibility of the IESG to ensure that an approval for the registration by the Designated Expert is obtained before approving the RFC establishing the registration.
Standards Action With Expert Review This policy is identical to a combination of Sections and of RFC 8126 , mirroring the requirements of narrowed down to a certain type of RFC to be published.
IESG Approval With Expert Review This policy is identical to a combination of either Section or Section with Section of RFC 8126 , depending on the discretion of the IESG mentioned in the first paragraph of the latter section (which may be additionally informed by input from the Designated Expert). It is the responsibility of the IESG to ensure that an approval for the registration by the Designated Expert is obtained before approving the registration.
Early Allocation for Augmented Registration Policies This document updates RFC 7120 to apply to the augmented policies defined above in , , and . For the period of time while has not been updated in this respect, authors of specifications can use text that builds on , in a section that establishes a new registry using one of the augmented registration policies:
[...] The procedure for early IANA allocation of "standards track code points" defined in [] also applies. When such a procedure is used, IANA will ask the designated expert(s) to approve the early allocation before registration. In addition, working group chairs are encouraged to consult the expert(s) early during the process outlined in .
Specifically:
  • Item (a) in Section of RFC 7120 is extended to include the three augmented policies "", "", and "" (see Sections , , and of the present document, respectively).
  • Item (2) in Section of RFC 7120 is amended as follows:
  1. The WG chairs determine whether the conditions for early allocations described in Section 2 are met, particularly conditions (c) and (d). For the registration policies defined in of RFC-XXXX, IANA will ask the Designated Expert(s) to approve the early allocation before registration. In addition, WG chairs are encouraged to consult the Expert(s) early during the early allocation process.
RFC editor: please replace XXXX by the RFC number of this document and delete this note.
Security Considerations The security considerations of Section of RFC 7120 and Section of RFC 8126 apply. Augmenting registration policies by Designated Expert involvement may help reduce the potential of introducing security issues by adding inconsistent or insecure registrations to a registry.
IANA Considerations This document is all about procedures that need to be implemented by IANA, but by itself has no IANA actions.
References Normative References Early IANA Allocation of Standards Track Code Points This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. The RFC Series and RFC Editor This document describes the framework for an RFC Series and an RFC Editor function that incorporate the principles of organized community involvement and accountability that has become necessary as the Internet technical community has grown, thereby enabling the RFC Series to continue to fulfill its mandate. This document obsoletes RFC 4844. Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the Constrained Application Protocol (CoAP) and Object Security for Constrained RESTful Environments (OSCORE) The lightweight authenticated key exchange protocol Ephemeral Diffie-Hellman Over COSE (EDHOC) can be run over the Constrained Application Protocol (CoAP) and used by two peers to establish a Security Context for the security protocol Object Security for Constrained RESTful Environments (OSCORE). This document details this use of the EDHOC protocol by specifying a number of additional and optional mechanisms, including an optimization approach for combining the execution of EDHOC with the first OSCORE transaction. This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. Informative References Guidelines for Writing an IANA Considerations Section in RFCs Internet Assigned Numbers Authority Internet Assigned Numbers Authority Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the fourth edition of this document; it obsoletes RFC 8126. Early IANA Code Point Allocation for IETF Stream Internet-Drafts Internet Assigned Numbers Authority Internet Assigned Numbers Authority This memo describes the requirements for securing IANA code point assignments before RFC publication. In particular, it describes the "early allocation" process that allows for temporary but renewable allocations from registries that would ordinarily require an IESG- approved Internet-Draft: primarily, registries maintained in accordance with the "Standards Action," "IETF Review," "RFC Required," and, in some cases, "Specification Required" policies described in RFC 8126. This process can be used when code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication. The procedures in this document are intended to apply only to IETF Stream documents. This document obsoletes RFC 7120. CBOR Object Signing and Encryption (COSE) IANA CBOR Object Signing and Encryption (COSE): Structures and Process Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. CBOR Object Signing and Encryption (COSE) Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. Authentication and Authorization for Constrained Environments (ACE) IANA The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. Concise Software Identification Tags ISO/IEC 19770-2:2015 Software Identification (SWID) tags provide an extensible XML-based structure to identify and describe individual software components, patches, and installation bundles. SWID tag representations can be too large for devices with network and storage constraints. This document defines a concise representation of SWID tags: Concise SWID (CoSWID) tags. CoSWID supports a set of semantics and features that are similar to those for SWID tags, as well as new semantics that allow CoSWIDs to describe additional types of information, all in a more memory-efficient format. Ephemeral Diffie-Hellman Over COSE (EDHOC) This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding, and Constrained Application Protocol (CoAP) for transport, the additional code size can be kept very low. UUID IANA Universally Unique IDentifiers (UUIDs) This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. Network File System (NFS) Version 4 Minor Version 1 Protocol This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 7530) and protocol extensions made subsequently. The later minor version has no dependencies on NFS version 4 minor version 0, and is considered a separate protocol. This document obsoletes RFC 5661. It substantially revises the treatment of features relating to multi-server namespace, superseding the description of those features appearing in RFC 5661. Network File System (NFS) Version 4 Minor Version 1 Protocol This document describes the Network File System (NFS) version 4 minor version 1, including features retained from the base protocol (NFS version 4 minor version 0, which is specified in RFC 3530) and protocol extensions made subsequently. Major extensions introduced in NFS version 4 minor version 1 include Sessions, Directory Delegations, and parallel NFS (pNFS). NFS version 4 minor version 1 has no dependencies on NFS version 4 minor version 0, and it is considered a separate protocol. Thus, this document neither updates nor obsoletes RFC 3530. NFS minor version 1 is deemed superior to NFS minor version 0 with no loss of functionality, and its use is preferred over version 0. Both NFS minor versions 0 and 1 can be used simultaneously on the same network, between the same client and server. [STANDARDS-TRACK] Guidelines for Writing an IANA Considerations Section in RFCs 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 transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA. This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Kerberized Internet Negotiation of Keys (KINK) This document describes the Kerberized Internet Negotiation of Keys (KINK) protocol. KINK defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. KINK reuses the Quick Mode payloads of the Internet Key Exchange (IKE), which should lead to substantial reuse of existing IKE implementations. [STANDARDS-TRACK] Media Resource Control Protocol Version 2 (MRCPv2) The Media Resource Control Protocol Version 2 (MRCPv2) allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers, and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol -- it relies on other protocols, such as the Session Initiation Protocol (SIP), to coordinate MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover, and exchange capabilities. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server. [STANDARDS-TRACK] FTP Command and Extension Registry Every version of the FTP specification has added a few new commands, with the early ones summarized in RFC 959. RFC 2389 established a mechanism for specifying and negotiating FTP extensions. The number of extensions, both those supported by the mechanism and some that are not, continues to increase. An IANA registry of FTP Command and Feature names is established to reduce the likelihood of conflict of names and the consequent ambiguity. This specification establishes that registry. [STANDARDS-TRACK]
Usage in Existing Specifications This appendix is informative. Examples for RFCs and registries created from them that use "Standards Action with Expert Review", without further explanation of this usage, include:
  • Several registries of , interpreting in conjunction with the older
  • Several registries of , interpreting
  • of , interpreting
Related Policy Statements Potentially of Interest In a number of places, uses phrasing such as:
Hence, all assignments to the registry are made on a Standards Action basis per Section 4.6 of [63], with Expert Review required.
(here, [63] is a reference to RFC 8126 . RFC 8881's predecessor used:)
All assignments to the registry are made on a Standards Action basis per Section 4.1 of [55], with Expert Review required.
(here, [55] is a reference to , the precursor of RFC 8126, which listed the well-known policies in its Section .) (written before ) uses this phrasing:
  • Assignment from the "RESERVED TO IANA" range needs Standards Action, or non-standards-track RFCs with Expert Review.
Somewhat unrelated, uses the redundant phrase "Specification Required with Expert Review". uses related phrasing for a more complicated requirement.
Acknowledgments The creation of this document was prompted by an IESG ballot comment from John Scudder, which led to the observation that the now somewhat common practice of augmenting review-body-based registry policies by Expert Review had not been documented sufficiently.