Registry policies “… with Expert Review”
Internet-Draft draft-bormann-gendispatch-with-expert-review-01
Carsten Bormann
Universität Bremen TZI
Postfach 330440
Bremen
D-28359
Germany
+49-421-218-63921
cabo@tzi.org
Marco Tiloca
RISE AB
Isafjordsgatan 22
Kista
16440 Stockholm
Sweden
marco.tiloca@ri.se
06 October 2024
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.
About This Document
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-bormann-gendispatch-with-expert-review/.
Discussion of this document takes place on the gendispatch Working Group mailing list (mailto:gendispatch@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/gendispatch/. Subscribe at https://www.ietf.org/mailman/listinfo/gendispatch/.
Source for this draft and an issue tracker can be found at https://github.com/cabo/with-expert-review.
Introduction
Section 4 of RFC 8126 [BCP26] 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 4.5 and 4.6 of RFC 8126 [BCP26]). Some other policies involve a review body that autonomously, not involving a Designated Expert, decide whether a registration should be accepted (Sections 4.7, 4.8, 4.9, and 4.10 of RFC 8126 [BCP26]).
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 4 of RFC 8126 [BCP26], 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 2 and 3 of RFC 7120 [BCP100] with the necessary process to perform early allocations for registries with one of the augmented policies.
Augmented Registration Policies
For each of the well-known policies defined in Sections 4.7, 4.8, 4.9, and 4.10 of RFC 8126 [BCP26], this document adds a parallel augmented policy that also specifies involving a Designated Expert.
RFC Required With Expert Review
This policy is identical to a combination of Sections 4.6 and 4.7 of RFC 8126 [BCP26]. The RFC to be published serves as the documentation required by Section 4.6 of RFC 8126 [BCP26]. It is the responsibility of the stream approving body (see Section 5.1 of [RFC8729]) 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 4.6 and 4.8 of RFC 8126 [BCP26]. The RFC to be published serves as the documentation required by Section 4.6 of RFC 8126 [BCP26]. 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 4.6 and 4.9 of RFC 8126 [BCP26], mirroring the requirements of Section 2.2 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 4.5 or Section 4.6 with Section 4.10 of RFC 8126 [BCP26], 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 [BCP100] to apply to the augmented policies defined above in Section 2.1, Section 2.2, and Section 2.3.
Specifically:
- Item (a) in Section 2 of RFC 7120 [BCP100] is extended to include the three augmented policies "RFC Required With Expert Review", "IETF Review With Expert Review", and "Standards Action With Expert Review" (see Sections 2.1, 2.2, and 2.3 of the present document, respectively).
- Item (2) in Section 3.1 of RFC 7120 [BCP100] is amended as follows:
2. 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 Section 2 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 5 of RFC 7120 [BCP100] and Section 12 of RFC 8126 [BCP26] 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
[RFC7120]

Early IANA Allocation of Standards Track Code Points
M. Cotton
January 2014
BCP 100
RFC 7120
DOI 10.17487/RFC7120
[RFC8126]

Guidelines for Writing an IANA Considerations Section in RFCs
M. Cotton
B. Leiba
T. Narten
June 2017
BCP 26
RFC 8126
DOI 10.17487/RFC8126
[RFC8729]

The RFC Series and RFC Editor
R. Housley, Ed.
L. Daigle, Ed.
February 2020
RFC 8729
DOI 10.17487/RFC8729
Informative References
[IANA.uuid]

UUID
IANA
[I-D.ietf-uuidrev-rfc4122bis-14]

Universally Unique IDentifiers (UUID)
Kyzer R. Davis
Cisco Systems
Brad Peabody
Uncloud
P. Leach
University of Washington
6 November 2023
Internet-Draft draft-ietf-uuidrev-rfc4122bis-14
[IANA.cose]

CBOR Object Signing and Encryption (COSE)
IANA
[RFC9052]

CBOR Object Signing and Encryption (COSE): Structures and Process
J. Schaad
August 2022
STD 96
RFC 9052
DOI 10.17487/RFC9052
[RFC8152]

CBOR Object Signing and Encryption (COSE)
J. Schaad
July 2017
RFC 8152
DOI 10.17487/RFC8152
[IANA.ace]

Authentication and Authorization for Constrained Environments (ACE)
IANA
[RFC9203]

The Object Security for Constrained RESTful Environments (OSCORE) Profile of the Authentication and Authorization for Constrained Environments (ACE) Framework
F. Palombini
L. Seitz
G. Selander
M. Gunnarsson
August 2022
RFC 9203
DOI 10.17487/RFC9203
[RFC9393]

Concise Software Identification Tags
H. Birkholz
J. Fitzgerald-McKay
C. Schmidt
D. Waltermire
June 2023
RFC 9393
DOI 10.17487/RFC9393
[RFC9528]

Ephemeral Diffie-Hellman Over COSE (EDHOC)
G. Selander
J. Preuß Mattsson
F. Palombini
March 2024
RFC 9528
DOI 10.17487/RFC9528
[RFC8881]

Network File System (NFS) Version 4 Minor Version 1 Protocol
D. Noveck, Ed.
C. Lever
August 2020
RFC 8881
DOI 10.17487/RFC8881
[RFC5661]

Network File System (NFS) Version 4 Minor Version 1 Protocol
S. Shepler, Ed.
M. Eisler, Ed.
D. Noveck, Ed.
January 2010
RFC 5661
DOI 10.17487/RFC5661
[RFC5226]

Guidelines for Writing an IANA Considerations Section in RFCs
T. Narten
H. Alvestrand
May 2008
RFC 5226
DOI 10.17487/RFC5226
[RFC4430]

Kerberized Internet Negotiation of Keys (KINK)
S. Sakane
K. Kamada
M. Thomas
J. Vilhuber
March 2006
RFC 4430
DOI 10.17487/RFC4430
[RFC6787]

Media Resource Control Protocol Version 2 (MRCPv2)
D. Burnett
S. Shanmugham
November 2012
RFC 6787
DOI 10.17487/RFC6787
[RFC5797]

FTP Command and Extension Registry
J. Klensin
A. Hoenes
March 2010
RFC 5797
DOI 10.17487/RFC5797
Usage in Existing Specifications
This appendix is informative.
Examples for RFCs (and one RFC-to-be) and registries created from them that use "Standards Action with Expert Review", without further explanation of this usage, include:
- [IANA.uuid], interpreting the approved [I-D.ietf-uuidrev-rfc4122bis-14]
- [IANA.cose], interpreting Section 11 of [RFC9052] in conjunction with the older Section 16 of [RFC8152]
- [IANA.ace], interpreting Section 9 of [RFC9203]
- Section 6 of [RFC9393]
- Section 10 of [RFC9528]
Related Policy Statements Potentially of Interest
In a number of places, [RFC8881] 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 [BCP100]. RFC 8881's predecessor [RFC5661] 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 [RFC5226], the precursor of RFC 8126, which listed the well-known policies in its Section 4.1.)
[RFC4430] (written before [RFC5226]) uses this phrasing:
- Assignment from the "RESERVED TO IANA" range needs Standards Action, or non-standards-track RFCs with Expert Review.
Somewhat unrelated, [RFC6787] uses the redundant phrase "Specification Required with Expert Review". Section 5 of [RFC5797] 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.