要約

  • 2026年8月17日付のdraft-ietf-procon-2418bis-04は、関心の低下などを理由に、WGがInternet-Draftを非採用状態へ戻せるとの一文を追加した。直前の-03には、この出口はなかった。
  • 現在の位置づけはWG Documentで、IESG状態はI-D Existsにすぎない。承認済みのBest Current Practiceではなく、RFC 2418をまだ置き換えていない。
  • 採用は作業の土台を選び、変更管理をWGへ移す行為である。全文への賛同やRFC化の保証ではない。したがって採用の撤回が直接決めるのは文書の管理関係であり、技術的な正誤ではない。
  • 信頼できる出口には、採用時の記録、WG管理下の最終版、再検討の理由、合意判断、移行先の状態、編集権の移転、後継文書、未解決論点、外部実装を結ぶ「処分票」が必要になる。

出口を明文化した一文

第4版の8.2節は、WGがInternet-Draftを作業項目の土台として正式に採用できるとする。その直後に、採用は文書内容の合意を意味しないと限定し、編集者にはWGの議論の結果を文書化する役割を与える。段落の末尾に新たに置かれたのが、WGはInternet-Draftを非採用状態へ戻すこともできる、という規定案である。関心が薄れた場合が例示されている。

第3版も、採用と全文同意を区別していた。しかし、非採用へ戻す文言はない。-04の変更履歴には、採用に関する文章を再び修正したと記録されている。どの版で何が加わったかは、二つの一次文書を比較して確認できる。

もっとも、今回の文章だけで完全な手続きができたわけではない。通知期間、賛否の数、異議申立て、関心低下の測り方、Datatracker上の最終ラベルはいずれも規定されていない。特定のWGが実際にこの条文を使った事例を示すものでもない。新しいのは、集団的な管理の開始だけでなく、その終了も制度上の状態として扱う視点である。

これは内部事務にとどまらない。開発者はWG文書を試作候補として追い、別の標準文書は参照関係を作り、製品担当者はdraft-ietfという名前を成熟度の手掛かりにする。管理が終わったなら、「WGが今後この文書を育てない」という事実と、「技術が否定された」「実装が消えた」という推測を切り離す必要がある。

新ルールではなく、審議中の草案

PROCONの文書一覧は、draft-ietf-procon-2418bis-04を2026年8月17日付の新しいWG Documentとして掲載している。個別のDatatrackerページによれば、目標はBest Current Practiceであり、承認された場合にはRFC 2418とRFC 3934を廃止し、複数の後続RFCを更新する。

しかし8月27日時点では、IESG状態はI-D Existsだった。document shepherdも担当Area Directorもtelechat日もない。更新や進展がなければ、2027年2月18日に期限を迎える。同じ一覧で2026bis-11はWorking Group Last Callに入っているが、2418bis-04は入っていない。隣り合う文書の状態を転用してはならない。

PROCON憲章は、既存のプロセス文書の統合に加え、WGによる草案採用の指針を非編集的に見直すことを認めている。つまり今回の論点は活動範囲内にある。ただし、憲章は個々の文言への合意ではない。

適用されるIETF手続きを経て後継文書が成立するまでは、公開済みの RFC 2418がBCP 25の基盤であり続ける。管理台帳には「現行文書」と「改訂案」を別項目として併記し、それぞれの日時と状態を示すべきだ。草案を無視することも、すでに施行済みと扱うことも、どちらも現状を損なう。

採用は管理権の移転であり、正しさの認証ではない

RFC 7221は、採用時の一般的な流れを説明する。元の文書所有者は変更管理がIETFへ移ることを確認し、chairは知的財産権の申告を確認し、rough consensusを判断し、編集者を選び、WG版の投稿を承認し、個人草案との置換関係を残す。

選択基準は、継続作業の土台として受け入れられるかどうかである。同RFCは採用を「最初であって最後ではない」「承認ではなく採用」と表現する。完成した解決策である必要はなく、RFCとしての公開も保証されない。採用後、文書はWGの管理下に入り、憲章とIETFプロセスの範囲で変更できる。明示的な合意がなければ、元の内容すべてへの同意とも見なされない。

管理の移転には実効性がある。元の著者は個人の変更をWGの結論として提示できず、編集者はWGが決めた内容を反映しなければならない。その一方で、WGはレビュー資源を使い、判断と版の履歴を維持する責任を負う。採用は永久の推薦印というより、共同の作業台に文書を載せる決定である。

非採用への復帰も、その同じ層で理解すべきだ。作業台から下ろすことで、WGとしての変更管理や今後の投資は終わり得る。しかし、採用時に存在した根拠や、途中で得た技術的知見まで否定されるわけではない。

既存の状態モデルにも脇道があった

RFC 6174は、WG文書の状態を一方向の階段として描いていない。採用提案中の状態は、まだ選択や合意が成立していないことを示す。採用されなければstream固有の状態から外れるが、採用が検討された履歴は残る。Adopted by a WGは個人草案からWG版が投稿されるまでの間を捉え、WG Documentは採用済みで活発に開発中であることを示す。

さらに、Parked WG Documentは編集者不在、別文書やレビュー待ちなどで進められない場合に使われ、再開条件を注記できる。Dead WG Documentは放棄された仕事を示すが、後に復活する可能性まで排除しない。期限前なら、必要な同意を得て別WGの非Dead状態へ移すこともできる。図に矢印がないからといって、適切な状態変更が禁止されるわけではないとも明記されている。

用語を分ける理由は明確だ。Parkedは管理を維持した一時停止、DeadはそのWGでの放棄、Expiredは保管期限の経過である。Non-adoptedは、その文書がWG作業項目の土台ではなくなったことを示す。ただし、次に誰が変更を管理するかは別途記録しなければならない。

2418bis-04の語が、Datatrackerのすべての状態とどう対応するかはまだ決まっていない。今後の版やツール設計で確認すべき点であり、今の段階で同義語を作るべきではない。

RFC 7221は出口後の可能性も示す。WGには採用した文書を保持し続ける義務がない。WGが文書を落とした場合、著作権上の制約に従い、誰でもIndividual SubmissionまたはIndependent Submissionとして追求できる。WG管理の終了は、文書そのものの消滅とは限らない。

非採用は技術的な判決ではない

関心低下には複数の中身がある。問題の優先度が下がった、編集者がいない、別案が有用な部分を吸収した、依存関係が解けない、実装者が異なる方向へ進んだ、重大な反対意見が残った、単にレビュー能力が足りない。いずれも作業配分を見直す理由になり得るが、技術的評価は同じではない。

RFC 7282が示すように、rough consensusは票数だけでは測れない。反対の理由と、それにどう応答したかが重要である。出口でも、投稿数の減少だけを自己証明にしてはならない。chairの発表には、問い、検討期間、主要な理由、合意判断が必要になる。

運用の事実も別だ。放棄された草案に基づくコードが残ることはあり、活発なWG Documentに本番実装がないこともある。文書状態が答えるのは、誰がどの権限で文章を管理するかである。導入状況は、実装報告、製品情報、運用データなど独立した証拠で判断する。

Heng Luの最小初期仕様、将来判断の局所化、自発的採用という枠組みは、この分離を考える助けになる。調整文書は共通の基準を作れても、公開だけで外部主体に実装を命じるものではない。これはIETF手続きの根拠ではなく、本稿の編集上の境界である。採用は導入命令ではなく、非採用は稼働中のシステムへの停止命令でもない。

きれいな出口が残すべきもの

最初は文書の同一性である。検討された個人草案、置き換えたdraft-ietf文書、重要な版、内容ハッシュを結び、採用提案と合意発表もリンクする。これがなければ、後続の個人版を無関係な重複と誤認したり、逆に非公式版をWGの継続版と誤認したりする。

次は出口の判断だ。誰が提案し、いつまで議論し、継続と終了の双方にどんな理由があり、何が未解決で、chairがどう合意を判断したかを残す。関心低下を理由にするなら、編集者募集、レビュー要請、後継作業など、事例に応じた観測事実が必要である。

移行先も具体的に示す。stream固有状態なし、Parked、Dead、別文書による置換、移管、期限切れ、個人草案としての継続は、それぞれ期待が異なる。WGを代表する最終版はどれか、いつ編集権が終わったか、その後の変更主体は誰かも明示する。

技術的な記録は処分記録と分離して保存する。未解決問題、セキュリティ分析、試験結果、反対理由は、別の場で再利用されるかもしれない。将来の投資をやめることと、過去の知識を消すことは同じではない。

リバージョンの処分票

最低限必要なのは、採用系列の名称・版・ハッシュ、採用提案と決定、WG管理下の最終版、退出提案と討議、chairの合意判断、移行先の正確な状態、WG編集権の終了、後継・置換・移管・個人投稿へのリンク、保存された技術課題、既知の実装・実験・参照依存、憲章やマイルストーンへの影響、そして「この変更が決めていないこと」の明記である。

入口だけを残せば、終わった制度的な権威が文書に残存する。出口で入口を削除すれば、歴史が書き換わる。二つを結ぶ記録によって、管理は可逆に、来歴は恒久的になる。

出典