要約

  • RFC 9592 は、変化速度の異なる話題、参加形態、新規参加者の需要を一つの長文で追い続けられなかったため、Tao of the IETFを単独の維持文書として退役させた。
  • 焦点を絞ったウェブページや複数の媒体は更新を速くできるが、現在性、編集責任、過去版、読者が実際に見た版、運用結果は別の証拠である。

Taoは1993年のRFC 1391から始まった。その後17年間にRFC版が四つ続き、2006年のRFC 4677が最後になった。2012年のRFC 6722は、更新を容易にするためTaoをウェブページとして運用する手順を定めた。それでもRFC 9592によれば、続く11年間に公開された版は四つだけだった。

ウェブは変えやすい。しかし、全体を一つの審査単位にしたままでは、媒体だけを変えても時計は速くならない。

一冊の中に異なる更新周期を閉じ込めた

会議参加、リモート参加、Hackathon、ワーキンググループ、ツール、標準化手続は同時に古くならない。ところが一部を直すために長い全文を見直すなら、編集と承認の費用が律速段階になる。追加したHackathon情報も長文の中に埋もれ、対面中心の説明はリモート参加の比重変化を追いにくかった。

RFC 9592が示す後継像は、短いガイド、動画、ポッドキャスト、ブログ、Datatrackerなどの組合せである。現在の「Getting started」は、IETF入門、RFC、ワーキンググループ、新規作業、会議、新規参加者、メーリングリスト、録画へ読者を振り分ける。百科事典ではなく経路表だ。

この設計は一部分だけを直せる。だが、修正の来歴まで自動的に作るわけではない。

RFC 6722が明示していた証跡

旧ウェブ手順では、IESGが編集者を指名し、変更提案を専用リストで議論し、編集者が候補版をまとめ、IESGが承認した。各版には見える時刻を置き、公開済みの版を日付付きURLで保存し、改訂一覧を用意することになっていた。

これでもTaoは正式なプロセス文書ではない。RFC 9592は、共同体が作り維持した非公式の概説だと明記する。それでも旧手順は、どの版がいつ誰の管理下で公開されたかを追いやすくした。

RFC 9592は、後継のすべてのページ、動画、投稿、チャネルに同一の時刻・保存・承認制度を定めてはいない。ここから「現在のIETFに履歴やレビューがない」と推測してはならない。凍結した公開資料がそこまでの否定を支えないからだ。言えるのは、単独文書の廃止だけでは、旧来の公開証跡が全媒体へ自動継承されないということだ。

「公式」「現在」「見た版」「規範」「実行」を分ける

公式URLは現在の発行者を示す。現在のページは今の説明を示す。日付付き保存は過去の公開物を示す。読者の取得記録はその人が見た内容を示す。正式文書は手続上の地位を示す。実際の参加とシステム挙動は、説明が現実になったかを示す。

今日のページが正しくても、昨年の読者が何を見たかは証明できない。過去版を完全に保存しても、その助言が正しかったとは限らない。公式説明は組織参加を助けるが、外部ネットワークへの統治権を生まない。IETFの現行入門も、標準は自発的に採用され、IETFはインターネットを支配も巡回もしないと説明している。

必要なのは新しい巨大文書ではなく、モジュールごとの小さな来歴台帳である。資格、異議申立て、知的財産、合意、安全、重大な技術判断に関わる案内なら、所有者、範囲、根拠文書、URL、公開時刻、ハッシュまたはスナップショット、重要変更の理由、レビュー、置換対象、再点検条件を残す。

利用側も、参照したURLと版、取得時刻、説明と正式文書が衝突した場合の優先順位、解釈責任者、再確認期限を残す。そうしなければ、可変の説明が後から不変の規則として引用される。

証拠の連鎖は、需要、所有者、根拠、変更案、審査、公開、版、保存、読者の観測、ローカル判断、実行結果である。モジュール化は途中を速めるが、前後を消さない。

running codeの優先は文書否定ではない。案内の価値は、現実の参加と技術作業を改善する点にある。公式ラベル自体は結果ではない。最小初期仕様は共通部分を絞り、後のローカル判断を明示する。現実の層を分ければ、公式ページ、承認済み手続、参加者の理解、実際の成果を一つの表示に潰さずに済む。

情報源