コンテンツ種別
Research
コンテンツ種別の観点では、Research は同じ編集形式を持つ BTW.MEDIA の記事を集約し、解説、プロフィール、リスクノート、市場分析、イベント記事を、種類の異なる証拠を混ぜずに比較できるようにします。このページは、この記事タイプがサイト上のインターネット基盤の出来事、企業の動き、ガバナンス上の決定、運用上のシグナル、公開された証拠をどのように位置づけるかを説明します。読者は、どの主体やインフラシステムが頻繁に登場するか、情報源の質が解釈をどう変えるか、対象が継続的なプロフィールなのか、時限性のあるイベントなのか、戦略的な市場シグナルなのか、ガバナンス上の進展なのかを比較できます。同じ形式の記事の背景、時期、証拠を理解したい運用者、投資家、顧客、アナリスト、政策関係者にとって役立つ検索ページです。
インターネット史
各IPsecピアが抱えきれない信頼をKDCが担った：RFC 3129
2001年の RFC 3129は、鍵交換を暗号方式の比較だけで語らなかった。ピアごとに証明書、計算、ポリシー、共有秘密を背負わせる設計は、大規模な組織でも運用できるのか。Kerberos の KDC を使う提案は、その負担の置き場所を変える試みだった。
IETF
バックアップが見失ったのは主系ではなく、観測経路だった
BIER の予備入口が主入口を監視する経路と、主入口が受信側へ流す経路は同一とは限らない。前者の断絶を後者の故障として扱えば、止まっていないサービスに二本目の流れを重ねることになる。
インターネット史
プラス記号はローカルな一方式にすぎない――RFC 5233
メールアドレスのローカル部には配送の手掛かりを含められるが、その表記が世界共通の言語になるわけではない。RFC 5233 は Sieve が「ユーザー」部分と「詳細」部分を照合できるようにしたものの、各メールシステムが同じ方法で分割するとも、プラス記号を使うとも定めなかった。
インターネット史
最初の断片は通過した。重なりがポートを書き換えた：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 だった。
IETF
ハンドシェイクは開けた。それでも送信者の認証には群の記憶が要る
MLS の外部受信者は、メンバーと同じ Commit や Proposal を復号できても、誰が送ったかを検証する状態を持たないことがある。足りないのは暗号文ではない。epoch、sender leaf、credential、外部受信者リストを結ぶ GroupContext である。
インターネット史
フィルターは配達時に印を付けられても、メールボックスを書き換えられない――RFC 5232
メールルールは、配達するコピーに印を付けられる。しかし RFC 5232 は、保存済みの任意のメッセージを変更する権限までは与えなかった。フィルタリングの判断、配達されるコピー、メールボックスに残る状態は、別々の層にある。
欧州・中東のデータセンター
ミストラル・コンピュート：稼働実績の証拠を監査する——機隊数の矛盾と「通電」の空白
2026年3月30日、Mistral AI は創業以来初の負債調達として8億3,000万ドルを調達し、パリ近郊のデータセンター向けに Nvidia 製チップ13,800基を購入したと報じられた。この記事は、その資金で整備された計算機群が実際にいつから稼働しているのか、公表記録に基づく日付付きの証拠がどこまで存在するのかを監査する。調査の結果、Nvidia の公式ブログが「18,000基の GB200 がすでに稼働中」と記述する一方、2026年3月の融資は後継世代の GB300…
IETF
正しい5バイトが、32ビットの実装では別の値になった
CBOR として正しく、提案された私用範囲にも入っている整数が、アプリケーション境界を越えた瞬間に失われることがある。EDHOC の認証が成功しても、双方のプログラムが同じ数と同じ意味を保持した証明にはならない。
インターネット史
有効なsignatureにもpolicyが必要だった：RFC 3125
RFC 3125は、電子署名を取り巻く規則を参照可能で、必要なら machine-processable な対象にしようとした。暗号計算が正しいだけでは最初の gate しか通らない。どの policy bytes、commitment、trust condition、外部制度が適用されたかが残った。
欧州・中東のクラウドサービス
MainStreamingの「AI駆動型エッジ配信」は何を自動化しているのか — ベンダー主張とDAZN・ITV・BTの実証記録の検証
MainStreaming は、ISP ネットワーク内に埋め込まれた専用容量を基盤とする「ブロードキャストグレードのエッジビデオ配信ネットワーク」を標榜する企業である。本稿は、その「AI オーケストレーター」が実際に何を自動化しているのかをベンダー公開資料と独立系報道から検証する。
インターネット史
一通のメールに、異なる三つの数え方――RFC 5231
メールフィルターが数えるのは、メールボックス、配送エンベロープの宛先、それともヘッダーフィールドの行数なのか。RFC 5231 は比較を可能にしたが、数の意味は検査対象の構文に委ねた。
インターネット史
送信許可はpacket queueではなかった：RFC 3124
Congestion Manager は、一台の host で競合する application に送信機会を配る構想だった。ただし data を預からない。RFC 3124は、許可、host からの実送信、receiver feedback を別々の事実として残した。
IETF
現行鍵が後継鍵に署名した。それこそが問題だった
鍵のローテーション記録がきれいであるほど、見落としやすい問いがある。侵害されたかもしれない現行鍵に、次の支配者を単独で選ばせてよいのか。
インターネット史
Prefix listはまだaccess policyではなかった：RFC 3123
DNS は network prefix の列を正確に配ることができた。RFC 3123の重要な節度は、その列を命令に仕立てなかったことにある。record は表現を保存し、意味と決定と実行は別の主体に残した。
インターネット史
不在通知は文面ではなく、宛先への応答方針だった――RFC 5230
不在通知は、メールを読めない人に代わってシステムが送る一通だ。RFC 5230は、その当たり前に見える動作を、宛先確認、返信内容の識別、送信済み記録、再送までの時間という運用方針に分解した。
インターネット史
遅延の数値は時計についての主張でもあった――RFC 3116
ATM 装置の前後で timestamp を取り、差を計算する。それだけなら簡単に見える。RFC 3116が守ろうとしたのは、差の背後にある clock、counter、traffic 条件を消さないことだった。
IETF
同じノードの署名を確かめても、隣接者の世界は一致しない
監視画面に二つの正常な緑色が並んだ。どちらも同じ SAND ノードから届き、BPSec の完全性検証に成功している。ところが片方には IPv6 の収束層と三つの隣接点があり、もう片方には別の資格情報と異なる経路候補しかない。この差を即座に障害と呼ぶと、SAND が意図的に残した局所判断を、中央の誤った唯一真実へ変えてしまう。
インターネット史
同じシステムを共有しても、承認権は一つにならない――RFC 3113
第3世代 mobile system は Internet protocol を必要とした。IETF も radio network の現実を必要とした。RFC 3113が設計したのは統合組織ではなく、権限を奪わずに依存関係を運ぶ境界だった。
インターネット史
フィルターは一致を覚えられても、会話までは覚えない――RFC 5229
Sieve は、メール配送サーバーを何でも実行できるプログラム環境に変えずに、利用者が配送時の振り分け規則を書けるよう設計された。RFC 5229が加えたのは、小さな一時記憶である。名前を付けた文字列と、成功した照合から得る部分文字列だ。規則同士はつなげやすくなったが、値は実行中のスクリプトに属する状態であり、メールボックスの履歴でも、差出人の証明でも、汎用データベースでもない。