主要領域
基盤
主要領域 の観点では、「基盤」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。
インターネット史
一つのパケットが共有リンク上の他の通信を待たせる：RFC 3150
非常に遅いリンクでは、パケットの大きさが、同じインターフェースを使う他の通信の待ち時間も決める。RFC 3150は、MTU を単なるバイト効率ではなく、設計上の時間制約として扱った。
インターネット史
Call Agentが機能を決めても、ミュートは電話に残った：RFC 3149
MGCP は呼制御の知能を電話の外へ置いた。しかし RFC 3149は、利用者の手元まで中央へ移さなかった。番号付き機能キーの意味や XML 画面は Call Agent が扱い、音量、受話器とスピーカーの即時切替、マイクのミュートは端末内に残した。意味の集中と物理操作の集中は同じではなかった。
インターネット史
同じ経路から妥当な容量値が二つ出ることがあった：RFC 3148
単一フローの大容量転送を測ると、結果は一つの数字に見える。RFC 3148は、その数字が転送方式によって変わり得る理由を示し、値とともに経路の記録を残す必要性を説いた。
インターネット史
新しい管理網は古い管理網を渡らなければならなかった：RFC 3147
移行計画では、新方式が旧方式を置き換える順序がきれいに描かれる。しかし現場では、新しい IP 管理の装置が、まだ止められない CLNS 網の向こう側に先に設置されることがある。RFC 3147 は IP を GRE に、GRE を CLNP に収めてその距離を埋めた。これは勝利宣言ではなく、依存関係を壊さず次の道を作るための設計だった。
インターネット史
トンネルは閉じた。それでも原因コードは判決を下せなかった：RFC 3145
利用者に近い装置が切断を知り、PPP の最終状態は遠いサーバーだけが知る。所有者まで異なれば、「なぜ」の受け渡しは障害対応そのものになる。RFC 3145 は理由を運ぶ小さな器を作ったが、その器に制御権も裁定権も入れなかった。
インターネット史
利用者が選んでも、通話処理はまだ実行されない――RFC 3136
RFC 3136は着信をインターネット側へ知らせながら、画面の選択と電話網の動作を同じものとは扱わなかった。SPIRITS の設計が分けたのは、利用者への通知、その希望を運ぶ経路、サービス制御による判断、交換機での実行、そして発信者が経験する結果だった。
インターネット史
network policyはGoldと言った。各deviceを書けるtranslatorは一人だけだった――RFC 3139
「この customer に Gold service を与える」という一文は、router が実行できる configuration ではなかった。RFC 3139は、topology、capability、network-wide model、device-local 変換、排他的 writer、同期、feedback、traffic という残りの経路を示した。
インターネット史
proxyはbyteをACKした。applicationにはまだ届いていなかった――RFC 3135
送信側には、すぐ ACK が返った。だがその応答を発したのは宛先ではなく、難しい link の手前に置かれた proxy だった。RFC 3135が記録したのは高速化の技法だけではない。近い場所からの応答を、遠い application の受領証に昇格させてはならないという境界である。
インターネット史
配送率は良好だった。アプリケーションは遅かった――RFC 3133
失われたのは小さな確認フレーム一つだった。届いたバイトの比率はほとんど下がらない。それでも送信側は大量のデータを送り直し、利用者は待たされる。RFC 3133 は、この食い違いを測定値の限界として明記していた。
インターネット史
最初のpacketは、届く前にhostを起こさなければならなかった：RFC 3132
mobile host は電池を守るため、通常 traffic の channel を聞くのをやめた。その瞬間から、最初の packet は配送物である前に、network へ捜索を命じる合図になった。
インターネット史
中継をやめても、ルーターは到達可能なままだった：RFC 3137
経路から退くことと、topology から消えることは同じではない。RFC 3137は、OSPF router を目的地として残しながら、中継路としては最も選ばれにくくする状態を定義した。
インターネット史
一日のワークショップでは期限切れの署名を試せなかった：RFC 3130
IETF 49の頃、DNSSEC の短期実験は成功しやすくなっていた。だが、それは完成の証拠ではなかった。署名、鍵、cache、組織間の引き継ぎが本当に難しい状態へ進む前に、実験日程が終わっていたからである。
インターネット史
各IPsecピアが抱えきれない信頼をKDCが担った：RFC 3129
2001年の RFC 3129は、鍵交換を暗号方式の比較だけで語らなかった。ピアごとに証明書、計算、ポリシー、共有秘密を背負わせる設計は、大規模な組織でも運用できるのか。Kerberos の KDC を使う提案は、その負担の置き場所を変える試みだった。
インターネット史
最初の断片は通過した。重なりがポートを書き換えた：RFC 3128
RFC 3128が示したのは、filter が何も見なかったという失敗ではない。filter は許可可能な TCP header を見て判断した。ところが、受信 host が重なった断片を組み直した後には、別の destination port を持つ header が出来上がる可能性があった。
インターネット史
長期の証拠は鍵より長く生きなければならなかった：RFC 3126
RFC 3126が扱ったのは、古い signature の保管問題だった。2001年に正しかった計算も、certificate、revocation record、正確な signed bytes、信頼できる algorithm が失われれば、後年には理由を説明できない。答えは永続的な trust ではなく、更新を続ける evidence chain だった。
インターネット史
有効なsignatureにもpolicyが必要だった：RFC 3125
RFC 3125は、電子署名を取り巻く規則を参照可能で、必要なら machine-processable な対象にしようとした。暗号計算が正しいだけでは最初の gate しか通らない。どの policy bytes、commitment、trust condition、外部制度が適用されたかが残った。
インターネット史
送信許可はpacket queueではなかった：RFC 3124
Congestion Manager は、一台の host で競合する application に送信機会を配る構想だった。ただし data を預からない。RFC 3124は、許可、host からの実送信、receiver feedback を別々の事実として残した。
インターネット史
Prefix listはまだaccess policyではなかった：RFC 3123
DNS は network prefix の列を正確に配ることができた。RFC 3123の重要な節度は、その列を命令に仕立てなかったことにある。record は表現を保存し、意味と決定と実行は別の主体に残した。
インターネット史
遅延の数値は時計についての主張でもあった――RFC 3116
ATM 装置の前後で timestamp を取り、差を計算する。それだけなら簡単に見える。RFC 3116が守ろうとしたのは、差の背後にある clock、counter、traffic 条件を消さないことだった。
インターネット史
同じシステムを共有しても、承認権は一つにならない――RFC 3113
第3世代 mobile system は Internet protocol を必要とした。IETF も radio network の現実を必要とした。RFC 3113が設計したのは統合組織ではなく、権限を奪わずに依存関係を運ぶ境界だった。