調査・分析
最新記事
インフラ運用者、政策決定、市場動向、デジタル権力の変化に関する最新情報。
インターネット史
運ぶ網が接続そのものではなかった――RFC 892が輸送状態と経路を分けた理由
下の接続が切れたとき、上の接続も必ず死ぬのか。RFC 892 の答えは class によって違った。class 0 では寿命が結び付く。回復機能を持つ class では、別の Network Connection へ割り当て直して同期し直せる。この差が、二つの「接続」を同じものとして扱えない理由だった。
ケースファイル
秘密鍵は動かなかった。利用権限は越境した：RFC 9987と SSH エージェント転送の推移的信頼
シェルを閉じれば、そこから始まった権限も消える――そう考えるのは危険だ。RFC 9987では、ポリシーが許せば、転送を要求したセッションが閉じた後もエージェント接続を受け付け得る。鍵の所在、接続の寿命、署名の効力は別々の時間軸にある。
ケースファイル
認証失敗がメーリングリストを明かすとき――RFC 9991とDMARC報告の開示権限
正当なメーリングリスト投稿が転送中の変更で DMARC に失敗したとする。詳細な報告は設定修正に役立つ一方、投稿者のドメインや外部委託先に、これまで見えなかった会員アドレスと配送先を渡し得る。RFC 9991は失敗を報告する共通手順を作った。誰が通信内容を開示できるかまで、DNS の要求に委ねてはいない。
IETF
Gavin Brownと、ドメイン登録にはまだ至っていなかった「成功したcreate」
受付票は、窓口が申請を受け取った証拠である。採択通知ではない。RFC 8334の`applicationID`は、この二つを混同しないための番号だ。EPP コマンドが成功しても、ドメインの割当はまだ保留になり得る。
ケースファイル
SC100草案はDNSSECの境界をプライマリ視点に置く。レシートはそれを名指しすべきだ
「DNSSEC 成功」という一行は、暗号学的な結果を示しても、規則が求めた主体を示さない。SC100 草案が明確にするのは、DNSSEC の義務がプライマリ・ネットワーク・パースペクティブに属するという点だ。リモート・パースペクティブでも DNSSEC を実行できるが、MPIC での固有の役割はプライマリ判断の独立した裏付けである。結果から役割を消せば、証拠は規則の境界も消してしまう。
記事
APNIC ECは議題「Shepherd」を採用したが、役割規程はまだ公開していない
ある議題を継続して追う人がいることと、その人が理事会を代表して決められることは同じではない。APNIC の Executive Council（EC）は2026年5月、重要テーマごとに議論を導く「Shepherd」モデルを採用した。分業としては理にかなう。ところが今回凍結した公開ページでは、担当者、権限、発言の限界、EC への戻し方を定める共通文書が見当たらない。
IETF
Russ Housleyと、証明書には記せても一意にはできないMACアドレス
証明書は6個または8個のオクテットを正確に固定できる。だが、その値を現在使っているインターフェースや、通信を許可した現場の判断まで固定できるわけではない。
インターネット史
最短経路は時刻を運んだが、親時計を選ばなかった――RFC 891のHELLO
RFC 891では、経路表の一行に往復遅延と時計オフセットが同居した。しかし、速い経路が時刻の権威になったわけではない。経路は測定で選び、親時計は設定で指定し、補正の可否は各ホストが判断した。
ケースファイル
SC101はドメイン管理の穴を塞いだ。それでも移行中は二つの規則が有効だ
監査人が9月の証明書発行を調べ、「当時の最新版は TLS Baseline Requirements v2.2.9 だった」と確認しても、調査は終わらない。v2.2.9 自身が11月15日まで旧 v2.2.7 の第3.2.2.4節を選べるようにしているからだ。SC101 は CNAME とラベル削除の危険な順序を正した。しかし移行期間の証拠が版と処理経路を残さなければ、正したはずの曖昧さが運用記録へ移る。
インターネット史
フレームはデータグラムより長かった――RFC 894がEthernetパディングをIPの外に置いた理由
受信バッファには46オクテットあるのに、IPv4 の Total Length は20を示している。どちらかが誤りとは限らない。Ethernet は最小フレームを満たすための長さを報告し、IP は自分のデータグラムの終端を宣言する。RFC 894は、同じ受信イベントに二つの正しい長さが存在できることを標準にした。
ケースファイル
形式は正しかった。だがスキーマは誰が選んだのか――RFC 9996が残すProtobufの権限境界
Protobuf のメッセージを十年後に再生できても、当時と同じ業務上の意味を再現できるとは限らない。RFC 9996はバイト列の形式に正式な名前を与えた。しかし、フィールド番号をどの定義で読むか、その定義を誰が承認したかまでは決めていない。正しいメディアタイプは、意味の出所を証明するものではない。
記事
AFRINICの新規会員ポータルは三つの事前案内を掲げる。リンク先はすべて同じ404だ
申請ポータルそのものは開き、要件や問い合わせ先も読める。切れているのは、その直前に置かれた三つの案内だ。手続、資格、提出書類という別々の問いが、一つの存在しないページに集約されていた。
IETF
Benoît Claiseと、ベースモジュール自身には見えないaugment
依存関係を読むとき、出発点のファイルがすべてを語るとは限らない。YANG では、別のモジュールが外からノードを差し込める。RFC 10035は、その逆向きの関係をサーバーの現在形として記録する。
欧州・中東の国内通信事業者トレンド
農村部の4G基地局は、事業者と場所が一致するまで地域の通信可能性を証明しない
基地局が稼働し、全国目標が達成されても、必要な場所で特定の端末が使えるとは限らない。地域で受け入れるには、事業者、場所、利用環境を特定する必要がある。
インターネット史
「誰かいるか」と「あなたが提供しているか」は別の質問だった――RFC 887のサービス発見
ブロードキャストへの沈黙は、明示的な否定応答ではない。RFC 887はこの違いを、質問そのものを二種類に分けて表した。さらに第三者の案内を、提供者本人の確認より弱い情報として扱った。
ケースファイル
WebDriverはCandidate Recommendationにとどまり得る。スナップショットを示せ
「WebDriver 対応」という表示は、一つの固定した規格を指すように見える。ところが W3C が審査中の Browser Testing and Tools 作業部会憲章案は、WebDriver と WebDriver BiDi を Candidate Recommendation まで進め、Snapshot を重ねながら継続更新し、Recommendation…
IETF
Kazuho Okuと、拒否を見える化してもストリーミングを約束しないHTTPフィールド
接続が切れず、サーバーも応答を作っているのに、最初のデータだけが届かない。RFC 10036は、その原因の一部を「対応する仲介者の明示的な拒否」に変える。一方で、フィールドを知らないホップまで従わせるものではない。
インターネット史
「公式リスト」は実装証明ではなかった――RFC 880が状態と動作中コードを分けた方法
Telnet の欄には、仕様書があるかだけでなく、古い手引きに残っているか、改訂版に収録されたか、一般に使われているかという別々の列があった。RFC 880は、ひとつの「対応済み」という言葉ではオプションの現実を表せないことを表の形で示していた。
ケースファイル
封筒が署名したのはダイジェストであり、原物を届けたのではない：RFC 9995とCOSE Hash Envelopeの権限
監査端末はネットワークから隔離されたまま、受け取った短い COSE オブジェクトの署名を検証できる。これは失敗ではなく、設計どおりである。しかし原物が手元にない以上、その端末は「照合済みの証拠を読んだ」とまでは言えない。RFC 9995は、この二つの成功を意図的に分ける。
ケースファイル
WebAuthn新憲章案は任意データ署名を対象にする。対象化は承認ではない
W3C が審査中の Web Authentication 作業部会憲章案には、認証以外のデータを WebAuthn 経由で署名する作業が新たに含まれる。想定例としてエージェント型 AI と検証可能なデジタル資格情報も挙がる。しかし、作業対象に加える決定は、現在の設計を承認する決定ではない。Level 4には最初の公開草案すらなく、`sign`拡張は Draft のプルリクエストであり、説明文書には利用者調査も主要ブラウザーの見解もない。統治に必要なのは、この距離を短く見せることではなく、権限、提案、検証、標準化、実装、普及を別々の状態として残すことだ。