主要領域
基盤
主要領域 の観点では、「基盤」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。
アジア太平洋の国内通信事業者トレンド
4つの海底ケーブル障害でベトナムに影響、Viettel が容量増強
4つの海底ケーブル障害でベトナムの国際インターネット容量の約30％に支障が生じ、Viettel は海底・陸上経路の容量を増強している。
IETF
Christian Amsüss と上流 DNS を保護しなかった DoC のセキュリティ文脈
DNS over CoAP の保護された交換は有用な事実だが、名前解決全体の秘匿性を意味しない。Christian Amsüss を含む共同著者による RFC 9953 は、DTLS、TLS、OSCORE の文脈を共有する当事者間に完全性と機密性を限定する。同時に DoC サーバーは上流 DNS と非保護の UDP で通信し得る。
北米の地域 ISP トレンド
Wire 3、アンダーソンで3,600万ドルの光ファイバー網建設を開始
Wire 3はサウスカロライナ州で初となる光ファイバー網の建設をアンダーソンで開始し、早ければ2026年秋にも最初の顧客接続を行う見通しだ。
欧州・中東の国内通信事業者トレンド
英国の PSTN 終了、移行待ちは150万回線
2027年1月の終了を前に、Openreach の PSTN は約150万回線が残る。調査では、顧客側の移行準備に遅れがあることも示された。
IETF
Paul Wouters と、交渉の受領証ではない IKEv2 実装要件
RFC 8247 の `MUST implement` は、実装間に共通の選択肢を残すための基準である。Paul Wouters を含む共同著者が示したこの基準は、特定の二者が何を提案し、選択し、認証し、ESP で使ったかを記録するものではない。
北米のデータセンタートレンド
ERCOT、テキサス州データセンターの系統分類を延期
ERCOT は Batch Zero の分類期限を再び守れず、検証作業の長期化により、テキサス州のデータセンターを巡る系統接続判断は2027年以降へさらにずれ込む。
IETF
Bernie Volz と、クライアントをまだ設定していない DHCPv6 Reconfigure
Reconfigure を送った、というサーバーログは完了の印に見えやすい。しかし Bernie Volz が共同執筆者に名を連ねる RFC 9915 は、送信、妥当な受信、後続要求、Reply、ローカルでの適用を別々に扱う。Reconfigure は後続の交換を始める合図であって、設定済みという受領証ではない。
IETF
Wassim Haddad と、まだ転送を許可しなかったプレフィックス
モバイルルーターは、使えるモバイルネットワークプレフィックスを知る前に、ホームエージェントへ登録できる。Wassim Haddad が共同執筆した RFC 6276 は、その後の境界を明示する。有効な DHCPv6 Prefix Delegation のリースがあって初めて、そのプレフィックスを Binding Cache Entry に加え、未委任プレフィックスへの転送を避けられる。
北米の国内通信トレンド
Optimum、T-Mobile との契約を拡大しスタンドアロン 5G へ
Optimum は自社のモバイルコアを T-Mobile のスタンドアロン 5G ネットワークに接続し、2027年初頭の全面提供開始を見込んでいる。
IETF
Thomas Graf と、制御プレーンの出所を示さなかった MPLS ラベル番号
運用画面に現れたラベル番号は、もっともらしい物語を急いで作らせる。番号を見つけ、集計し、想定していた移行と結び付ければ、原因まで分かったように見える。Thomas Graf が単著した RFC 9160 は、その一歩前で止まる。MPLS ラベルの数値だけでは、それを割り当てた制御プレーン・プロトコルを確実には特定できない。
IETF
SCITTは声明を台帳化できるが、リリースを承認できない
SCITT のレシートは、署名済みのサプライチェーン声明が特定の透明性サービスに登録されたことを検証可能にする。しかし、それだけで組織がその成果物を本番へ出すべきか、採用し続けるべきかを決めることはできない。損害を止め、説明し、是正できる側に、決定は残る。
IETF
Tommy Pauly と、アプリケーション処理を証明しなかった QUIC ACK
ACK が返ったことと、受信側のアプリケーションが仕事を終えたことは同じではない。Tommy Pauly が共同執筆した RFC 9221 は、QUIC DATAGRAM についてこの間隔を明示する。受信側のトランスポート層がフレームを処理したという事実は、データがアプリケーションで正常に処理されたことの保証ではない。
IETF
新しいパケットが先に届いたとき：TCP RACKが時間で損失を見つける仕組み
RACK は、確認済みの新しい送信を時間上の基準にして、未確認の古い送信を評価する。そこには並べ替えを許容するための明示的な幅が設けられている。
IETF
Gorry Fairhurstと、故障名を告げずに作動したサーキットブレーカー
保護が作動したという記録は、障害報告書ではない。Gorry Fairhurst が著した RFC 8084は、持続する過大な状態に対し、定義済みの輸送トラフィックを止めるか大幅に減らす仕組みを示す。その仕組みが証明できるのは計測範囲と反応であり、原因や場所や復旧ではない。
欧州・中東の国内通信事業者トレンド
緊急警報のカバレッジ地図だけでは地域の警報計画にならない――端末が受信できることを確かめるまで
モバイルのカバレッジ地図と英国の Emergency Alerts が存在していても、避難所、車庫、現場対応者の端末が必要な時に警報を受け取るとは証明しない。
ケースファイル
RFC 9878でACKに載せられても、請求の正しさは証明されない
RFC 9878は、3GPP で使われる SIP の私有ヘッダーをどのメッセージに収容できるかを修正した。2xx 応答後の ACK に位置情報や課金情報を載せる道は開いたが、その値の由来や請求結果まで正しいと保証したわけではない。
ケースファイル
RDAP が geofeed を示しても、所在地が証明されたわけではない：RFC 9877
RFC 9877 は、IP ネットワークオブジェクトから geofeed を見つける手順を整えた。ただし、見つかった URL は証拠の入口であって、所在地や利用目的まで確定する判定ではない。
ケースファイル
登録された番号と、動作を許可された機器は別である：RFC 9876
CoAP の短い整数は、長い内容記述を毎回送らずに済ませる。RFC 9876 はその対応表を正確にする。しかし登録が成功しても、受信機の実装・信頼・業務判断まで成功したことにはならない。
ケースファイル
応答が証明したのは一つのプローブであり、次のデータグラムではない：RFC 9869
経路 MTU は相手先に貼られた固定値ではない。RFC 9869 が返すのは、もっと狭く確かな事実だ。特定サイズの UDP Options プローブが、その時点の経路を通って受信側に届いたことを、対応するトークンで確認する。
欧州・中東の国内通信事業者トレンド
対応機関の連絡先一覧は、相互運用と通信事業者への連絡を訓練するまで強靱な通信計画ではない
調整室には最新の一覧表がある。管制室、当直責任者、無線担当者、通信事業者が並ぶ。しかし固定回線が止まり、携帯網が混雑した時、その表だけでは、どの機関がなお運用情報を交換できるか、代替経路を誰が管理するか、事業者へのエスカレーションをどう始めるかは分からない。