コンテンツ種別
Research
コンテンツ種別の観点では、Research は同じ編集形式を持つ BTW.MEDIA の記事を集約し、解説、プロフィール、リスクノート、市場分析、イベント記事を、種類の異なる証拠を混ぜずに比較できるようにします。このページは、この記事タイプがサイト上のインターネット基盤の出来事、企業の動き、ガバナンス上の決定、運用上のシグナル、公開された証拠をどのように位置づけるかを説明します。読者は、どの主体やインフラシステムが頻繁に登場するか、情報源の質が解釈をどう変えるか、対象が継続的なプロフィールなのか、時限性のあるイベントなのか、戦略的な市場シグナルなのか、ガバナンス上の進展なのかを比較できます。同じ形式の記事の背景、時期、証拠を理解したい運用者、投資家、顧客、アナリスト、政策関係者にとって役立つ検索ページです。
インターネット史
一つの安全なストリームに一つの TLS 接続が要った：RFC 3436
SCTP は一つのアソシエーションに複数のメッセージストリームと複数の経路を持ち込んだ。RFC 3436 は、その各双方向ストリームに別々の TLS 接続を置くことで独立性を守ったが、順序、信頼性、ハンドシェイク費用までストリームごとに引き受けた。
インターネット史
通知先はコマンドを受け取ったが、引き継ぎ競合は解かなかった：RFC 3435
メディアゲートウェイが予備の Call Agent へ通知先を切り替えても、どちらの制御器が完全で正当な呼状態を持つかは決まらない。RFC 3435は宛先を一つにしたが、引き継ぎの仲裁まで発明したわけではなかった。
IETF
障害が深刻になると、カウンターは静かになった
測ることと、状態を分類することは同じではない。RFC 3637 の WIS 管理では、ハードウェアから得た1秒分の事実をエージェントが分類し、その結果によって一部のカウンターを加算しない。深刻な状態ほどグラフが穏やかに見える場合がある。これは計測の失敗ではなく、公開された投影規則である。
IETF
測定ラベルが観測対象のフローを別経路へ動かした：RFC 9714
本番パケットに印を付ければ、合成プローブより現実に近いとは限らない。RFC 9714 の Flow-ID Label は MPLS の実トラフィックを測定できる一方、ラベルスタックを変え、ECMP が選ぶ経路まで変える可能性がある。
インターネット史
ポーリング失敗後のゼロは測定値ではなかった：RFC 3434
監視画面にゼロが現れると、私たちは「何も流れていない」と読みたくなる。RFC 3434 が残したのは、その誘惑への技術的な反論だった。取得できなかった値を格納するゼロと、本当に観測されたゼロは同じ記録ではない。
インターネット史
数値には尺度・精度・時刻が必要だった：RFC 3433
センサーが返した整数は、まだ測定値ではない。RFC 3433は、型・尺度・精度・状態・更新時刻を同じ証拠として残し、表示上の数字と物理的な事実の間に境界を置いた。
IETF
スナップショットが使用済み鍵を復活させた：RFC 9708
障害復旧が成功したように見えても、署名システムにとっては時間の逆行かもしれない。RFC 9708 が証明書と CMS に持ち込む HSS/LMS では、秘密鍵は単なる秘密データではない。二度と使えない葉を記録し続ける、有限で不可逆な台帳でもある。
ケースファイル
NovaCloud-Hosting（AS209874）の「本当の上流」：登録情報が示す三つの経路と、事業者が語る三つの物語
NovaCloud-Hosting（AS209874）の「本当の上流」：登録情報が示す三つの経路と、事業者が語る三つの物語の調査概要では、今回の動き、読者が確認できる公開証拠、関係する組織、地域的背景、市場への影響度、今後起こり得るインフラへの影響を解説します。ケースファイルの調査・分析の文脈では、この動きをネットワーク運用、事業者戦略、ガバナンス上の判断、資本の流れ、顧客への依存、規制圧力、提携の動き、強靱性への備え、調達リスク、サービス継続性に結び付けて示します。
IETF
先頭のKDCアドレスは、稼働証明ではなかった
フェイルオーバー画面は、先頭の KDC を緑、二番目を待機中と表示した。だが RFC 3634 が渡したのは監視結果ではない。優先度の高い順に並べた IPv4 アドレス列である。どのクライアントが何秒待ち、どの失敗で次へ進み、相手をどの realm の KDC と確認したかは、その列の外にあった。
インターネット史
開始時刻はランダムでも、ストリームは周期的だった：RFC 3432
最初の一歩をくじ引きで決めても、その後の足取りまで不規則になるわけではない。RFC 3432 は周期プローブの有用性を認めながら、その位相と偏りを結果から切り離してはならないと教えた。
IETF
発信者カードは「検証済み」だった。信頼は挿入者で止まる：RFC 9796
端末に表示された印は、署名そのものではない場合がある。RFC 9796 は、上流で検証した事業者が結果を `Call-Info` に写し、端末がその事業者を信頼する仕組みを定める。だからこそ、誰の判断なのかを消してはならない。
インターネット史
パケットは届いた。会計記録はまだ安全ではなかった：RFC 3423
配送確認が返った瞬間にも、受信アプリケーションの仕事は残っている。RFC 3423 は、ネットワークが見届けた事実と、永続ストレージが引き受けた事実を同じ成功表示に閉じ込めなかった。
IETF
同じ「No」が、拒否にも取消しにもなった
監査担当者は同じログ行を二度読むことになった。`TRANSFER`、`-Approve:No`、応答は 200。一度目は現スポンサーの registrar による拒否、二度目は申請した registrar による取消しだった。文字列の差はない。違ったのは、認証された話者と、その話者が保有していた権限である。
IETF
回線のクロックは続いた。欠けたビットは作られていた：RFC 9801
同期回線の出口は、遅延したパケットを待つために時間を止められない。RFC 9801 は欠損分と同量の代替データを出し、クロックを保持する。この動作は回線を継続させるが、遠端のビットが届いた証明にはならない。
インターネット史
拒否は名前の不存在を意味しなかった：RFC 3425
古い DNS 診断が opcode 1を送り、サーバーが`NOTIMP`を返す。そこで「逆引き名なし」と表示した瞬間、ツールは操作の廃止と名前の不存在を一つにしてしまう。RFC 3425が残した境界は、その短縮を許さない。
インターネット史
そのサービスが最良だったのは、指定したソートキーの中だけだった：RFC 3421
先頭に表示されたサービスは、まだ一度も接続を受けていないかもしれない。RFC 3421が順位に与えた根拠は、ディレクトリの属性と要求された比較手順までだった。その先の可用性は別の観測である。
IETF
成功した応答には、二つの名前が残っていた
RFC 9735 の LISP DN 検索では、`ietf.lisp` への問い合わせに、より短い登録名 `ietf` が返り得る。これは正しい最長一致である。しかし、正しい応答と完全一致した識別子は同じ事実ではない。
インターネット史
トランスポートドメインが来るまで、アドレスはただのバイト列だった：RFC 3419
障害対応画面に一つのアドレスが表示されると、対象は特定できたように見える。RFC 3419が残した教訓は逆だ。読み方を指定するドメインがなければ、その値からプロトコルもポートも IPv6 のゾーンも確定できない。
IETF
TLS は通った。目的の相手かは別の記録だった。
TLS の接続は成功し、証明書チェーンも鍵所有の証明も問題なく終わった。それでも、その接続先がアプリケーションの求めた組織だったとは限らない。参照名を作る処理が別のテナント名を渡していれば、暗号は実際の相手との通信を正しく守りながら、業務上は誤った場所へ安全に到達する。緑の錠前が嘘なのではない。錠前に、与えられていない問いの答えまで求めたことが誤りである。
グローバルのクラウドサービス
csoft（Cloud Software - FZCO）：リース型IP空間と二重法人構造で構築されたホスティング基盤 AS211273の実態
アラブ首長国連邦の自由地区に登録された小規模なクラウドソフトウェア企業が、インターネット基盤の上ではほぼ registry の記録を通じてしか姿を見せない。その実体を RIPE の登録データが解き明かすと、ホスティングブランド HostVDS の背後に、香港の契約主体とドバイのネットワーク主体という二重構造が浮かび上がる。本稿は、その構造がどのようにグローバルな到達性を組み上げているのかを、接頭辞の列挙と WHOIS 編集履歴から検証する。