5. Designated Experts

5.1. The Motivation for Designated Experts

Discussion on a mailing list can provide valuable technical feedback, but opinions often vary and discussions may continue for some time without clear resolution. In addition, IANA cannot participate in all of these mailing lists and cannot determine if or when such discussions reach consensus. Therefore, IANA relies on a "designated expert" for advice regarding the specific question of whether an assignment should be made. The designated expert is an individual who is responsible for carrying out an appropriate evaluation and returning a recommendation to IANA.

It should be noted that a key motivation for having designated experts is for the IETF to provide IANA with a subject matter expert to whom the evaluation process can be delegated. IANA forwards requests for an assignment to the expert for evaluation, and the expert (after performing the evaluation) informs IANA as to whether or not to make the assignment or registration. In most cases, the registrants do not work directly with the designated experts. The list of designated experts for a registry is listed in the registry.

It will often be useful to use a designated expert only some of the time, as a supplement to other processes. For more discussion of that topic, see Section 4.12.

5.2. The Role of the Designated Expert

The designated expert is responsible for coordinating the appropriate review of an assignment request. The review may be wide or narrow, depending on the situation and the judgment of the designated expert. This may involve consultation with a set of technology experts, discussion on a public mailing list, consultation with a working group (or its mailing list if the working group has disbanded), etc. Ideally, the designated expert follows specific review criteria as documented with the protocol that creates or uses the namespace. See the IANA Considerations sections of [RFC3748] and [RFC3575] for specific examples.

Designated experts are expected to be able to defend their decisions to the IETF community, and the evaluation process is not intended to be secretive or bestow unquestioned power on the expert. Experts are expected to apply applicable documented review or vetting procedures, or in the absence of documented criteria, follow generally accepted norms such as those in Section 5.3. Designated experts are generally not expected to be "gatekeepers", setting out to make registrations difficult to obtain, unless the guidance in the defining document specifies that they should act as such. Absent stronger guidance, the experts should be evaluating registration requests for completeness, interoperability, and conflicts with existing protocols and options.

It has proven useful to have multiple designated experts for some registries. Sometimes those experts work together in evaluating a request, while in other cases additional experts serve as backups, acting only when the primary expert is unavailable. In registries with a pool of experts, the pool often has a single chair responsible for defining how requests are to be assigned to and reviewed by experts. In other cases, IANA might assign requests to individual members in sequential or approximate random order. The document defining the registry can, if it's appropriate for the situation, specify how the group should work -- for example, it might be appropriate to specify rough consensus on a mailing list, within a related working group or among a pool of designated experts.

In cases of disagreement among multiple experts, it is the responsibility of those experts to make a single clear recommendation to IANA. It is not appropriate for IANA to resolve disputes among experts. In extreme situations, such as deadlock, the designating body may need to step in to resolve the problem.

If a designated expert has a conflict of interest for a particular review (is, for example, an author or significant proponent of a specification related to the registration under review), that expert should recuse himself. In the event that all the designated experts are conflicted, they should ask that a temporary expert be designated for the conflicted review. The responsible AD may then appoint someone or the AD may handle the review.

This document defines the designated expert mechanism with respect to documents in the IETF stream only. If other streams want to use registration policies that require designated experts, it is up to those streams (or those documents) to specify how those designated experts are appointed and managed. What is described below, with management by the IESG, is only appropriate for the IETF stream.

5.2.1. Managing Designated Experts in the IETF

Designated experts for registries created by the IETF are appointed by the IESG, normally upon recommendation by the relevant Area Director. They may be appointed at the time a document creating or updating a namespace is approved by the IESG, or subsequently, when the first registration request is received. Because experts originally appointed may later become unavailable, the IESG will appoint replacements as necessary. The IESG may remove any designated expert that it appointed, at its discretion.

The normal appeals process, as described in [RFC2026], Section 6.5.1, applies to issues that arise with the designated expert team. For this purpose, the designated expert team takes the place of the working group in that description.

5.3. Designated Expert Reviews

In the years since [RFC2434] was published and put to use, experience has led to the following observations:

A designated expert must respond in a timely fashion, normally within a week for simple requests to a few weeks for more complex ones. Unreasonable delays can cause significant problems for those needing assignments, such as when products need code points to ship. This is not to say that all reviews can be completed under a firm deadline, but they must be started, and the requester and IANA should have some transparency into the process if an answer cannot be given quickly.
If a designated expert does not respond to IANA's requests within a reasonable period of time, either with a response or with a reasonable explanation for the delay (some requests may be particularly complex), and if this is a recurring event, IANA must raise the issue with the IESG. Because of the problems caused by delayed evaluations and assignments, the IESG should take appropriate actions to ensure that the expert understands and accepts his or her responsibilities, or appoint a new expert.
The designated expert is not required to personally bear the burden of evaluating and deciding all requests, but acts as a shepherd for the request, enlisting the help of others as appropriate. In the case that a request is denied, and rejecting the request is likely to be controversial, the expert should have the support of other subject matter experts. That is, the expert must be able to defend a decision to the community as a whole.

When a designated expert is used, the documentation should give clear guidance to the designated expert, laying out criteria for performing an evaluation and reasons for rejecting a request. In the case where there are no specific documented criteria, the presumption should be that a code point should be granted unless there is a compelling reason to the contrary (and see also Section 5.4). Reasons that have been used to deny requests have included these:

Scarcity of code points, where the finite remaining code points should be prudently managed, or where a request for a large number of code points is made and a single code point is the norm.
Documentation is not of sufficient clarity to evaluate or ensure interoperability.
The code point is needed for a protocol extension, but the extension is not consistent with the documented (or generally understood) architecture of the base protocol being extended and would be harmful to the protocol if widely deployed. It is not the intent that "inconsistencies" refer to minor differences "of a personal preference nature". Instead, they refer to significant differences such as inconsistencies with the underlying security model, implying a change to the semantics of an existing message type or operation, requiring unwarranted changes in deployed systems (compared with alternate ways of achieving a similar result), etc.
The extension would cause problems with existing deployed systems.
The extension would conflict with one under active development by the IETF, and having both would harm rather than foster interoperability.

Documents must not name the designated expert(s) in the document itself; instead, any suggested names should be relayed to the appropriate Area Director at the time the document is sent to the IESG for approval. This is usually done in the document shepherd writeup.

If the request should also be reviewed on a specific public mailing list, its address should be specified.

5.4. Expert Reviews and the Document Lifecycle

Review by the designated expert is necessarily done at a particular point in time and represents review of a particular version of the document. While reviews are generally done around the time of IETF Last Call, deciding when the review should take place is a question of good judgment. And while rereviews might be done when it's acknowledged that the documentation of the registered item has changed substantially, making sure that rereview happens requires attention and care.

It is possible, through carelessness, accident, inattentiveness, or even willful disregard, that changes might be made after the designated expert's review and approval that would, if the document were rereviewed, cause the expert not to approve the registration. It is up to the IESG, with the token held by the responsible Area Director, to be alert to such situations and to recognize that such changes need to be checked.

For registrations made from documents on the Standards Track, there is often expert review required (by the registration policy) in addition to IETF consensus (for approval as a Standards Track RFC). In such cases, the review by the designated expert needs to be timely, submitted before the IESG evaluates the document. The IESG should generally not hold the document up waiting for a late review. It is also not intended for the expert review to override IETF consensus: the IESG should consider the review in its own evaluation, as it would do for other Last Call reviews.