調査・分析
最新記事
インフラ運用者、政策決定、市場動向、デジタル権力の変化に関する最新情報。

IETF
Mirja Kühlewindと、ネットワークRTTではなくアプリ周期を測ったQUIC spin bit
観測点には200ミリ秒ごとに整った反転が現れた。これをそのまま経路 RTT と呼ぶと誤る。疎なアプリが200ミリ秒周期で送信していれば、速い経路の上でも同じ波形が生まれるからだ。

インターネット史
指紋は一致した。それでもまだ誰も署名していなかった:RFC 1319
長さを問わないメッセージを 128 ビットに縮める値は、結論まで縮めたように見える。1992 年の RFC 1319 が MD2 に与えた役割は、そこまでではない。任意長のメッセージを入力とし、128 ビットの fingerprint、すなわち message digest を出力する。RFC はこのアルゴリズムをデジタル署名の用途に意図したが、digest そのものが署名であるとは言わない。人を識別するとも、秘密鍵の支配を示すとも、送信、受領、時刻、許可を証明するとも言わない。digest…

ケースファイル
CA/B Forum草案は失効の終点を公開する。時計はCA内部で動き始める
証明書の失効には、外から確認できる「終わり」と、CA だけが最初に知る「始まり」がある。servercert の pull request 622は前者を CRL と OCSP の応答で定義しようとする一方、後者を問題報告が`actionable`だと CA が判断した時点に置く。その二つを結ぶ記録こそ、期限を実効的な統治に変える。

LKNOG
LKNOGの2019年CFPは一つの議題枠に二つの選考列を設けていた
LKNOG3 は、締切日にかかわらず先着順で発表を選ぶと告知する一方、極めて時宜を得た内容、重要な内容、または運用上きわめて重要な内容のために、委員会が限られた数の枠を締切まで確保できるとしていた。通常枠は提出時刻、例外枠は委員会の判断によって配分される、二重の仕組みだった。

インターネット史
PaperOut の信号は変わった。それでも一枚が印刷されたとはいえない:RFC 1318
1992 年、並列プリンタの接続面に並ぶ語は、運用者にひとつの出来事を語りかけるように見えた。Power、Online、Busy、PaperOut、Fault。紙切れ、稼働、故障という語は、文書がどこまで進んだかも教えてくれるように感じられる。RFC 1318 の扱いはもっと限定的だった。この RFC は、並列プリンタに似たハードウェアの物理的な制御線を管理対象にし、ソフトウェアが検出または設定できる信号、その `none`、`on`、`off`…

ケースファイル
WHATWGは「異議なし」、W3Cは「合意なし」と判断した
金曜日までに異議がなければ5仕様、異議があれば Web Serial だけ――WHATWG の Steering Group は、新しい Peripheral APIs Workstream の発足範囲をこの条件で決めた。ところが参照先の W3C では、期限内に Intel が5 API の削除に明確な懸念を表明していた。WHATWG はその懸念を認めた上で「異議なし」の条件を満たしたと記録し、5仕様を登録した。翌週、W3C…

インターネット史
本文は「標準」と言い、記録は「情報提供」と言った――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は、現在のリンクに合うという判断と、利用期限を延ばす権限を別の取引として設計した。
