調査・分析
最新記事
インフラ運用者、政策決定、市場動向、デジタル権力の変化に関する最新情報。
インターネット史
中継点は識別子を承認した。宛先はまだストリームを受け入れていなかった――RFC 1190
1990年の ST-II では、経路の途中から肯定的な返事が届いても、まだ送信を始めてはならなかった。隣の agent は制御メッセージを受け取り、転送用の短い識別子を使えると答え、資源を確保していたかもしれない。しかし宛先 application の参加判断は、そのさらに先に残っていた。RFC 1190 は「途中まで進んだ」と「相手が受け入れた」を wire protocol の別イベントにした。
IETF
David Schinaziと、宛先の応答を待たずに成立するUDPトンネル
返事を待たないことは、確認を省略したという意味ではない。UDP には、そもそも全アプリケーションに共通する接続確認がない。RFC 9298は、その空白を推測で埋めず、プロキシが証明できる範囲だけを成功と呼ぶ。
NPNOG
誰が会場を開くのか――npNOG-10の式次第に見るnpNOG、NPIX、SANOG
会議の冒頭10分は、組織図のように見えることがある。ポカラで開かれた npNOG-10 の[公開プログラム](https://npnog.org.np/npnog10/programs/conference/)では、最初の歓迎挨拶を Rupesh Shrestha が担当し、肩書は NPIX Managing Director 兼 SANOG Chair と記されていた。続く歓迎挨拶は npNOG President の Samit Jana で、両者にはそれぞれ10分が割り当てられていた。その後に特別来賓の挨拶と開会基調講演が続く。
ケースファイル
W3C Math Working Groupの合意形成要請は1週間 沈黙は支持ではない
締切は決定を終わらせることができる。しかし、発言しなかった人の賛成まで作り出すことはできない。W3C Math Working Group の2026年憲章は、会議で採択した決議をいったん暫定扱いとし、1週間の合意形成要請（CfC）にかける。異議がなければ作業部会の合意とみなす一方、上位にある W3C Process は沈黙を棄権と定義し、合意には相当数の支持も求めている。両方を残す記録が必要だ。
インターネット史
公開ディレクトリには掲載を拒む権利が必要だった：RFC 1295 の境界
ネットワーク上で読めるという技術的状態は、公開してよいという判断とは別である。RFC 1295 が印象的なのは、この違いを抽象的な理念としてではなく、ディレクトリ運用の順序として置いた点にある。検索の便利さより先に、Public Directory に載らない権利を挙げたのである。
インターネット史
ホスト名は有効だった。それでも悪い名前だった――RFC 1178
仕様に通る文字列と、現場で迷わず使える名前は同じではない。RFC 1123 は1989年、数字で始まるホスト名を受け入れるようソフトウェアに求めた。ところが翌年の RFC 1178 は、管理者にはその命名を避けるよう勧めた。前者は適合実装の入口を広げ、後者は旧いプログラム、ローカルな補完規則、人間の会話が同じ文字列を同じ意味で扱うとは限らない現実を記録した。
インターネット史
フレームのラベルは仮想回線の設定ではなかった：RFC 1294 の多重プロトコル境界
Frame Relay の受信側が、一つのフレームの後ろにどのプロトコルがあるかを識別できても、その仮想回線で当該のカプセル化を使う権限まで得たわけではない。RFC 1294 はこの二つを明確に分離した。NLPID と SNAP は PDU の読み方を示す。どの VC がどのカプセル化方式を運べるかは、端点があらかじめ知り、明示的に設定しておくべき別の条件である。
IETF
RFC 9925はX.509証明書を無署名にした。信頼は別の場所から来る
RFC 9925が定義したのは、X.509 の形を保ちながら、署名値を意図的に空にした情報コンテナである。互換性のために発行者欄へ主体名を繰り返すことさえできるが、その値はプレースホルダーにすぎない。発行者は存在せず、自己署名でも自己発行でもない。これは技術的に誠実な設計だ。同時に、重要な問いをファイルの外へ移す。アプリケーションがその主体情報を信頼するなら、誰が、何の目的で、どのシステムに、いつまで通用する信頼を与えたのか。
IETF
Christopher A. Woodと単独の運用者に持たせないプライバシー境界
Oblivious HTTP が作るのは、何も見えない通信ではない。接続元を見られる役割と、内容を読める役割を分け、どちらにも全体像を持たせない通信である。その「分掌」を運用が守り続けられるかが、暗号そのものと同じほど重要になる。
インターネット史
要件は確定した。ホストはまだ設定されていない――RFC 1127
仕様書は大文字の MUST で議論を終えられる。しかし、その単語が機械室に入り、稼働中の値を選ぶことはない。1989年の Host Requirements は、相互運用の経験を義務・推奨・選択肢へと整理した。RFC 1127 が残したのは、その表の背後にある境界である。合意はどこまで強かったのか。何が未決のまま残り、適合する実装と実際の設定・動作・結果との間には何が必要なのか。
インターネット史
既知の DLCI はまだ使える隣接先ではなかった：RFC 1293 の InARP 境界
Frame Relay のネットワークが仮想回線と DLCI を通知しても、受信側の局は回線の向こうにある局のプロトコル・アドレスを知らないことがある。RFC 1293 の InARP は、この下位層の識別子を対端の身元や接続完了の証明に変えなかった。既知のハードウェア・アドレス宛に直接問い、返答できる局だけが適切なアドレスを返し、学んだ対応はローカルで老化または無効化されうる、という限定された発見の手順を定めた。
APRICOT
APRICOTはフェロー選考を「能力のみ」とするが、決定は最終で変更不能だ
APRICOT はフェローシップの基準と選考委員の氏名を公開している。しかし同じ公開資料は、選考に相当程度の主観的評価が含まれることを認め、決定を最終かつ交渉不能としている。重要な事実に誤りがあり得る場合、「能力のみ」という約束を検証することは難しい。
ケースファイル
UDPのユーザーデータは保護された。だがオプションはそうではない：RFC 9868
RFC 9868 は UDP にトランスポート・オプションの領域を設ける。それは DTLS が保護する UDP ユーザーデータの一部になるわけではなく、オプションの検査、送信、保護済みペイロードをもって、オプション処理や結果の証拠にはできない。
ケースファイル
Internet Societyは9回連続の理事会で公開フォーラムを設けなかった
2025年5月14日から2026年7月25〜26日まで、Internet Society が公開した9回連続の理事会議題には、傍聴の入口はあっても、理事に質問し、意見を届け、議論するための Open Forum はなかった。透明な会議室であることと、発言できる会議室であることは同じではない。そして、発言できたとしても、それだけで決定権や代表権が生まれるわけではない。
インターネット史
カタログは相互運用性の判定ではなかった：RFC 1292 の X.500 スナップショット
実装をカタログに載せることは、分散していた選択肢を発見可能にする。しかし、それだけで二つの実装が接続できること、同じディレクトリを読めること、あるいは利用者が役に立つ結果を得ることにはならない。RFC 1292 は 1992 年 1 月、X.500 実装を配布方法、DSA/DUA の形態、転送環境、パイロットへの接続性、機能、動作環境で索引化した。これは比較の入口をつくった文書であり、接続の記録、適合性試験、導入判断、サービス成果の証明ではない。
インターネット史
行は完成した。だが命令はまだ走っていない――RFC 1116とTelnet Linemode
遠い計算機を使っているのに、文字は手元ですぐ現れ、削除も待たずに効く。1989年の Linemode は、この感覚をネットワーク往復から切り離した。入力行をクライアントで整えてから送れば、遅延とパケット数は減る。しかし、手元で完成した行は、遠端で完了した処理の証明にはならない。
IETF
Martin Thomsonと、セッションを復号できても発生を証明できない鍵ログ
暗号化されていた通信が読めるようになった。それは重要な事実である。しかし、「読めた」と「その人物がその通信を行った」は同じ文ではない。間にある取得経路、権限、エンドポイント、時刻、保全の記録を、鍵ログは持っていない。
ケースファイル
カーソルが続けたのは一覧であって、権限ではない：RFC 9865
RFC 9865 は、すでにカーソルを使う基盤のために SCIM のページ送りを整える。次ページを指す値を、持ち運べるアクセス権や確定済みの判断へ変える仕様ではない。
SANOG
SANOGの「8カ国」の地図を、6つのNOGによる委員会は覆えていない
SANOG は南アジア8カ国を活動地域として掲げている。一方、公表された将来のガバナンス案で、ローカル NOG から中核委員会へつながる経路は6団体に限られる。アフガニスタンとモルディブには、同等の制度的な入口が見当たらない。
記事
AFRINICはJSContactを追加したという。RDAPガイドはどのJSContactかを示していない
変更履歴に機能名が載ることと、利用者がその機能をどのように扱うべきかが文書化されることは、同じではない。AFRINIC の公開記録は前者を示している。現在の RDAP ガイドは問い合わせの入口を示している。しかし、その二つを結ぶ表現形式の記録は見当たらない。