主要領域
基盤
主要領域 の観点では、「基盤」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。
ケースファイル
登録上は空いた。だが古い装置はその日付を知らない：RFC 9900
RFC 9900 は三つの NETCONF 関連ポートを正しく解放し、歴史的な service name は残した。IANA の状態変更と、各運用環境の退役完了は別々に証明すべき事実である。
ケースファイル
レジストリは署名停止を告げた。それでもゾーンにはロールオーバーが残った：RFC 9904と9905
RFC 9904は IANA の DNSSEC アルゴリズム表を更新可能な勧告記録に変え、RFC 9905は SHA-1 による新規署名を止めつつ検証対応を残した。しかし、表の規範語が変わっても稼働中のゾーンが自動で切り替わるわけではない。
ケースファイル
二本目のサブフローは参加した。それでも耐障害性は未証明だ：RFC 9897
RFC 9897 は追加の DCCP サブフローを認証し、一つのマルチパス接続へ参加させられる。これは厳密な制御面の成果だが、有用な通信やサービス復旧の証拠ではない。
ケースファイル
図は決定版RFCに入った。それでも意味を担うのは本文だった：RFC 9896
RFC 9896 は、RFC Production Center が特定の SVG 実装を永久に固定せず、道具を更新できるようにした。代わりに残した不変条件は明確だ。概念は本文にも存在し、どの表示も本文と整合しなければならない。
ケースファイル
セッションは再開した。それでも認可は「現在」を証明する：RFC 9930
再開チケットが保存するのは、以前に成立した状態である。処理を省くことはできても、その時の資格情報と方針が今も有効かという判断まで保存期間いっぱい自動延長することはできない。
ケースファイル
到達不能は通知された。それでも動作を決めるのは受信側だ：RFC 9929
集約経路が残っているからといって、その内側の全プレフィックスが生きているとは限らない。RFC 9929 は隠れた喪失を知らせるが、その通知に受信側を指揮する権限までは与えていない。
LKNOG
LKNOGの2019年CFPは一つの議題枠に二つの選考列を設けていた
LKNOG3 は、締切日にかかわらず先着順で発表を選ぶと告知する一方、極めて時宜を得た内容、重要な内容、または運用上きわめて重要な内容のために、委員会が限られた数の枠を締切まで確保できるとしていた。通常枠は提出時刻、例外枠は委員会の判断によって配分される、二重の仕組みだった。
ケースファイル
往復が完了しても、顧客の処理は証明されない
RFC 9516 の Echo は、設計された検査要求がサービス機能連鎖をどう通ったかを示せる。だが、その往復を顧客トラフィックの処理完了やサービス回復の受領書に変えてはならない。
インターネット史
ファイルはファクス通話ではなかった：RFC 1314
スキャンした一枚の紙がファイルになっても、それだけで送信・印刷・閲覧の出来事にはならない。1992年の RFC 1314 は、ファクスに似た白黒画像を交換するために TIFF-B を定めた。複数ページを扱い、一ページを一つの TIFF strip で表す。しかし、この仕様の重要な慎重さは、ファイル形式を運搬、保存、表示、印刷、そして人の反応の証明にしなかった点にある。ファイルは交換のための対象であり、後続の全行為の証人ではない。
ケースファイル
ACK は次の送信を許した。経路はまだ回復していなかった：RFC 9937
ACK が戻り、送信側がもう一度送れるようになった。その事実と、共有経路やサービスが回復したという判断は別の記録である。
ケースファイル
内容種別は YAML だった。決定はなおローカルに残った。
`application/yaml` は到着した表現の形式を知らせる。受信者がそれを受け入れ、解釈し、現実の状態を変えてよいことまでは知らせない。
ケースファイル
コントローラには枠組みがあった。決定的サービスはまだ成立していなかった：RFC 9938
RFC 9938 は DetNet コントローラプレーンに必要になり得る仕事を整理する文書である。フロー要求、経路計算、設定投入を、実際に成立し維持され観測されたサービスの証明へ変えるものではない。
ケースファイル
委任された LSP は、委任されたネットワークではない
RFC 9504 は GMPLS 制御ネットワークで状態保持型 PCE を使いやすくする。だが、PCEP 上の記録を運用権限の移転に、あるいは経路要求をサービス実績に変えるものではない。
ケースファイル
受信者の鍵は示された。それでもメッセージは開かれていない：RFC 9936
RFC 9936 は CMS に ML-KEM の受信者経路を載せる。検査できる記録は証明書または公開鍵と、その鍵向けの暗号文を示せる。しかし秘密鍵の管理、復号の成功、内容の処理、組織上の決定までは示さない。
インターネット史
エージェントはモジュールを支援した。変更権限を与えたのではない：RFC 1303
SNMP の管理画面では、対応しているという表示が判断を急がせる。読める、書ける、対象の MIB を実装している――その三つが並ぶと、次の `Set` が正当であり、返答が来れば変更も完了したように見える。RFC 1303 はその飛躍を支持しない。1992 年の文書が与えたのは、エージェントの能力を記述して対話を適合させる約束であり、権限や実行結果の代替ではなかった。
インターネット史
チケットは障害そのものではない：RFC 1297 が定めた NOC の記憶の境界
障害は、当直が交替しても、番号を付けても、ひとつの確定した出来事にはならない。監視の信号、利用者の申告、ベンダーへの照会、未検証の仮説は、それぞれ別の時点で残る。1992 年の RFC 1297 は、このばらばらな作業をつなぐためにチケットを構想した。ただしそれは、障害を支配する台帳ではなく、NOC の共有記憶だった。
ケースファイル
スケジュールは有効だった。変更は実行されていなかった：RFC 9922
定例保守の行に `enabled`、次回時刻、前回の発生時刻、増えたカウンタが並んでいる。その表示は時間規則については有益である。しかし、誰かが変更を許可し、呼び出し、対象で完了させ、結果を確認したという証明にはならない。
インターネット史
DNS の走査が数えたのはレコードであって到達可能性ではない：RFC 1296 の下限
Internet の大きさを示す数字は、数字を集めた手続より強く見えがちである。RFC 1296 は 1992 年 1 月に 727,000 の IP host を表にした。しかし同じ文書は、その数字を到達可能な機械の総数とも、Internet の完全な人口とも扱わなかった。ZONE が得た DNS レコード、得られなかったゾーン、重複の恐れ、そして採用した host の定義を併記し、結果を実数ではなく最小数として置いた。
インターネット史
公開ディレクトリには掲載を拒む権利が必要だった：RFC 1295 の境界
ネットワーク上で読めるという技術的状態は、公開してよいという判断とは別である。RFC 1295 が印象的なのは、この違いを抽象的な理念としてではなく、ディレクトリ運用の順序として置いた点にある。検索の便利さより先に、Public Directory に載らない権利を挙げたのである。
インターネット史
フレームのラベルは仮想回線の設定ではなかった：RFC 1294 の多重プロトコル境界
Frame Relay の受信側が、一つのフレームの後ろにどのプロトコルがあるかを識別できても、その仮想回線で当該のカプセル化を使う権限まで得たわけではない。RFC 1294 はこの二つを明確に分離した。NLPID と SNAP は PDU の読み方を示す。どの VC がどのカプセル化方式を運べるかは、端点があらかじめ知り、明示的に設定しておくべき別の条件である。