コンテンツ種別
Research
コンテンツ種別の観点では、Research は同じ編集形式を持つ BTW.MEDIA の記事を集約し、解説、プロフィール、リスクノート、市場分析、イベント記事を、種類の異なる証拠を混ぜずに比較できるようにします。このページは、この記事タイプがサイト上のインターネット基盤の出来事、企業の動き、ガバナンス上の決定、運用上のシグナル、公開された証拠をどのように位置づけるかを説明します。読者は、どの主体やインフラシステムが頻繁に登場するか、情報源の質が解釈をどう変えるか、対象が継続的なプロフィールなのか、時限性のあるイベントなのか、戦略的な市場シグナルなのか、ガバナンス上の進展なのかを比較できます。同じ形式の記事の背景、時期、証拠を理解したい運用者、投資家、顧客、アナリスト、政策関係者にとって役立つ検索ページです。
インターネット史
RFC 1180はTCP/IPを解説し、読者を規格文書へ送り返した
1991年1月、T.J. Socolofsky と C.J. Kale は、ネットワークの専門家が IP データグラムを送信ホストからルーター経由で宛先ホストまで追えるよう、具体的な道筋を示した。同時に、明確な境界も置いた。このメモは TCP/IP を説明するが、定義はしない。
インターネット史
物理リンクは上がっていた。遠端が知ったのは Echo の期限切れだった：RFC 3186
近端の光回線が切れても、遠端のランプは消えない。RFC 3186 の MAPOS/PPP トンネルでは、光パスが網の端で終端されるためだ。遠端が異常を知るのは PPP Echo が戻らなくなった後だった。この時間差に、透明なリンクと実際の経路の違いが表れている。
インターネット史
MSG1 の CEK から MSG2 の権限が生まれた：RFC 3185
MSG2 の鍵を理解するには、MSG2 の受信者欄だけを見ても足りない。一本前の MSG1 に戻り、誰がその CEK を受け取り、保存し、次の KEK を導出できたかをたどる必要がある。RFC 3185 は、暗号化されたオブジェクトの権限が過去の鍵から継承される仕組みを規定した。
IETF
鍵は替わった。同じインスタンスだと言えるのは台帳が残っているからだ
OAuth の新しい提案は、鍵を更新したクライアントを以前と同じインスタンスとして扱えるようにする。しかし連続性を生むのは ID の文字列ではない。登録、鍵の継承、ライフサイクルを記録して判断する attester である。
インターネット史
その S/MIME 層は、誰の代わりに語ったのか：RFC 3183
署名された層の内側に暗号化された層があり、その内側に別の署名がある。境界装置が一枚を検証し、一枚を外し、新しい署名を加えたとき、最後の受信者に向かって語っているのは誰なのか。RFC 3183 は、S/MIME の入れ子を単なる包装ではなく、権限と保管の履歴として読ませる文書だった。
インターネット史
ファイアウォールは拒否してよい。通信を壊してはいけない：RFC 2979
2000年10月、Informational RFC は、パケットフィルターがしばしば曖昧にしていた線を引いた。組織はセキュリティ上の理由で通信を拒否できる。しかしファイアウォールが、正当で標準に準拠した利用を意図せず失敗させてはならない。障害が中間装置に由来するなら、修正の責任もその側にある。
IETF
ICVは正しかった。それでも経路記録が真実とは限らない
IOAM の累積完全性チェーンは、宣言された保護対象に改変が検出されなかったことを示せる。だが、期待した記録がすべて届いたこと、各ノードの自己申告が正しいこと、輸出後のデータが保たれたこと、そして判断がサービスを改善したことまでは示さない。
インターネット史
名前はRSVPに入った。それでも権限は意味を決めなければならなかった：RFC 3182
ポリシー・ロケータ、資格情報、ポリシー判断、実行は、同じ「身元確認」の別名ではない。RFC 3182は、その四つを RSVP の経路上で受け渡す仕組みを示した。ロケータは規則の所在を指し、チケットや証明書は主体の検証材料を与え、PDP が判断し、PEP がローカルに実行する。マルチキャストでは、どのアプリケーションの身元情報が残るかまで選択の対象だった。名前が運ばれたことと、資源を使う権限が成立したことの間には、消してはならない履歴がある。
インターネット史
ピア間を保護しても、信頼できないMASCの主張は届く：RFC 2909
MASC は、マルチキャストのアドレス空間を期限付きの階層的な主張に分けた。2000年の RFC 2909は、隣接するピア間を保護しても、転送された更新すべてが信頼できるとは限らないと指摘していた。
IETF
コントローラーは双方向完了と報告した。それでも無瞬断は証明されない
細粒度 OTN は、稼働中の低速回線に割り当てる帯域を変えられる。しかし多ドメイン調整器に届く一つの完了通知は、各方向、各ドメイン、現用・予備経路、トリビュタリスロット、そして顧客トラフィックを一括して証明するものではない。
北米のデータセンタートレンド
発電量ではなく権利の設計――Georgia PowerとGoogleの原発増出力契約
Georgia Power は Vogtle と Hatch の増出力で系統に約96MW の容量を加え、Google には増分電力に付随するゼロ排出クレジットを割り当てる計画だ。顧客便益として示された約9億ドルを評価するには、設備の数字よりも、費用・属性・リスクの配分を追う必要がある。
インターネット史
新しいフローは受入れを勝ち取った。防御優先度は次の到着にも耐えねばならなかった：RFC 3181
資源が全員分ないとき、早く来たことだけでは席を守れない。RFC 3181 は、後から来たフローが既存の予約を退かせる仕組みを定義した。ただし、その勝利を永続的な権利にはしなかった。入るときの優先度と、入った後に次の到着から席を守る優先度は別だった。ポリシー生成、予約の統合、局所的な執行、パケット、アプリケーション結果も、それぞれ別の証拠面に残った。
記事
APNIC、8サービスに及ぶ障害を負荷分散装置の接続排出ミスと説明
APNIC によると、片方の負荷分散ノードの保守中に、本来の対象ではないもう一方のノードへ接続の排出処理が実行され、8サービスに障害が及んだ。告知上の継続時間は15分だが、記載された開始・終了時刻の差は17分ある。
インターネット史
1つのASに256個のマルチキャストアドレス、そして4オクテットの壁
GLOP は、既存のネットワーク番号から静的なマルチキャスト範囲を導けるようにした。簡潔な仕組みだったが、借りた AS 番号欄は2オクテットだった。
IETF
バッチ証明は通った。それで、トークンは何個在庫になったのか
Privacy Pass の一括発行は、暗号処理の重複を減らす一方で、「発行済み」という言葉を危うくする。共通証明が正しいこと、各応答が最終化できたこと、ローカル在庫へ永続的に入ったこと、後日利用できたことは、同じ事実ではない。
インターネット史
ランタイムは231と応答した。それでもスクリプトには終了の受領証が必要だった：RFC 3179
「実行中」は、完了の言い換えではない。RFC 3179 はその当たり前をメッセージの順序として残した。231 は制御要求がランタイム状態へ到達したことを示し、中間結果、エラー、終了は別の応答で届いた。さらに結果の解釈と管理対象の変化はプロトコルの外に残る。自動化の証拠は、一つの成功表示ではなく、責任の異なる受領証の列だった。
IETF
ACME注文はプロファイルを記録した。それでも証明書そのものの検査は残る
ACME Profiles は、CA の発行方針を CSR の曖昧な拡張から注文上の明示的な選択へ移す。これは重要な改善だが、プロファイル名は証明書の中身、配備、利用側の受容までを証明する印章ではない。
インターネット史
IPv6の/48は出発点だった——すべてのサイトに合う寸法ではない
IPv6 の/48が見直されたのは、アドレスが足りなくなったからではない。規模も用途も異なるエンドサイトに、ひとつの見やすい推奨値をそのまま当てはめられるのか。地域レジストリが政策に落とし込む段階で、その問いが前に出てきた。
IETF
署名済みの会話コンテナは、会話の真実まで証明するのか
vCon は当事者、対話、添付資料、分析結果を運べる共通の器を目指す。署名は特定の版を改ざんから守るが、記録の全体性、本人性、同意の有効性、分析の正しさ、署名者の権限までは一括して保証しない。
インターネット史
コアはフローを忘れた。それでもエッジは予約を証明しなければならなかった：RFC 3175
RFC 3175 は、すべての予約をコアの全ルーターに記憶させる設計から一歩退いた。多数の RSVP フローを一つの大きな予約へまとめても、個々の約束まで一つに溶けるわけではない。中央の状態を減らすほど、両端の証拠は鮮明でなければならなかった。