要約

  • 9月29日付の draft-gerke-publication-process-reform-09 は、承認された場合に更新する文書として従来のRFC 7841にRFC 6359を加えた。個人提出のInternet-Draftであり、IESGでの状態は I-D Exists。現行RFCを変更したわけではない。
  • 二段階の技術・編集上の凍結案は第08版にもあった。第09版で新しいのは、Datatrackerによる状態追跡を説明したRFC 6359に、自動的な整合性検証と編集制限の構想を明示的に接続した点だ。

改訂の意味は、表紙の Updates 欄から読み取れる。9月22日の第08版が挙げたのは、RFCの発行系列やヘッダー表示を扱うRFC 7841だけだった。第09版は、承認後のIANAとRFC Editorの作業をDatatrackerで追跡する仕組みを扱うRFC 6359も挙げる。出版物の表示を論じる提案が、状態を映す基盤にまで適用範囲を広げた格好だ。

追加された第1.2節は、RFC 6359の追跡経路を、提案する状態整合性チェックと書き込み制限の足場として位置付ける。要旨にも、既存および将来の主要な処理系列に自動的な節目を横断適用する趣旨が加わった。ただし、これは提案者が望む設計である。実際にDatatrackerが権限を制限し始めたという報告ではない。

新旧の差分を丁寧に分ける必要がある。第08版の時点で、技術的な変更を先に、編集上の変更を後に凍結する二段階案や、IESG OK 後のIESGの書き込み権限、RFC制作側の編集段階に関する案は既にあった。第09版が初めて凍結を発明したわけではない。また第09版は draft-ietf-procon-2026bis-11 を参考資料から規範的参照文献へ移したが、参照先も作業部会の最終意見募集段階にある草案で、RFCではない。

比較対象となるRFC 6359は、複数の作業状況を一元的に見られるようにすることを目的とした。一方で、各組織の実際の手続きを定義しないと明記している。承認後のIANAの状況についてはIANA側の追跡システム、RFC Editorの状況については常にRFC Editor側のシステムが正式な記録となる。Datatrackerはその状態を反映する。共同の表示面と共同の停止権限は同義ではない。

この区別は、将来の自動検証を否定するものではない。問うべきは、系列ごとに誰が停止条件を認めるか、技術的修正と編集上の修正を誰が判定するか、誤ったロックや例外をどう審査するかだ。草案の表紙にRFC番号を増やしても、その答えや関係者の同意まで得られるわけではない。目標とするBest Current Practiceも、現在の承認状態ではない。

出典