調査・分析
最新記事
インフラ運用者、政策決定、市場動向、デジタル権力の変化に関する最新情報。
インターネット史
本文は「標準」と言い、記録は「情報提供」と言った――RFC 1216
RFC 1216 は、IAB の標準化トラックに向けた新しい標準パラダイムを提案すると書いた。ところが RFC Editor の記録は Informational、Independent Stream と分類し、IETF は自らの承認を受けた文書ではなく、標準化プロセス上の正式な位置もないと明記する。本文の自己紹介と制度上の地位は、同じ証拠ではない。
NPNOG
主催者の裁量に委ねられる安全：npNOG行動規範の実施構造を検証する
npNOG は、ハラスメントを禁じ、主催者が迅速に対応できる規則を公開している。一方、申告を誰が受け取り、情報をどう守り、利害関係があるとき誰が退き、誤りをどう訂正するのかは、公開資料から同じ精度では読み取れない。
IETF
Murray Kucherawyと、末尾を署名の外に残したDKIM
`dkim=pass`は、message 全体に貼る品質保証ではない。DKIM-Signature に`l=`があれば、検証対象は canonicalize 後の body 先頭部分で終わり、その後の bytes は reader に表示されても署名の外にある。
インターネット史
ポートにはポートの状態がある。セッションには別の状態がある：RFC 1316
運用画面の一行は、しばしば多くを約束しているように見える。ポート名、状態、増え続ける文字数、そして reset に書ける `execute`。しかし 1992 年の RFC 1316 は、その一行を一つの物語にしなかった。Character MIB は、文字を運ぶポート、そこで成立するセッション、管理上の意図、実際の運用状態、集計値、制御を別々の対象として置く。ポートについて正しい記録が、特定のセッション、相手、利用者、画面やアプリケーションの結果まで正しいとは限らない、という設計である。
インターネット史
インターフェースはダウンだった。全回線が失敗したわけではない：RFC 1315
一つの状態表示を、そこにつながるすべての関係の結論にしてしまうと、監視は便利であるほど危険になる。1992年の RFC 1315 は Frame Relay DTE の MIB を定め、一つの物理インターフェースの下に複数の仮想接続を置いた。所定の問い合わせ間隔と観測窓で無応答を数え、閾値を超えればエージェントはそのインターフェースを down と判定できる。しかしそれは局所的な管理判断であり、全仮想回線、遠隔装置、フレーム、サービス結果の判決ではない。
インターネット史
トラップは定義済みだった。事象はまだ観測されていない――RFC 1215
障害が起きる前から、トラップには名前も変数も説明も番号もある。RFC 1215 は1991年、その定義を SNMP の Trap-PDU に結び付ける手順を整えた。ただし、定義が整ったことと、実行時に何かを観測したことは別である。認識、生成、送信、受信、確認、対応には、それぞれ別の記録が要る。
IETF
John Klensinと、配送ではなく責任を引き受けたSMTP応答
送信側の queue は、DATA の末尾で`250 OK`を受けると自分の copy を消せる。これは乱暴な最適化ではない。相手が保管責任を引き受けたからだ。ただし、その瞬間に recipient の mailbox を観測した者はまだいない。
ケースファイル
SC-106は非Webのrelying partyを挙げる。SCWG Charterが挙げるのはブラウザである
ML-DSA の Draft は、SDK、組み込み機器、IoT、企業 middleware、OS の trust store を利用するアプリケーションを必要性の根拠に置く。一方、SCWG で投票できる Certificate Consumer は、安全な Web 閲覧用ソフトウェアによって定義される。技術的に有用な profile であることと、その profile を誰のために共通化する権限があるかは、別の問いである。
インターネット史
ファイルはファクス通話ではなかった：RFC 1314
スキャンした一枚の紙がファイルになっても、それだけで送信・印刷・閲覧の出来事にはならない。1992年の RFC 1314 は、ファクスに似た白黒画像を交換するために TIFF-B を定めた。複数ページを扱い、一ページを一つの TIFF strip で表す。しかし、この仕様の重要な慎重さは、ファイル形式を運搬、保存、表示、印刷、そして人の反応の証明にしなかった点にある。ファイルは交換のための対象であり、後続の全行為の証人ではない。
NPNOG
席に限りあり：npNOGワークショップの収容力をどう配るか
先着順、空席条件、当日参加不可、フェローシップ。npNOG の公開情報から、限られた実習席を配る仕組みと、その記録だけでは分からないことを検証する。
インターネット史
アドレスは不達になった。主リストに載っていたとは限らない――RFC 1211
不達通知に一つの宛先が現れたのに、主リストを検索しても見つからない。RFC 1211 が描いたのは、記録漏れではなく入れ子になった配布構造だった。主リストが保持するのは一個の展開用別名だけで、その先の会員表は別組織が管理している。中央の担当者には手掛かりはあっても、最後の一行を書き換える権限はなかった。
ケースファイル
内容種別は YAML だった。決定はなおローカルに残った。
`application/yaml` は到着した表現の形式を知らせる。受信者がそれを受け入れ、解釈し、現実の状態を変えてよいことまでは知らせない。
インターネット史
サーバーはプラスを返した。メッセージが読まれたわけではない：RFC 1312
短い肯定応答は、十分に狭く読めば有用である。RFC 1312 の Message Send Protocol 2 は、その狭さを自ら明記した。TCP の `+` はサービス上の成功を示せるが、サーバーがローカルのメッセージ配送サービスを呼び出しただけかもしれない。表示、端末の前の人、内容の閲覧は、同じ一文字から導けない別の出来事である。
IETF
Tomek Mrugalskiとリースを更新しなかったDHCPv6の「成功」
IPv6 アドレスがインターフェースに残っている。`Confirm`への Reply も`Success`だった。それでもリースの残り時間は増えていない。RFC 9915は、現在のリンクに合うという判断と、利用期限を延ばす権限を別の取引として設計した。
ケースファイル
SC-104はAIAをMUSTからSHOULDへ移す提案だが、二つのメソッドは同じにならない
証明書に AIA が「ある」という記録だけでは、発行者証明書を取得できるのか、OCSP を利用できるのか、クライアントがどちらかを実際に使ったのかは分からない。SC-104 が変えるのは最も外側の規範語であり、運用結果ではない。二行の変更を誤読しないための単位は、五つの状態である。
ケースファイル
コントローラには枠組みがあった。決定的サービスはまだ成立していなかった：RFC 9938
RFC 9938 は DetNet コントローラプレーンに必要になり得る仕事を整理する文書である。フロー要求、経路計算、設定投入を、実際に成立し維持され観測されたサービスの証明へ変えるものではない。
ケースファイル
委任された LSP は、委任されたネットワークではない
RFC 9504 は GMPLS 制御ネットワークで状態保持型 PCE を使いやすくする。だが、PCEP 上の記録を運用権限の移転に、あるいは経路要求をサービス実績に変えるものではない。
インターネット史
経路は回線を要求した。回線を作ったわけではない：RFC 1306
経路探索の結果が、外部の交換制御装置への要求につながることがある。RFC 1306 が記録した 1992 年の Cray プロジェクトは、そのような要求型 T3 回線の経験を扱う。ただし文書は、経路、要求、回線の確立、TCP の最初の送信を一つの成功にまとめない。要求が見えた時点で確定しているのは、要求が発行されたという限定された事実だけである。
NPNOG
「謝意」の5分間：スポンサーの可視性はnpNOGの技術プログラムにどう入ったか
npNOG-11 の公開日程には、登壇者とスポンサーを顕彰する5分枠が3回ある。商業的な可視性を測る手掛かりではあるが、技術内容の選定権まで示すものではない。
インターネット史
サーバーは 250 と答えた。アカウントは存在しないかもしれない――RFC 1204
同じ三桁が、同じ事実を意味するとは限らない。RFC 1204 では、構文が正しい `USER` なら、未知のユーザー名にも `250` を返すことが推奨された。アカウントの有無を外から調べさせないためである。パスワードの照合、メッセージ本文の入口、ローカルキュー、配送は、その後に残された別の境界だった。