要約

  • RFC 1264はルーティング標準の成熟を一つの評価語にせず、再現可能な仕様、管理性、セキュリティ設計、独立実装、全機能試験、運用経験、スケール限界に分けて証拠を求めた。
  • RFC 4794は2006年、公開の迅速性を損なうとして全ルーティング文書への一律規則を撤回した。しかしRFC 2026に基づくIESGの要求権と、各作業部会が独自手続きを続ける選択は残した。
  • その後も文書状態と実行は分離された。RFC 6410はInternet Standardに独立相互運用、広範な配備、成功した運用経験を結び、RFC 7942は実装状況を任意かつ未検証の場合がある判断材料とした。

一つの判定ではなく、複数の引き出し

RFC 1264が対象にしたルーティングプロトコルは、分散して動く実時間アルゴリズムだった。一つの実装が一つの構成で成功しても、別のコードが同じ仕様を同じように読めるとは限らない。小規模で安定しても、未知の上限を越えれば崩れる可能性がある。

そこで文書は、証拠を一枚の合格証にまとめなかった。プロトコルと利用法の仕様、遠隔管理のためのMIB、経路メッセージ認証を含むセキュリティアーキテクチャ、実装の出自、試験シナリオと結果、運用環境、性能と適用範囲の分析を別にした。

明瞭な仕様は第三者が実装できる可能性を示す。MIBは観測・制御する状態を定義する。セキュリティ設計は保護の意図を記す。どれも、二つの実装が経路を交換した事実や、認証が動いた事実そのものではない。

独立性はコードの来歴から始まる

RFC 1264は通常、複数の相互運用実装と、少なくとも二つの独立実装を求めた。同じコードベースから派生した二製品は、同じ誤読と欠陥を共有できる。独立した開発者が原作者に問い合わせず同じ動作へ到達できれば、仕様そのものが調整能力を持ったという強い試験になる。

だから実装一覧にはコードの出自が必要で、試験報告には場面と結果が必要だった。Draft Standardでは全機能を少なくとも二実装間で試し、セキュリティ機能も実際に働き、意図した保護を与えることを示す必要があった。

実装数だけでは機能網羅を証明できない。相互運用一回も、特定の版と入力と環境の関係を示すだけで、全攻撃への耐性や大規模な利用者結果までは示さない。

運用経験には地図と時計が要った

RFC 1264の運用報告は、トポロジー、環境、時期、期間、関与した実装、結果、結論を記録するものだった。重要な機能を実際に使い、外部ゲートウェイプロトコルなら外部経路全体を扱う。内部プロトコルも、別機構がない限り内部・外部双方の経路を運ぶ必要があった。

成熟段階で負担は変わった。Proposed Standardは実装と主要機能の試験を要したが、運用経験は不要だった。Draft Standardは運用中のインターネットで中程度のルータ数と複雑さを持つ経験を要求した。Standardでは大規模・複雑・複数ベンダーの経験へ進んだ。

これは候補が満たすべき条件であり、RFC 1264自身が特定プロトコルの達成を認定した記録ではない。標準化決定と、その根拠報告は別の対象だった。

二番目の報告は破綻点を尋ねた

この制度の核心は、実装報告とは別の分析報告にある。主要アルゴリズムを説明し、平常時の帯域、メモリ、CPU消費を評価し、当時より少なくとも一桁大きい環境での増え方を示し、限界と不適切な環境を名指しすることが求められた。

これにより「スケーラブル」は宣伝語ではなく、前提、資源、成長曲線、境界条件の組になった。既存ルーティング方式との比較も、改善主張を検査可能にした。

ただし分析は観測ではない。モデルの破綻点、試験で近づいた境界、実ネットワークで遭遇する障害は異なりうる。予測、実験、運用を分けて初めて、計算が配備実績に化けるのを防げる。

2006年、既定値が反転した

RFC 4794はRFC 1264をHistoricへ移した。理由は、ルーティング文書だけに常時追加される手続きが公開の適時性を損ない、一般の標準化過程と現実の制約で不合理なプロトコルを抑えられるという判断だった。

撤回は限定的だった。すべてのルーティング文書に同じ追加要件を課すことを止めた一方で、Routing Area DirectorがRFC 2026に基づき実装・運用経験を要求する余地を残した。作業部会も、望むならRFC 1264由来の手続きを続けられた。

証拠の決定権は、一律チェックリストからIESGと作業部会の個別判断へ移った。柔軟性と速度は上がるが、誰がどのリスクに何を求め、なぜ十分と判断したかを残す責任は重くなる。

成熟度を二段にしても実行証拠は残った

RFC 2026はProposed Standardを、経験により変更や撤回もありうる初期段階とした。通常は実装・運用経験を必須としないが、コアプロトコルや重大な運用影響がある場合、IESGは先に経験を求められる。

RFC 6410は後に三段階をProposed StandardとInternet Standardの二段へ縮めた。上位段階では、少なくとも二つの独立相互運用実装、広範な配備、成功した運用経験が明示的に残った。重大なエラー、使われない複雑機能、ライセンスも別に確認する。

それでも広範な配備は、特定ネットワークの現在状態ではない。版、対象、期間、観測を伴わなければ、個別事業者の有効化や成果を証明できない。

軽量な実装状況欄は限界も記した

RFC 7942はInternet-DraftにImplementation Status欄を置く任意の仕組みを定めた。実装の成熟度、ライセンス、経験、連絡先、相互運用報告を早く共有し、仕様が理解可能か、実装する関心があるかを判断しやすくする。

同時に定型文は、掲載がIETFの推奨ではなく、寄稿者の情報を独立検証していない場合があり、利用可能実装や機能の総覧でもないと明記する。これは欠陥ではなく、来歴の境界である。判断材料と試験結果、運用テレメトリ、配備記録は交換できない。

情報源と証拠の限界

1991年の専用基準はRFC 1264、一般手続きはRFC 2026、一律要件の退役はRFC 4794に基づく。二段階モデルはRFC 6410、任意の実装状況欄はRFC 7942による。

これらは制度、条件、変更理由を示す。特定プロトコルが全条件を満たしたこと、掲載実装が検証済みであること、特定運用者が配備したこと、利用者成果が生じたことは示さない。Historic化は旧い証拠を消去せず、過去の主張を自動的に偽にもしない。