要約

  • 現行のIETFリポジトリでは、正式な処理状態が期限切れを止めない限り、Internet-Draftは通常、掲載から185日でExpiredになる。これは活性版の寿命を示す表示であり、提案を退けた機関を示すものではない。
  • 活性版を置くRepositoryと履歴を残すArchiveは別の記録である。更新、別文書による置換、RFC化、期限切れのいずれでも版はRepositoryを離れるが、各版は原則としてArchiveに残る。
  • 公式履歴は差を可視化する。draft-iab-protocol-maintenance-05は期限切れ後に改訂され、最終的にRFC 9413となった。draft-ietf-netvc-testingも何度も期限切れになったが、意味のある終結は理由を伴う別個のIESG Dead状態だった。
  • 調査台帳には草案状態のレシートが必要である。正確な版、掲載日と期限日、保存先と置換関係、WGや文書ストリームの状態、採用・Last Call・処分の証拠、実装依存、結論の責任者を分けて残すべきだ。

時計を処分に変えた台帳

ある調達部門が、新しいプロトコル機能を評価しているとする。担当者はIETF Datatrackerで最新草案がExpiredになっているのを見て、リスク台帳に「IETF却下」と入力する。製品責任者はロードマップから機能を外し、監査人も同じ判定を報告書へ転記する。数か月後に新しい版が出ると、今度は「IETFが再承認」と書き換える。

二つの結論はどちらも証拠を越えている。最初は自動的な日付を組織判断にし、次は新しいファイルを承認にした。期限切れと改訂という観測は正しい。IETFが否定し、その後肯定したという帰属だけが作られている。

却下には主語が要る。WGが採用しなかったのか。チェアがrough consensusなしと判断したのか。Area Directorが支援しなかったのか。IESGが出版要求をDeadにしたのか。著者が単に改訂しなかったのか。別名の草案に置換されたのか。議論は続いていたが、文書だけが自動時計をまたいだのか。

Expiredという一語は、どの問いにも単独では答えない。分かるのはライフサイクル上の条件が成立したことだけである。ガバナンス記録は、機関が実際に何を決めたのかを示す別の出来事を探し、権限、対象版、日時、理由とともに保存しなければならない。

Repository、Archive、185日の出来事

現在のIETF Author Resourcesは、Internet-Draft RepositoryとInternet-Draft Archiveを区別している。Repositoryにあるのは活性版である。新しい版への更新、別草案による置換、RFC出版、または期限切れが起きると、その版は活性でなくなる。Archiveは例外的な削除を除き、すべての版と追加の表示形式を保持する。

現行運用では、草案はRepositoryに置かれてから通常185日で期限切れになる。ただし正式な出版処理中など、期限切れを防ぐ状態がある。IETFストリームでIESGが出版処理をしている場合や、Independent Submission StreamでIndependent Series Editorが審査している場合が例である。つまり時計でさえ、手続状態から完全に独立した断頭台ではない。

一方、Archiveに残ることはRFCのような公刊物になったことを意味しない。同じ案内は、Internet-Draftがarchival seriesではなく、あくまでwork in progressとして扱われるべきだと注意する。保存が証明するのは「その版が存在した」ことであり、「IETFが承認した」ことではない。

RFC 2026の2.2節を読むと、制度の時間差も見える。1996年のBCP 9は、Internet-Draftsディレクトリを発展途中の文書を広く非公式レビューにさらす場と説明した。六か月を超えて変更されず、IESGからRFC出版を勧告されなければ削除され、新版が出れば時計は再始動する。文書には正式な地位がなく、変更・削除され得るとも明記した。

現在は185日という具体的な期間と、履歴を保持するArchiveがある。ツールは変わった。しかし境界は逆転していない。草案はRFCではなく、リポジトリの時間切れは権限ある主体の処分ではない。

一つの表示に押し込めない四層

最低でも四種類の状態を分ける必要がある。

第一は文書の同一性である。draft-example-foo-04は「Fooという考え」の別名ではない。掲載日、本文のバイト列、参照、具体的な機構を持つ一版である。05版が安全条件を直し、範囲を狭め、互換性を変えるかもしれない。版番号を落とした調査は、どの主張を読んだのか証明できない。

第二はリポジトリのライフサイクルである。active、updated、replaced、published、expiredは、その版が現在のコピーか、なぜ現在の表示から外れたかを示す。閲覧支援には有用だが、技術的価値やコンセンサスを単独で表さない。

第三は手続状態である。個人提出、WG採用候補、採用済みWG文書、WG Last Call、IESG評価中の出版要求は、それぞれ権限関係が違う。RFC 2418の7.2節はInternet-Draftsを進行中の文書の場として扱い、7.4節はWG Last Callを別の行為として定める。7.5節では、文書を進めるrough consensusとIESGへの提出がさらに分かれている。

第四が処分である。権限を持つ主体が採用、置換、撤回、支援拒否、承認、出版、終結を記録し、場合によっては理由や異議申立て経路を残す。否定的な判断を探す場所はここであって、ライフサイクル層から作ってはならない。

各層は別々に動く。WGが改訂を続ける文書も期限切れになる。活性な個人草案にスポンサーがいないこともある。実装済みの案が出版段階で終わることもある。期限切れ版の後に同じ名称の新版が出ることもある。一色のバッジでは、この組合せを正直に表せない。

期限切れ後にRFC 9413となった草案

Maintaining Robust Protocolsの公式履歴は、「期限切れは却下」の明快な反例である。05版は2021年7月12日に掲載され、2022年1月13日にシステムが期限切れを記録した。06版は同年5月10日に現れ、07版から12版まで改訂が続いた。IABはCommunity Review、IAB Reviewへ進め、コンセンサスと承認を記録し、2023年2月にRFC Editorへ送った。

最終成果は2023年6月にRFC 9413として出版された。05版の期限切れは消すべきでない真実である。それをIABまたはIETFの却下と呼ぶことが誤りなのだ。時計は後の改訂も審査も出版も禁止していない。

この事例から、期限切れ文書の大半が復活するとは言えない。言えるのはもっと狭く重要なことだけだ。期限切れと却下は論理的に同一ではない。最初に「却下」、最後に「承認」と一セルを書き換えるしかない台帳は、途中のガバナンスを捨てている。

良い記録はすべてを併存させる。2022年1月13日に05版が自動期限切れで活性状態を離れ、5月10日に06版が掲載された。その後のイベントは審査主体と判断を個別に示し、RFC 9413が最終的な公刊結果を示す。それぞれに日時と主語がある。

本当の終結には名前と理由があった

Video Codec Testing and Quality Measurementの履歴は反対側を示す。05版は2017年9月に期限切れとなり、翌月に06版が出た。06版は2018年5月に期限切れとなり、07版が7月に出てWG Last Callへ進んだ。07版は、WG状態が「コンセンサスあり、write-up待ち」だった2019年1月にも期限切れになった。その後08版が出版手続とIETF Last Callに入った。

意味のある否定的記録はもっと後である。2020年3月25日、IESG状態がDeadに変わった。Area Directorの注記は、IESG評価上のコメントへ対応させる試みを重ねたものの、NETVC WGには文書を完成させる十分な勢いがないと結論した、と理由を示す。自動期限切れは同年8月にも別に記録された。

ここでは引用できる終結がある。日付、手続主体、理由がそろっている。理由は勢いと未解決コメントであって、試験方法に技術的価値がないという判決ではない。shepherdの記録は、その方法がAV1実装者に既に使われていたとも述べた。実装上の利用、出版上の処分、リポジトリの期限は三つの事実だった。

最後の期限切れだけを「却下」と書けば、最良の証拠であるIESG状態変更と説明を隠してしまう。初期の期限切れを却下と書けば、その後も作業が続いた履歴と矛盾する。

再掲載も承認ではない

境界は左右対称である。期限切れが却下を証明しないのと同じく、新版は承認を証明しない。要件を満たす人はInternet-Draftを提出できる。改訂はコメントへの応答、可視性の回復、議論の再開、あるいは著者が継続の選択肢を残す行為かもしれない。正式な地位はなお手続記録に依存する。

ファイル名にも同じ注意が要る。draft-ietf-...は通常WG採用を反映するが、正確なWG状態と履歴を確認すべきである。名前だけでは各文章への現在のrough consensusも、IESG承認も証明しない。Last Callは所定のレビューを開く行為であって、最終出版ではない。

running codeも組織上の地位を代作しない。実装は相互運用性、運用価値、移行費用を判断する重要な証拠である。Heng LuのRunning-Code Primacyは紙面だけの権威を抑える規律を示す。しかし実装は稼働実態の証拠であって、コンセンサスの偽造票ではない。コードと手続を別々に残し、互いに検証させるべきだ。

外部の採用者にも責任がある。RFC出版前に必要な機能を得るため、調達者が特定の草案版を契約で固定することはあり得る。その義務を作るのは契約であり、リポジトリのバッジではない。契約には版、変更受入れ、互換試験、退出条件が必要になる。

期限廃止を唱える文書も草案である

個人草案Removing Expiration Notices from Internet-Draftsは、草案がArchiveに残る現在、自動期限切れの効用は失われたと論じた。期限切れ草案も引用され、一部システムは単に表示や検索を変えるだけだと指摘する。経験ある参加者が制度の意味について異なる見方を持つ証拠として価値がある。

同時に、この文書の最新版も期限切れのInternet-Draftである。その皮肉を嘲笑にも権威にも変えてはいけない。提案は現行規則として採用されていない。論拠を評価することと、文書の存在を「IETFが期限を廃止した」と引用することは別である。

ここに全文の規律が凝縮される。強い議論を含む草案でも正式地位はない。正しい手続表示でも技術的価値を決定しない。権限ある主体が追跡可能な記録で両者を結んだときだけ、制度上の判断になる。

草案状態のレシート

標準調査の台帳は、当時その場にいなかった人が結論を再構成できるだけの要素を持つべきである。

項目 証明するもの
正確な名称と版 浮動する案ではなく、評価した具体的テキスト
内容フィンガープリント 読んだバイト列と保存版が一致するか
掲載日と期限日 時計イベントと適用された規則
Repository状態 活性か、何が理由で活性状態を離れたか
Archiveの所在 履歴テキストと表示形式の保存場所
改訂系列 前後の版を結びつつ、同一視を避ける
置換関係 別の草案名が仕事を継承・代替したか
ストリーム、スポンサー、WG 次の手続に責任を持つ機関があるか
採用状態 WGが作業項目としたか、その根拠は何か
コンセンサスとLast Call どの版を誰がレビューし、何が未解決か
IESG等の処分 実際の判断、主体、日付、状態、理由
出版結果 RFCになった場合の番号、ストリーム、カテゴリー
実装依存 状態変更後も残るコード、試験、導入、外部参照
外部採用文書 どの契約・方針がどの版を選び、更新をどう扱うか
責任者と次回レビュー 草案、手続、導入が変わったとき誰が直すか

このレシートは二つの反対の誤りを止める。Active、adopted、Last Callを「IETF承認」にするのは権威の膨張である。Expiredを「IETF却下」にするのは権威の捏造である。前者には肯定的行為、後者には否定的行為の証拠が必要で、時計だけではどちらも得られない。

出典

結論

Expiredは有用な警告である。活性版が鮮度の境界を越え、依存を見直す時期だと教える。なぜ仕事が止まったか、技術判断があったか、機関が何かを決めたかまでは教えない。

運用原則は単純でよい。期限切れを時計のレシート、処分を権限のレシートとして両方残す。提案が閉じられたなら、主体、手続、版、日付、理由を記す。新版が出たなら、承認を作らず新版を記す。実装者や調達者が依存を続けるなら、その選択を自身の権限で記す。暦は文書を古くできるが、機関の票を投じることはできない。