主要領域
基盤
主要領域 の観点では、「基盤」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。
IETF
すべてのセルが停止を告げる：RFC 9906がECC-GOSTのDNSSEC廃止を完結
影響を受ける ECC-GOST の登録簿セルはすべて **MUST NOT** になった。SHA-1 の互換性移行である RFC 9905が検証側の余地を残したのに対し、RFC 9906は生成と検証の両方の経路を閉じ、登録簿での受け入れまで停止点にする。
AFNOG
AfNOGの200語要旨上限は必要な情報を示していない
2007年の AfNOG 募集は要旨を200語以内としたが、必須内容を示さなかった。
欧州・中東の地域 ISP トレンド
Ray-Svyazの500 Mbit/sキャンペーンで確認すべき更新後の料金
MyCentra がシェレゲシュ向けに掲げるのは、最大500 Mbit/s と50％割引だ。同じ公式ページには、割引は開通から3カ月で終了し、その後は契約時に合意した通常プランへ移るとも記されている。利用者が最初に確かめるべき経済条件は、初月の安さよりもキャンペーン終了後の料金である。
インターネット史
IPv4の識別子がすべてのデータグラムを識別しなくなったとき
*ヘッダーにフィールドが残っていても、その意味まで全パケットで保証されるとは限らない。*
IETF
署名は止め、検証は続ける：RFC 9905がSHA-1廃止を非対称にする
RFC 9905の仕組みは、対象となる DNSSEC アルゴリズム行で SHA-1 の新規生成を禁止する一方、検証実装の義務を残すというものだ。運用者は RSASHA1 と RSASHA1-NSEC3-SHA1 による DNSKEY、RRSIG、DS の作成を止めなければならない。しかし、残存する導入基盤を移行する間、再帰検証ソフトウェアはそれらを検証できなければならない。
IETF
MPLSリニアプロテクションは切替を調整するが、どの要求を優先するかは優先順位規則が決める
運用上の決定：プロテクションドメインのエンドポイントはローカル要求とリモート要求を受け取り、明示的な優先順位で並べ、事前に用意されたワーキングパスとプロテクションパスの間でセレクタを動かす。PSC が調整するのは既存のプロテクションドメイン内の切替である。パスを作成せず、容量を割り当てず、単独でメッセージを認証せず、どちらのエンドポイントにも制約のない経路選択権を与えない。
インターネット史
添付物が種類を名乗り、ローカル機がコマンドを選んだ：RFC 1524
1993年のメール端末で、同じ本文が標準入力になるか、一時ファイルになるかは添付物自身には決められなかった。RFC 1524 は、その分岐をローカルな `mailcap` 規則に置いた。相互運用できる名前と、実行を許す権限を分離するためである。
IETF
QUICの受信上限はパスMTUではない
相手が受信可能として通知した値を、ネットワーク経路の能力と取り違えてはならない。
IETF
四つのセル、一つの信頼連鎖：RFC 9904がDNSSECアルゴリズム方針をレジストリへ移す
RFC 9904は DNSSEC のアルゴリズム番号そのものを変更しない。変わるのは、その番号に結び付く推奨をどこで管理し、どの手続きで更新するかである。一つの DNSSEC アルゴリズム番号には、バリデーター実装、署名者実装、検証での利用、署名での利用という、別々に管理される四つの推奨セルがある。この四分割を単一の「アルゴリズム状態」に戻さないことが、RFC 9904を読む出発点になる。
インターネット史
メッセージは無傷で届いた。それでも読む順序には三人の責任者がいた――RFC 1556
配送完了の印は、文章が正しく読めることまで保証しない。ヘブライ文字と英単語、数字、句読点を含む一行は、同じ文字列のまま二つの画面に届き、異なる並びに見えることがある。RFC 1556 が扱ったのは、輸送後に残るこの責任だった。
インターネット史
TCPが終了マーカーとノーオペレーションの両方を必要とした理由
TCP の可変長オプション領域では、ヘッダーの物理的な終端と、意味のあるオプション列の終端を別々に扱う必要がありました。NOP は、送信側の配置上の都合を支えます。
インターネット史
リピーターはリセット前に応答した――RFC 1516
応答が届いた瞬間は、処理が終わった瞬間ではない。むしろ Ethernet リピーターが破壊的な自己試験へ入る直前だった。RFC 1516 は、管理要求への返事、装置の動作、完了通知、サービス回復を別々の時刻に置いた。
インターネット史
次のプロトコルを選ぶ前に、インターネットは誰がそれと暮らすのかを問うた：RFC 1550
RFC 1550 の冒頭に置かれたのは、パケット形式ではなく電力メーターと無線回線だった。IPv4 の後継候補を比べる前に、将来その影響を引き受ける側の条件を記録しようとしたのである。
インターネット史
警報は待ったが、カウンタは進んだ：RFC 1515
管理画面の警報が一度しか鳴らなくても、物理接続の状態は二度変わっていたかもしれない。RFC 1515は、この差を取りこぼしとして隠さなかった。通知には五秒の間隔を課し、現在状態と遷移回数には別の仕事を与えた。
インターネット史
機能を切っても標準は動かなければならない――RFC 1547
回線が従量課金なら、「相手はまだ生きているか」を確かめるだけのパケットにも値札が付く。RFC 1547 は、この小さな費用の食い違いから大きな条件を導いた。一方が機能を必要とし、他方が止めても、二者が共有するプロトコルまで止まってはならない。
インターネット史
ディスク容量を、そのまま「使える量」と呼ばなかったRFC 1514
容量という語は一つでも、装置が持つ量、ファイルシステムが管理する量、アプリケーションが実際に確保できる量は同じではない。1993年の RFC 1514は、その差を誤差として消すのではなく、Host Resources MIB の別々の表と関係として残した。遠隔監視で重要なのは桁数より先に、その数字がどの現実を測ったかだった。
インターネット史
同じアドレスでも、次のサーバーは同じとは限らない――RFC 1546
TCP の SYN に返ってきた SYN-ACK は、単なる応答ではない。RFC 1546 の構想では、その瞬間に「サービスなら誰でもよい」という宛先から、「この一台と話す」という相手へ参照先が切り替わる。共有アドレスだけでは継続する相手を名指せなかったからだ。
インターネット史
カウンタが一つ増えても、失われたフレーム数は分からない――RFC 1513
監視画面の数字は 41 から 42 になった。では、失われたフレームは何枚か。RFC 1513 の答えは、数字の見た目より慎重だった。このカウンタが数えたのは、プローブが資源不足を検知した回数であり、見落としたフレームの総数ではない。
AFNOG
AfNOGの任意の実習形式は必要資源を明記していない
2007年の AfNOG 募集は実習を可能としたが、必要資源を公表しなかった。
IETF
MPLSの損失・遅延測定は性能を可視化しても経路の制御権は握らない
MPLS LM/DM の仕組みは、パケットまたはオクテットのカウンター差分から損失を求め、G-ACh 上の LM/DM の問い合わせ・応答で運ばれるタイムスタンプから片方向および双方向の遅延を求めることにある。対象は既存の LSP、疑似ワイヤ、またはセクションであり、測定が経路を作るわけではない。