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 によって作成されたレジストリの指定専門家は, 通常, 関連するエリアディレクター (Area Director) の推薦に基づいて IESG によって任命されます。彼らは, IESG が名前空間を作成または更新する文書を承認する時点で任命される場合もあれば, その後最初の登録要求が受領されたときに任命される場合もあります。当初任命された専門家が後に利用できなくなる可能性があるため, IESG は必要に応じて代替者を任命します。IESG は, その裁量により, 任命した指定専門家を解任することができます。

[RFC2026] のセクション 6.5.1 に記載されている通常の異議申し立てプロセスは, 指定専門家チームで発生する問題に適用されます。この目的のために, 指定専門家チームはその説明においてワーキンググループの代わりをします。

5.3. Designated Expert Reviews (指定専門家レビュー)

[RFC2434] が公開され使用されて以来の数年間で, 経験は以下の観察につながりました:

指定専門家は, 通常, 単純な要求の場合は 1 週間以内, より複雑な要求の場合は数週間以内にタイムリーに応答しなければなりません。不合理な遅延は, 製品が出荷するためにコードポイント (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 レビューに対して行うように, 自身の評価においてレビューを考慮する必要があります。