要約

  • RFC 7942は、Internet-Draftに任意のImplementation Statusセクションを設け、実装主体、成熟度、対象範囲、対応する草案版、ライセンス、経験、連絡先、更新日、相互運用試験を記録できるようにした。
  • 掲載はIETFの推奨ではなく、寄稿者の情報をIETFが検証したことも意味しない。内容は時間とともに変わるため、RFC公開前にセクションとRFC 7942への参照を削除するよう求めている。
  • 実装は明確な仕様の代わりにならない。草案時の実装、試験、標準化判断、製品対応、配備、運用結果にはそれぞれ別の証拠が要る。

消えることを失敗とみなさない

Yaron ShefferとAdrian Farrelが著者となったRFC 7942は、2016年7月にBCP 205として公開された。出発点は「実装がなければRFCにできない」という一律の門ではない。文書は、実装を伴わないProposed Standardがあり得ることを認め、Implementation Statusの利用を任意とした。個々のワーキンググループは必要なら独自の条件を定められる。

ここで重要なのは強制ではなく可視化である。実装可能な仕様を扱うInternet-Draftは、Security Considerationsの直前に一時的な欄を置ける。そこで、誰が何を作り、草案のどの版に対応し、どこまで実装し、どの相手と何を試したかを審査中の資料にする。

先行するRFC 6982は、2013年にこの仕組みを18か月の実験として始めた。成功の問いも慎重だった。競合案の比較がより informed になったか。実装経験で提案が実際に修正されたか。相互運用試験が増えたか。著者以外がコードを調べたり使ったりしてレビューしたか。RFC 7942が実験文書をobsoletesしたこと自体、仮説、観測、継続判断という同じ証拠の順序を示す。

一覧ではなく、版付きの主張

RFC 7942が挙げる項目は、製品ロゴを並べるためのものではない。責任組織、実装名や公開ページ、概要、研究・prototype・productionなどの成熟度、仕様の対象範囲、対応するInternet-Draftの版、ライセンス、実装経験、連絡先、最終更新日を記録する。存在するなら試験ケースと相互運用報告も含められる。

この構造では、一語のラベルより接続関係が重要になる。productionと書いても、版と日付がなければ古さを判定できない。implementsと書いても、必須部分だけかoptional機能までか分からなければ比較できない。公開repositoryがあっても、commitと対応draftがなければ当時の状態を再現できない。二つの名称があっても、同じコードベースから派生していれば独立確認とは限らない。

文書の定型文は、この弱点を隠さない。個別実装の掲載はIETFのendorsementではない。IETFは寄稿者が提示した情報を検証していない。利用可能な実装や機能の完全なcatalogueでもない。掲載されていない実装もあり得る。WG chairとArea Directorには、この欄を特定実装のmarketingの場にしないことも求める。

早くコードを書いた組織が自案の優先を望むのは自然である。著者はmomentumを見せたい。open sourceは利用者とcontributorsを増やしたい。その動機だけで実装は無効にならないが、名前の数を証拠にする危険は増える。評価すべきなのは、所有関係、版、coverage、試験条件、失敗結果、独立性である。

RFCの寿命と実装情報の寿命

Implementation Statusを削除する理由は、情報が「necessarily time dependent」だからである。著者はRFC Editorに、公開前にセクション全体とRFC 7942への参照を外すよう依頼する。公開後のerrataで製品状態を更新する設計でもない。

もし古いprototype状態がRFCに残れば、数年後には現行の製品対応と誤読される。会社が撤退し、licenseが変わり、最終仕様に合わせた更新が行われなくても、永久文書だけが古い一覧を保持する。載っていた一社はIETFの選好を得たように見え、当時載らなかった実装は歴史から消えたように見える。

だから、削除は証拠の否定ではなく、証拠に誤った寿命を与えない処理である。公開後もstatusが必要なら、RFC 7942はWG wikiのような外部の公開場所を認める。実装者が更新でき、巨大化してもよく、RFC公開後も変えられる。役に立つためにはauthentication、registration、access controlを要求しないことが望ましい。固定すべき仕様と、更新すべき状態を別の器に入れる。

running codeは投票権ではない

RFC 3935は、IETFの標準作りをengineering judgementと、実装・配備のreal-world experienceに結び付ける。RFC 7282は、頭数やhummingを技術的異議の代わりに使うことを戒め、理論だけの判断を実際のengineeringで試す考えを説明する。Heng LuのRunning-Code Primacyも、文書の公表と運用現実を同一視せず、相互運用に必要な最小条件から共通ルールを正当化する。

RFC 7942は、その思想を狭い手続きへ落とした例である。動作するコードは、仕様を変えられる段階で発言する。しかしコードが支配するわけではない。文書は、code should never be used in lieu of a clear specificationと明記し、実装付き提案をどの程度優先すべきかも規定しない。

一つのprototypeは、一つのteamが一つの解釈を実装できたことを示せる。曖昧さや欠落を見つけ、他実装とのpacket交換を可能にする。だが存在だけでsecurity、scale、独立した実装数、運用採用、期待した成果までは証明できない。実装者は証拠の供給者であって、他の実装者やoperatorに採用を命じるprincipalではない。

公開番号の前後をつなぐレシート

監査可能な記録には、少なくとも草案名とrevision、申告者と申告日、code/release/commit/build、license、feature coverage、test case、環境、peerとその版、成功と失敗、WGの判断への使われ方、公開後の配備観測が要る。

draft-08向けコードはdraft-12の証拠ではない。一つの必須交換の成功は全optional機能の相互運用ではない。実装で文言が改善されたとしても、最終RFCを同じコードが実装したとは限らない。RFC番号は製品出荷、設定有効化、traffic、security、運用成果を証明しない。

2026年9月1日のIETF Datatrackerは、Adrian Farrelの同じ公開本人情報に82件のRFCと複数の当時の役割を結び付けていた。これは人物と長い標準化参加を確認するが、すべての申告を本人が検証したことにはならない。RFC 7942の設計はむしろ権限を分ける。implementerが申告し、authorが編集し、chairとADが宣伝化を防ぎ、WGが重みを判断し、RFC Editorが一時情報を外し、operatorが配備を決める。

公開前に消える欄は、記憶の欠落ではない。仕様へ影響を与えられる時期には実装を見せ、永久文書になった後は変化する実装事実を、日付、責任者、訂正履歴を備えた別の台帳へ移すための境界である。

出典