要約

  • RFC Seriesは一つの恒久アーカイブだが、入口はIETF、IAB、IRTF、Independent Submissionの四つに分かれる。同じ連番は、同じ機関が承認したことを意味しない。
  • ストリームは由来と刊行手続きを示し、カテゴリーは文書の種類や初期状態を示す。Standards TrackとBCPを出せるのはIETFストリームだけだが、IETFストリームのRFCがすべてInternet Standardになるわけではない。
  • IRTF文書や独立投稿に対するIESGの審査は、IETFの標準化作業との衝突を確認するためのものだ。「衝突なし」は技術的推奨、安全性認証、導入適格性を意味しない。
  • 調達、監査、設計、政策でRFCを要件化するなら、ストリーム、カテゴリー、刊行承認者、審査の射程、現行状態、文書の継承関係、適用範囲、実装証拠、採用決定者を記録すべきである。

稟議書から消えた来歴

ある調達仕様書に四つのRFC番号が並んでいる。一つはIETFストリームのStandards Track文書、一つはIABの見解、一つはIRTF研究グループの成果、もう一つは独立投稿として採択された文書だ。ところが欄名はすべて「IETF標準」になっている。

番号自体は正しい。どの番号からも、編集され保存された一意の文書にたどり着ける。誤っているのは、番号に付加された制度上の意味である。

図書館の請求記号は、本の置き場所を確定する。著者、査読者、出版判断を一人にまとめるものではない。RFC番号も同じで、文書の恒久的な住所ではあっても、誰が何を審査したかを圧縮した証明書ではない。

RFCが共通の体裁を持ち、同じ場所から取得できることは大きな価値である。だからこそ、表紙の統一感に審査主体の違いを埋没させてはならない。

一つの書庫に四つの入口

RFC 8729によれば、RFC Seriesはインターネットの技術仕様を記録するアーカイブである。標準文書だけでなく、研究・技術コミュニティーからの幅広い貢献も収める。IETF文書は大きな部分を占めるが、全体ではない。

現在の入口は四つある。IETFストリームには、ワーキンググループ文書と、IESGのエリアディレクターがスポンサーとなる一部の個人提案が入る。IABストリームはInternet Architecture Board自身の手続きで承認する。IRTFストリームでは研究グループの成果をIRSGが審査する。独立投稿ストリームは、その三つの範囲外にある技術文書の道を確保する。

RFC Editorは、これらを共通の編集規則で刊行し、索引し、保存する。共通の管理は検索性と記憶を生むが、刊行前の判断主体を変更しない。IRSGの判断がIESGの判断になることも、IAB文書がIETFワーキンググループ成果になることもない。

異なる入口を残すことには意味がある。標準、研究、アーキテクチャ上の見解、特定ベンダーの方式、反論、歴史資料を、無理に同じ権威へ変換せず保管できるからだ。

ストリームとカテゴリーを重ねない

IETFストリームだと分かっても、まだInternet Standardとは限らない。RFC 7841が示すカテゴリーには、Standards Track、Best Current Practice、Experimental、Informational、Historicがある。

Standards TrackまたはBCPを承認できるのはIETFストリームだけである。しかしIETFストリームは、情報提供、実験、歴史のカテゴリーも刊行する。したがって「IESGが刊行を承認した」と「Internet Standard候補である」は同義ではない。

ストリームは、どの共同体がどの手続きで文書を刊行したかを示す。カテゴリーは、どの種類・状態で刊行されたかを示す。特定のシステムに適用できるかは、さらに版、選択機能、現在の状態、実装、相互運用性、運用上の制約を見なければ判断できない。

Status of This Memoは読み飛ばすための定型文ではない。ストリーム固有の位置づけと、受けた審査の性質を読者に知らせる欄だ。ここを省く引用は、裁判所名と手続きの段階を伏せて判決だけ持ち出すのに似ている。

「承認した」の主語を確かめる

IABストリームの文書は、IABのコンセンサスを表し、恒久記録に値するアーキテクチャ上の見解を示すことがある。その判断には重みがある。ただし主語はIABであって、IETF全体でも、インターネット利用者全体でもない。

IRTFストリームでは、支持の程度を意図的に細かく残す。RFC 5743は、研究グループがコンセンサスを得たのか、限定的な意見なのか、論争はあるが刊行価値について合意したのかを説明するよう求める。どれほど広く読まれたかも明記する。

IRSGは編集委員会に近い役割を担い、技術的な明瞭さ、文章の質、研究グループ内で必要な審査が行われたかを確認する。文書はIETFの成果物ではなく、標準でもないことを明確にする必要がある。

これは価値を下げる表示ではない。研究は、標準化の結論が出る前にも、そもそも標準化を目指さない場合にも必要だ。支持と審査の範囲を正確に書くからこそ、読者は肩書ではなく中身を評価できる。

独立投稿も無審査の掲示板ではない。RFC 4846は、その系譜がIETFより古いことを説明し、IETFの議題外の技術、学術と実装の橋渡し、ベンダー固有のプロトコル、標準案への批判、歴史資料などの役割を挙げる。同文書が記す旧手続きではRFC Editorがレビューを集める。RFC 8729が参照する現行モデルでは、独立ストリームへの適合性を判断するのはIndependent Submission Editorであり、共通のRFC Editorによる刊行がその判断をIETFの決定に変えるわけではない。

「独立」は刊行経路の独立性を指すのであって、評価の欠如を指すのではない。

衝突確認が推奨に化けるまで

IRTF文書と独立投稿はIESGにも送られる。社内メモに「IESGレビュー済み」と書かれ、次の資料で「IESG確認済み」となり、最後には「IETF承認済み」へ変わる。この言い換えで、審査の問いそのものが消える。

RFC 5742が定めるのは、IETFの標準化作業との衝突確認である。既存または予定された作業を妨げないか、両者の関係を説明する注記が必要かをIESGが見る。

衝突が見つからなければ、独立投稿の技術的価値はIndependent Submission Editorが判断し、IRTF文書の技術的価値はIRSGが判断する。IESGが二つのストリームの実質審査を引き取るわけではない。

「衝突なし」は狭いが重要な結論である。標準化作業との境界を保ち、別の入口からの出版を可能にする。しかし設計への賛同、包括的なセキュリティー審査、特定環境での稼働保証を意味しない。

逆に、IETF外のストリームだから品質が低いと決めつけるのも誤りだ。来歴は序列ではない。どの判断を誰に帰属させるかを正すための情報である。

番号が実際に保証するもの

RFC番号は単なる飾りではない。編集され、索引され、恒久保存されるシリーズに文書が収録されたことを示す。著者、日付、ストリーム、初期カテゴリーを確認でき、現在の記録から正誤情報、更新、廃止、状態変更を追える。

この安定性が技術史を支える。古い実装が当時どの記述を参照したのか、ある論争で何が主張されたのかを、後から同じ本文で検証できる。少数意見や独立の批判も、標準に昇格しなくても消えない。

一方、本文を固定するからこそ、現在の状態は外部記録で確かめる必要がある。刊行後にHistoricへ移っても、古い文書の定型文は書き換わらない。更新や後継RFC、正誤情報と併せて読まなければならない。

刊行は実装の証拠でもない。Standards Trackの要件がある製品で動いていないこともあれば、Informational文書が広く使われる実態を正確に記すこともある。動作を証明するのは、コード、設定、相互運用試験、観測データである。

引用の連鎖で増幅される借り物の権威

番号だけの引用は流通しやすい。調達担当者が仕様に入れ、監査担当者が二択の統制項目へ変え、行政機関がその統制を指針に引用し、ベンダーが試験条件を示さず「RFC準拠」と宣伝する。

転記のたびに権威らしさが増え、範囲は失われる。研究文書が入札の足切り条件になり、実験的方式が確立した慣行として扱われ、衝突確認がセキュリティー認証へ置き換わる。文書を採用した当事者は番号の陰に隠れる。

代表性も同じように膨らむ。技術作業への開かれた参加は重要だが、参加者を全利用者の政治的代理人にするものではない。rough consensusは相互運用可能な仕様を作るための工学的規律であって、世界規模の委任投票ではない。

調達者や規制者がRFCを採用すること自体はあり得る。その場合は自らの目的と権限を明記すべきで、番号に存在しない委任を代筆させてはならない。

引用に刊行証明を添える

実務では、短い確認票で十分である。

まず文書を特定する。番号、タイトル、日付、依拠する節を記す。次にストリーム、刊行承認者、支持やコンセンサスの記述を記す。カテゴリーとStatus of This Memoに示された審査範囲を加える。IRTFまたは独立投稿なら、IESGの衝突確認と各ストリームの価値判断を別項目にする。

続いて現行性を確認する。現在の状態、正誤情報、更新・後継文書を調べる。適用範囲として版、環境、オプション、例外を限定する。実装証拠として製品、設定、試験、観測、既知の限界を添える。

最後に採用主体を明記する。運用者の判断なのか、契約条項、内部方針、法令なのか。文書をこの場の要件に変えた主体が、自分の決定を引き受ける必要がある。

番号を引用する前にストリームを読む

RFC Seriesは、一つの議会というより、四つの入庫手続きを持つ技術書庫である。共通番号は知識を守り、ストリーム表示は責任を守る。

引用を見たら五つ問えばよい。どのストリームか。どのカテゴリーか。誰が何のために刊行を承認したか。実際の審査範囲はどこまでか。現在この文書を適用すると決めたのは誰か。

答えがなければ、番号が組織になりすましている。来歴を戻せば、番号は本来の役割を取り戻す。すなわち、証拠への正確な住所であり、偽造された委任状ではない。

Sources