要約

  • RFC 1958 は Informational であり、標準でも、教義でも、不変の参照モデルでもないと自ら範囲を限定した。
  • 必要な通信状態は端点に置き、不可避な網内状態は小さく自己修復可能にし、原則より実装からのフィードバックを重く見るという検証可能な境界を示した。
  • 文書は相互運用の経験を記録できるが、RFC 番号だけで変更を命令できない。変更は独立実装と運用上の採用を通じて現実になる。

1996 年6月の RFC 1958 は、題名だけ見ればインターネットの憲法を思わせる。しかし本文はその読み方を最初から拒む。ステータス欄は、いかなるインターネット標準も規定しないと明記する。要旨は現在の理解を写した一般的な手引きにすぎず、正式でも不変でもない参照モデルだと述べる。第1節は、プロトコル設計の教義を定める目的ではないと言い切った。

この慎ましさは飾りではない。インターネットは「壮大な計画」からではなく、動いている系を変え続けることで育った。かつて不可侵と思われた原則は廃れ、1996 年の原則も例外ではない。RFC 1958 が永続を許した唯一の候補は、絶えず変わるという原則そのものだった。

文書の都市の比喩が重要なのは、その更新方法を示すからだ。都市を更地にして完成品を建て直すのではない。通行を保ちながら道路と建物を一つずつ更新する。少数の共通規則は多様な技術空間を生むための骨組みであって、骨組みの管理者に都市全体の指揮権を与えるものではない。

その境界は、抽象論だけではない。目標は接続性、道具は IP、知性は網内に隠すより端から端へ置く。狭いインターネット層が異なる媒体、機器、事業者の共通点となる一方、上下の層には複数の方式を許す。IP の世代移行では複数方式が一時的に共存し得るとも認めた。共通部分は、広いから強いのではなく、薄いから多様性を結べる。

状態の所在は、その考えを故障時に測る尺度になる。アプリケーションの知識を必要とする機能は端点の助けなしに完全には実行できないため、端間通信の状態は端点と運命を共にすべきだと RFC 1958 は述べた。ただし網内状態を全面禁止したわけではない。経路、QoS の保証、ヘッダー圧縮のセッション情報などを明示的に挙げ、必要なら量を抑え、トポロジーや活動に応じて適応的に導出・修復し、手動設定を最小にするよう求めた。接続性が残るなら、状態消失の影響は一時的なサービス拒否にとどめる。

したがって端点原則は地理ではなく質問である。完全な判断に必要な知識は誰が持つのか。途中の装置が失った状態を誰が再構築できるのか。交換時に私有の記憶が必要になるのか。端点は必要な真実を再び確立できるのか。中間機能が存在するだけで誤りなのではない。回復と置換が一つの隠れた記憶に従属した時、そこが権力と故障の集中点になる。

一般設計原則も単純な序列ではない。RFC 1958 は単純さとモジュール性を勧めながら、性能と費用も同時に考えよと言い、完全解を待つよりほぼ十分な解を今採る方がよい場合もあるとした。美しい分離は運用費を正当化しなければならず、速い最適化は将来の分離可能性を証明しなければならない。

RFC 3439 は後にこの記録を更新し、複雑性を拡張性、設備投資、運用費の問題として扱った。コア状態と端点状態の相互作用、層と結合が費用をどう増幅するかを検討した点で、単純さを新しい絶対命令にしたのではなく、設計を評価する観測項目を増やした。

RFC 1958 は最後の判定権を自分から手放している。インターネットには所有者も中央制御もなく、進化はラフコンセンサスと稼働コードに依存すると述べた直後、実際の実装から得られる工学的フィードバックはどの建築原則より重要だとした。さらに、複数の稼働実装ができるまでは標準化しないという原則を置いた。

稼働コードは多数決でも無条件の正しさでもない。普及したコードが欠陥、囲い込み、歴史的偶然を固定することはある。ラフコンセンサスも全運用者の委任を意味しない。価値は、文書だけでは見えない曖昧さ、障害、費用、暗黙の依存を表に出す点にある。独立した複数実装なら、特権的な内部知識なしに同じ境界を再現できるかを試せる。

後の IETF 文書も権威を限定した。RFC 3935 は標準を、それに従うと主張するならこのように実装するという記述であって、採用の強制や取締りではないと説明した。RFC 7282 は王、議長、多数票ではなく技術的異論を扱い、真空の理論を実際の工学成果で検証する過程としてラフコンセンサスを描いた。RFC 9592 に保存された Tao も、IETF は自発的に採用される標準で進路に影響するが、インターネットを運営、支配、巡回しないと述べる。

Lu Heng の Running-Code Primacy は、この自己限定を現代の変更権として読む枠組みを与える。最小の共通仕様は相互運用と局所検証を可能にし、その後の選択は採用、拒否、あるいは互換集合への限定によって効力を持つ。公表は選択を説明できても、未実装の義務を現実にはしない。ただしこれは解釈であり、RFC 1958 が特定の台帳、分岐方式、統治制度を定めたという主張ではない。

RFC 1958 の歴史的価値は、原則を王座に置かなかったことにある。新しい設計はこの文書を引用したから勝つのではない。独立に実装でき、障害から回復でき、互換性の違いを隠さず、採用後も接続性を守れるから勝つ。メモは約束を記録する。変更する権利は、ネットワークを動かし続ける側に残る。

出典