要約

  • RFC 5226 の指定専門家は、特定の割当てを行うべきかを助言する。名前空間の所有者ではなく、IANA も政策立案者ではない。メーリングリストへの参加は決定権への委任ではない。
  • 現行の後継文書 RFC 8126 は、提出情報、評価基準、拒否理由、忌避、代替、変更管理、審査対象版、異議申立てという制御面を一層明確にした。
  • 登録値は、ある時点のある申請が所定手続を通ったことを示すにすぎない。製品の安全性、実装、展開、相互運用の実績を証明するものではない。

専門性では再現できないもの

同じ申請書を二人の優れた技術者に渡せば、二つの慎重な判断が返るかもしれない。一人は脅威モデルを求め、もう一人は独立実装を重視する。どちらも工学的には正しい。だが、レジストリを作った文書が証拠要件も拒否基準も書かなかったなら、申請者は事前に義務を知れず、後から同等事例を比較できない。

これは専門家の力量の問題ではない。組織が「誰に聞くか」を決めながら、「何を根拠に答えるか」を未決定のまま残した問題である。指名は席を埋める。委任はその席から動かせる範囲を定める。

RFC 5226 は 2008 年 5 月に BCP 26 として発行された。IANA は割当て方針を作るのではなく、他者が定め RFC で公表した方針を実施する、という抑制が中心にある。プレーンテキストでは役割の連鎖を追いやすい。Datatracker 版、RFC Editor の状態、履歴、正誤情報は、同文書が現在の規則ではなく、2017 年に RFC 8126 に置き換えられた歴史的対象であることも示す。

したがって監査すべきは、専門家が信頼できる人物かどうかだけではない。どの資料を要求でき、どの欠陥で拒否でき、どの版を見て、衝突時に誰が代わり、どこへ異議を申し立てられるかである。

一行の背後にある分業

画面上のレジストリエントリーは一行でも、その周囲には異なる主体がいる。定義 RFC は名前空間、申請項目、審査方式、記法、初期割当てや予約を決める。IANA は受付を運用し結果を記録する。IETF ストリームのレジストリでは IESG が専門家を指名し、必要なら交代させる。専門家は審査を調整し、個別の割当てについて勧告する。通常の手続が異議申立てを扱う。

IANA のRFC 著者向け案内は、対象レジストリ、必要フィールド、根拠文書を明示するよう求める。プロトコル登録申請ページは、申請前に各レジストリの手順を確認させる。Datatracker のIANA review 状態説明は文書処理の一段階を見せる。いずれも重要な操作面だが、定義文書にない実体規則を黙って作る場所ではない。

この分業を潰すと、IANA の入力フォームが政策源となり、専門家の好みが規範となり、公開討議への出席が委任へ変換される。誰が政策を書き、誰が受付を行い、誰が技術勧告をしたかは別々に記録すべきである。

作業部会は永久機関ではない

Expert Review が必要になった理由は現実的だ。メーリングリストは広い知識を集められるが、議論が一つの答えに収束するとは限らない。IANA は全てのリストを監視できず、いつ粗い合意が成立したかを裁定する主体でもない。そして作業部会は閉じるが、レジストリは残る。

RFC 2418は作業部会のライフサイクルを示す。RFC 7282の rough consensus は、票数ではなく技術的反対を扱うための規律である。RFC 3935は、インターネットの運用に役立つ技術作業を IETF の使命に置く。閉じた部会、声の大きい参加者、単純多数を恒久裁判所にする根拠はない。

指定専門家は終了条件を提供する。申請を受け、必要に応じて専門家、公開リスト、活動中または解散済みの部会コミュニティに相談し、IANA に明確な勧告を返す。全てを一人で知る審判ではなく、審査の世話役でもよい。

その権限は限定的である。レジストリの規則に照らして割り当てるかを答えるのであって、申請者の製品全体を認証したり、導入を命じたり、名前空間を所有したりはしない。

ラベルは判定式ではない

「専門家が見る」という文だけでは、専門家も申請者も保護されない。何を見て、何が不合格になるかが必要である。

RFC 5226 は、専門家が判断を IETF コミュニティに説明できること、過程が秘密でも無制約の権力でもないことを求めた。基準はプロトコルと共に文書化されるのが望ましい。具体的基準がなければ、説得力ある理由がない限りコードポイントを与える、という推定が働く。

現行後継の RFC 8126 はこれをさらに明示する。テキスト版は、申請者が出す情報、専門家が評価する事項、拒否理由を示すよう求める。Datatracker、状態ページ、文書履歴、正誤表は、その発行・保守状態を確認する資料である。

拒否理由は無限ではない。コード空間の希少性、相互運用性を判断できないほど不明瞭な文書、基礎プロトコルの設計やセキュリティモデルとの重大な矛盾、展開済みシステムへの害、相互運用性を損なう活動中の IETF 作業との衝突などである。個人的な美意識は同列ではない。

基準の欠如は、保守的に何でも拒める余白ではない。強いゲートが必要なら、二実装、公開分析、利用見込みなどの条件を申請到着前に書くべきだ。後付けの善意は、予見可能な規則の代わりにならない。

判断には時刻と版がある

キューを進めるだけなら yes/no で足りる。長期的な制度には、申請版、証拠、適用基準の版、相談、利益相反、理由の記録が要る。

版 N の承認は、内容が大きく変わった版 N+1 の承認ではない。RFC 8126 は、専門家審査がある時点の特定文書に対して行われ、実質的変更なら再審査が必要になり得ると指摘する。コードレビューで一つのコミットに与えた承認を、未確認の次のコミットへ移せないのと同じである。

理由は専門家を守る。理由がなければ承認はえこひいき、拒否は妨害と呼ばれやすい。理由があれば、希少性の評価、文書不足、互換性被害、セキュリティモデルとの衝突、または単なる好みのどこに争点があるかを特定できる。

実務上の監査票は、申請版、提出証拠、基準版、利益相反を含む理由付き勧告、登録動作と後続履歴の五点を結び付けるとよい。これは Daniel Kade/BTW の分析案であり、RFC が定義する形式ではない。目的は、担当者が替わった後も判断を読めるようにすることだ。

忌避、交代、異議申立て

狭い専門分野ほど、詳しい人が提案の著者、競合設計の推進者、関係企業の助言者でもある可能性が高い。利益相反を語らないことは中立ではなく、観察不能にするだけである。

RFC 8126 は、申請仕様を執筆または強く推進した専門家の忌避を求める。全員に衝突があれば一時専門家を要請し、担当 Area Director が指名または審査を扱える。専門家が応答不能になれば交代でき、IESG が任命した専門家は IESG が解任できる。

複数専門家がいても決定規則は必要だ。意見が割れたまま IANA に渡してはならず、一つの明確な勧告にする。IANA は技術紛争の仲裁者ではない。行き詰まりは任命主体が解く。

登録判断は RFC 2026 の通常手続により、まず IESG、必要なら IAB へ異議を申し立てられる。異議申立ては専門家への侮辱ではなく、勧告がより大きな委任構造の中にある証拠である。

割当て後の支配面

登録行は申請処理より長生きする。参照先の修正、連絡先の更新、非推奨化、仕様改訂が起きる。RFC 8126 は First Come First Served、Expert Review、Specification Required などで変更管理者を記録することを勧める。

最初の割当てを得た者が、将来その意味を非互換に変える権利まで得るとは限らない。最初の専門家も全編集の所有者ではない。廃止後も履歴を注記として残す方が、削除して未使用に見せるより調整に役立つ。

RFC 7120の早期・一時割当ては、作業中の実装を助けながら標準化完了を偽らない仕組みである。一時、恒久、非推奨、廃止は単なる表示ではなく、異なる権利と期待を伴う状態だ。

同じような名前でも証明範囲は違う

RFC 5226 は RFC 2434の語彙を継承し改訂した。登録方針は品質バッジの序列ではない。

First Come First Served は、整形式で重複しない申請を扱い、実質的技術審査をしない。Expert Review は公開基準の下で指定審査者を加える。Specification Required は、独立した相互運用実装に足りる安定的・恒久的・公開仕様を加える。RFC Required は RFC を要するが、限定がなければ複数の文書ストリームや状態を含む。IETF Review は IESG 経路を通る IETF ストリーム RFC を求める。

Expert Review のコードポイントは製品認証ではない。RFC Required は必ずしも IETF Standard を意味しない。IETF Review も実装や展開の証拠ではない。各制度は自らが実行した手続だけを証明する。

Lu Heng の議論は、この境界を制度の中心に戻す。The Multi-Stakeholder Mirageは参加と委任を分ける。Minimum Initial Specificationは共通層を薄くし、後の情報に基づく選択を局所に残す。When the Bookkeeper Auditions for Olympusは記録役が高位の権力を演じる危険を指摘する。Running-Code Primacyは仕様と登録記号を、実装と観測結果から区別する。

指定専門家の価値は、境界を越えることではなく、境界の内側で衝突と害を減らし、明確な回答を返すことにある。

出典

  1. RFC 5226
  2. RFC 5226 プレーンテキスト
  3. Datatracker の RFC 5226
  4. RFC 5226 状態
  5. RFC 5226 履歴
  6. RFC 5226 正誤情報
  7. RFC 8126
  8. RFC 8126 プレーンテキスト
  9. Datatracker の RFC 8126
  10. RFC 8126 状態
  11. RFC 8126 履歴
  12. RFC 8126 正誤情報
  13. IANA の RFC 著者向け案内
  14. IANA プロトコル登録フォーム
  15. Datatracker の IANA Review 状態
  16. RFC 7120
  17. RFC 2026
  18. RFC 2418
  19. RFC 2434
  20. RFC 3935
  21. RFC 7282
  22. Lu Heng — The Multi-Stakeholder Mirage
  23. Lu Heng — Minimum Initial Specification
  24. Lu Heng — When the Bookkeeper Auditions for Olympus
  25. Lu Heng — Running-Code Primacy