コンテンツ種別
Research
コンテンツ種別の観点では、Research は同じ編集形式を持つ BTW.MEDIA の記事を集約し、解説、プロフィール、リスクノート、市場分析、イベント記事を、種類の異なる証拠を混ぜずに比較できるようにします。このページは、この記事タイプがサイト上のインターネット基盤の出来事、企業の動き、ガバナンス上の決定、運用上のシグナル、公開された証拠をどのように位置づけるかを説明します。読者は、どの主体やインフラシステムが頻繁に登場するか、情報源の質が解釈をどう変えるか、対象が継続的なプロフィールなのか、時限性のあるイベントなのか、戦略的な市場シグナルなのか、ガバナンス上の進展なのかを比較できます。同じ形式の記事の背景、時期、証拠を理解したい運用者、投資家、顧客、アナリスト、政策関係者にとって役立つ検索ページです。

研究者
David J. FarberとInteresting People:議論を可視化しても利用者を代表するわけではない
1993年のモデレーターの案内には、投稿の歓迎と最終的な掲載判断の両方が記されている。アーカイブで検証できるのは選ばれた論点であり、ネット利用者全体の意見ではない。

インターネット史
Archieの検索結果は、最後に取得したFTP一覧より新しくならない
Archie は、各地の匿名 FTP アーカイブからディレクトリ一覧を集め、まとめて検索できるようにした。検索結果が示すのはファイル名と置き場所であり、ファイル本体ではない。しかも、その記録が表すのは最後に一覧を取得した時点の状態だった。

インターネット史
ライセンス対象はソフトウェア、プロトコルではない――Gopherが1993年に引いた境界
1993年3月11日、ミネソタの Gopher チームは Usenet に声明を投稿し、まず流言や憶測に歯止めをかけようとした。後世に残った要約は「商用利用には料金がかかる」という一文だ。しかし原文は、サーバーの用途、公開範囲、そして University of Minnesota のソフトウェアを使うかどうかを分けていた。ここで混同されがちな核心は、特定の実装に対するライセンスと、Gopher プロトコルそのものは別だという点にある。

IETF
RFC 10065が運ぶのはグループID。ポリシー実行の証拠ではない
グループ ID を RADIUS で運べても、その文字列がどのパケット属性やポリシーに結び付くかは自動では決まらない。RFC 10065はこの対応付けを環境ごとの設定に残している。運用の焦点は、ID そのものよりも、対応表の更新と適用を追跡できるかにある。

リーダー
Alan Greenbergと、GNSOの審査を始めた要請
2007年5月、Alan Greenberg は ALAC の決定を GNSO の正式な手続きへ届けた。求めたのは、ICANN スタッフによる domain tasting(ドメインテイスティング)の調査だ。要請は検討への入口を開いたが、政策を決めたわけでも、参加者に全インターネット利用者を代表する権限を与えたわけでもない。

インターネット史
プラグの四本のピン――NORDUnetが示した欧州のプロトコル選択
1988年5月、北欧の研究ネットワークは米国に NSFNET への接続を申請する一方、地域の幹線で複数の既存ネットワークサービスを運ぶ構想を示した。「四本のピンを持つプラグ」は、より難しい問いを可視化した。関係者が一つのプロトコルに決める前に、共通のネットワークを作れるのか。

リーダー
Tina Damと、ドメイン名を承認できなかったルートゾーン試験
国際化トップレベルドメインをルートに加える前、ICANN は問いを意図的に絞った。符号化されたラベルは、DNS 問い合わせを次へ運ぶサーバーやリゾルバーに影響するのか。実験室の試験が答えたのは、用意された環境でのこの問いだけだ。どのコミュニティの名前を認めるかも、利用者がその名前を使いやすいかも判断していない。

IETF
Syslogは時計品質を報告できるが、その限界は運用者が設定する:RFC 5424
複数の機器のログを一つの時系列に並べると、順序が確定したように見える。RFC 5424は、送信元が自分の時計について何を把握しているかをメッセージに添える方法を定めた。ただし、その情報を作るのも送信元であり、受信側が時計を独立に測定した結果ではない。

IETF
EAP-FASTトンネル内では、Type 6の意味が変わった:RFC 5421
RFC 5421は、既存の EAP メソッドコードを新しい枠に持ち込んだ。Type 6は登録簿上では Generic Token Card のままだが、EAP-FAST トンネル内では異なる形式の内部交換を選ぶ。仕様は内外の使い分けを明確に禁じ分け、IESG Note はコード再利用がメソッド交渉と実装に与える互換性上の難しさを指摘した。

研究者
Lorrie Cranorが示す、コードから追えるプライバシー表示
Google Play の Data safety をめぐる実務上の問いは明快だ。ストアに載る各項目を、アプリのコードや SDK の挙動までさかのぼれるだろうか。Lorrie Cranor の使いやすいプライバシーに関する研究は、ソフトウェアの実態を公開表示へ移す作業を、開発の流れに戻そうとしている。

IETF
プロビジョニング成功だけではネットワークアクセスは決まらない:RFC 5422
RFC 5422は資格情報の準備完了とネットワーク利用の許可を分け、サーバー未認証モードをプロビジョニング専用として扱う。

インターネット史
欠陥の説明とワーム本体の公開は別だった:RFC 1135の開示論争
1988年の Internet worm 事件は、「公開するか、隠すか」という一つの問いに単純化されがちだ。しかし同時代の記録が示すのは、脆弱性の説明、手法の解説、修正の配布、そして改変可能な逆コンパイル済みコードの公開を分ける判断だった。RFC 1135は複数の立場を並べて記録したが、共通ルールにはしなかった。

リーダー
Rebecca MacKinnonのGNI復帰が照らす、二つの説明責任評価
企業が公表する方針を比べる評価と、非公開資料や個別事例を確かめる審査では、見えるものが違う。2026年8月の Rebecca MacKinnon の Global Network Initiative(GNI)復帰は、彼女が創設した Ranking Digital Rights(RDR)と GNI の二つの手法をあらためて並べて考える機会になった。どちらもデジタル上の権利を扱うが、示せる結論は限られている。

IETF
AAAは加入者を認証した。それでもHAには鍵が必要だった:RFC 5419
RFC 5419は、Mobile IPv6 の一部の運用者が、既存の AAA 関係を加入者認証に使いたかった理由を記録している。焦点は認証の成否だけではない。ホーム AAA が加入者を認識しても、選ばれた Home Agent(HA)には、使える形で範囲の定まった MN–HA セキュリティアソシエーションが必要になる。

インターネット史
「通常」でも審査は要る:RFC 6709の拡張判定
プロトコルの変更を「通常」と呼ぶと、小さな修正だから詳しく見る必要はない、という印象を与えやすい。RFC 6709が示した基準はもっと厳密だ。基盤となるプロトコルや稼働中の実装が、その拡張を安全に無視できるかどうかである。条件を満たしても、専門家の審査が不要になるとは限らない。

IETF
CAPWAP接続の認証は、導入先への登録を意味しない:RFC 5418
RFC 5418 は WTP–AC 間の認証、特定の導入先への登録、装置の役割、クライアントデータの経路を別々に扱う。セッションが成立しても、運用上の問いは残る。

インターネット史
一つのInternetを支えた複数の運用者:RFC 1462の電話会社比喩
1993年の FYI は電話会社の身近な例で Internet の構造を説明した。利用者には一つのサービスに見えても、運用と修理は複数のネットワークに分かれていた。

インターネット史
NATはインターフェースではなく論理機能だった――RFC 4008の管理モデルが改められた理由
RFC 4008の設定例では、SNMP マネージャーはまず`ifIndex`を指定した行を作り、その後でアドレスマップを登録する。10年後の NATV2-MIB は、変換機能をインターフェースから切り離し、論理インスタンス、アドレス領域、加入者、リソースプールを軸に記述した。両者の間には、旧モデルが多くの実装に合わなかったと規格自身が認めるまでの経緯がある。

リーダー
Anriette EsterhuysenのIGF構想が問うた、制度に残る能力
IGF の2021年進捗報告には、助成金、参加支援、オンラインの学習会が記録されている。Anriette Esterhuysen がそれ以前にまとめた枠組みは、もっと長い時間軸を向いていた。会合のあとも、人と組織は自らのインターネット政策目標を定め、実現し続けられるのか。

インターネット史
フレームは疑似回線を越えたが、サービス上の役割は届かなかった:RFC 7152
2014年、IETF の要求文書は、レイヤー2 VPN にある見えにくい欠落を示した。プロバイダーエッジは疑似回線から Ethernet フレームを受信できても、遠隔側の接続が Root なのか Leaf なのかを知らないことがある。RFC 7152は、この文脈の欠落を Ethernet Tree サービスの要件として記録した。
