5. Designated Experts (指定专家)

5.1. The Motivation for Designated Experts (指定专家的动机)

邮件列表上的讨论可以提供有价值的技术反馈, 但意见往往各不相同, 讨论可能会持续一段时间而没有明确的解决方案。此外, IANA 无法参与所有这些邮件列表, 也无法确定这些讨论是否或何时达成共识。因此, IANA 依赖"指定专家" (designated expert) 就是否应该进行分配这一具体问题提供建议。指定专家是负责进行适当评估并向 IANA 返回建议的个人。

应该注意的是, 设立指定专家的一个关键动机是让 IETF 为 IANA 提供一个主题专家 (subject matter expert), 可以将评估过程委托给该专家。IANA 将分配请求转发给专家进行评估, 专家 (在执行评估后) 通知 IANA 是否进行分配或注册。在大多数情况下, 注册者不直接与指定专家合作。注册表的指定专家列表会列在注册表中。

通常, 将指定专家仅在某些时候使用, 作为其他流程的补充, 会很有用。有关该主题的更多讨论, 请参见第 4.12 节。

5.2. The Role of the Designated Expert (指定专家的角色)

指定专家负责协调对分配请求的适当审查。审查范围可以是广泛的或狭窄的, 这取决于具体情况和指定专家的判断。这可能涉及与一组技术专家进行咨询, 在公共邮件列表上进行讨论, 与工作组 (或其邮件列表, 如果工作组已解散) 进行咨询等。理想情况下, 指定专家遵循创建或使用该命名空间的协议文档中记录的特定审查标准。有关具体示例, 请参见 [RFC3748] 和 [RFC3575] 的 IANA Considerations 章节。

指定专家应该能够向 IETF 社区捍卫他们的决定, 评估过程不应该是秘密的, 也不应该赋予专家无可置疑的权力。专家应该应用适用的已记录的审查或审核程序, 或者在没有记录标准的情况下, 遵循普遍接受的规范, 如第 5.3 节中所述。通常不期望指定专家成为"把关者" (gatekeepers), 试图使注册难以获得, 除非定义文档中的指导明确规定他们应该这样做。在没有更强有力的指导的情况下, 专家应该评估注册请求的完整性, 互操作性, 以及与现有协议和选项的冲突。

对于某些注册表, 拥有多个指定专家已被证明是有用的。有时这些专家共同评估一个请求, 而在其他情况下, 额外的专家充当后备, 仅在主要专家不可用时才采取行动。在拥有专家池的注册表中, 该池通常有一个单一的主席, 负责定义如何将请求分配给专家以及由专家审查。在其他情况下, IANA 可能按顺序或近似随机顺序将请求分配给各个成员。定义注册表的文档可以 (如果适合该情况) 指定组应该如何工作 -- 例如, 可能适合在邮件列表上, 在相关工作组内或在指定专家池中指定粗略共识 (rough consensus)。

在多个专家之间存在分歧的情况下, 这些专家有责任向 IANA 提出一个单一明确的建议。IANA 不适合解决专家之间的争议。在极端情况下, 如僵局, 指定机构可能需要介入解决问题。

如果指定专家对特定审查存在利益冲突 (例如, 是与正在审查的注册相关的规范的作者或重要支持者), 该专家应该回避。如果所有指定专家都存在冲突, 他们应该要求为有冲突的审查指定一个临时专家。负责的 AD 可以任命某人, 或者 AD 可以处理审查。

本文档仅针对 IETF 流 (IETF stream) 中的文档定义指定专家机制。如果其他流想要使用需要指定专家的注册策略, 则由这些流 (或这些文档) 来指定如何任命和管理这些指定专家。下面描述的由 IESG 管理的方式仅适用于 IETF 流。

5.2.1. Managing Designated Experts in the IETF (在 IETF 中管理指定专家)

为 IETF 创建的注册表的指定专家由 IESG 任命, 通常是根据相关领域主管 (Area Director) 的推荐。他们可以在 IESG 批准创建或更新命名空间的文档时任命, 或者随后在收到第一个注册请求时任命。由于最初任命的专家可能后来变得不可用, IESG 将根据需要任命替代者。IESG 可以自行决定移除其任命的任何指定专家。

正常的申诉程序, 如 [RFC2026] 第 6.5.1 节所述, 适用于指定专家团队出现的问题。为此, 指定专家团队在该描述中取代了工作组的位置。

5.3. Designated Expert Reviews (指定专家审查)

自 [RFC2434] 发布并投入使用以来的这些年里, 经验导致了以下观察:

指定专家必须及时响应, 通常对于简单的请求在一周内, 对于更复杂的请求在几周内。不合理的延迟可能会给需要分配的人造成重大问题, 例如当产品需要代码点 (code points) 来发货时。这并不是说所有审查都可以在严格的截止日期内完成, 但它们必须开始, 如果不能快速给出答案, 请求者和 IANA 应该对过程有一些透明度。
如果指定专家在合理的时间内没有响应 IANA 的请求, 无论是回复还是对延迟的合理解释 (某些请求可能特别复杂), 并且如果这是一个反复发生的事件, IANA 必须向 IESG 提出这个问题。由于延迟评估和分配造成的问题, IESG 应该采取适当的行动来确保专家理解并接受其职责, 或者任命一位新的专家。
指定专家不需要亲自承担评估和决定所有请求的负担, 而是充当请求的协调者 (shepherd), 根据需要寻求他人的帮助。如果请求被拒绝, 并且拒绝请求可能会引起争议, 专家应该得到其他主题专家的支持。也就是说, 专家必须能够向整个社区捍卫一个决定。

当使用指定专家时, 文档应该为指定专家提供明确的指导, 列出执行评估的标准和拒绝请求的理由。在没有特定记录标准的情况下, 假设应该是代码点应该被授予, 除非有令人信服的相反理由 (另请参见第 5.4 节)。已被用于拒绝请求的理由包括:

代码点稀缺, 其中有限的剩余代码点应该谨慎管理, 或者请求大量代码点而单个代码点是常规的情况。
文档不够清晰, 无法评估或确保互操作性。
需要代码点来进行协议扩展, 但该扩展与正在扩展的基础协议的记录 (或普遍理解) 架构不一致, 如果广泛部署将对协议有害。这并不是说"不一致"是指"个人偏好性质"的轻微差异。相反, 它们指的是重大差异, 例如与底层安全模型的不一致, 暗示对现有消息类型或操作语义的更改, 需要在已部署系统中进行不必要的更改 (与实现类似结果的替代方法相比) 等。
扩展会对现有已部署系统造成问题。
扩展会与 IETF 正在积极开发的扩展冲突, 同时拥有两者会损害而不是促进互操作性。

文档本身不得命名指定专家; 相反, 任何建议的名称应该在文档发送给 IESG 批准时转达给适当的领域主管。这通常在文档协调者总结 (document shepherd writeup) 中完成。

如果请求还应该在特定的公共邮件列表上进行审查, 应该指定其地址。

5.4. Expert Reviews and the Document Lifecycle (专家审查与文档生命周期)

指定专家的审查必然是在特定时间点进行的, 代表了对文档特定版本的审查。虽然审查通常在 IETF Last Call 前后进行, 但决定何时进行审查是一个良好判断的问题。虽然当确认注册项的文档已发生重大变化时可能会进行重新审查, 但确保重新审查发生需要关注和谨慎。

通过粗心, 意外, 疏忽, 甚至故意无视, 可能会在指定专家审查和批准后进行更改, 如果重新审查文档, 这些更改将导致专家不批准注册。由负责的领域主管持有令牌的 IESG 有责任警惕这种情况, 并认识到需要检查这些更改。

对于从标准轨道 (Standards Track) 文档进行的注册, 通常需要专家审查 (根据注册策略) 以及 IETF 共识 (用于批准为标准轨道 RFC)。在这种情况下, 指定专家的审查需要及时, 在 IESG 评估文档之前提交。IESG 通常不应该因为等待延迟的审查而推迟文档。专家审查也不是为了推翻 IETF 共识: IESG 应该在自己的评估中考虑审查, 就像对其他 Last Call 审查所做的那样。