要約

  • draft-ietf-procon-2026bis-11は2026年7月1日に公開され、8月27日時点ではWorking Group Last Callの最中にある。RFC 2026のvariance手続を引き継ぐ統合案だが、BCP 9を置き換える承認済み文書ではない。
  • 特定の仕様が手続上の行き詰まりに直面した場合、または手続に指針がない場合、担当ワーキンググループが例外を勧告できる。担当WGがなければアドホック委員会が担う。勧告は検討の開始であって承認ではない。
  • IESGは技術的価値、通常経路、代替策、不遵守の費用、波及効果と先例効果、範囲の狭さを検討する。提案は別個のInternet-Draftとして示され、最低4週間の延長Last Call、決定の公表、承認時のBCP刊行を経る。異議申立ても残る。
  • 明記された期間、公開性、公平性、コンセンサス、記録保存、中心的な審査機構は免除できない。したがってvarianceは一仕様に添付する版管理済みの例外票であり、既定規則、将来案件、運用者の導入判断を書き換えない。

適用除外票を既定値にしない

例外が必要になること自体は、手続の失敗を意味しない。一般規則が想定できなかった案件を、理由を示して扱うための仕組みがなければ、制度は硬直する。問題は、例外の結果だけが残り、例外だったという性質が消えるときに起きる。

ある仕様が一つの要件を満たせないとする。担当WGが勧告し、IESGが代替策や費用を検討し、公開審査の後に限定的なvarianceを承認した。ここで管理表が保存する値を「要件なし」としてしまえば、次の仕様にも同じ値が適用される。次の案件には勧告も理由もLast Callもないのに、前件の結論だけが移植される。

人間の説明でも同じことが起こる。「以前にも認められた」が「IETFの慣行」になり、やがて「この要件は任意だ」と短縮される。条件や異議、対象版を落とした要約は、記憶の効率を上げる代わりに権限を膨らませる。

台帳は二つの対象を分けなければならない。一つは版と発効根拠を持つ再利用可能な規則。もう一つは対象仕様、対象版、該当条項、理由、制限、決定連鎖を持つvarianceである。過去の例外は、RFC 2026が求める先例効果の分析には使える。しかし、それ自体が次の案件を処理する規則にはならない。

この分離は裁量を弱めるのではない。裁量が誰の判断で、どの範囲に、いつまで働くかを見えるようにする。出口のない規則と、出口がすべてを上書きする規則の間に、監査可能な柔軟性をつくる。

2026bisの状態を飛び越えない

Datatrackerの文書ページによれば、draft-ietf-procon-2026bis-11はPROCON WGの現行Internet-Draftである。ただし、そのページのIntended RFC status欄はNoneと表示し、草案本文のヘッダーは意図するRFC statusとしてBest Current Practiceを掲げる。この二つを、既に確定した状態決定としてまとめてはならない。-11は2026年7月1日に投稿され、更新または前進がなければ2027年1月2日に失効する。履歴には、-08だった5月21日にWG DocumentからIn WG Last Callへ移ったことが記録されている。

8月27日時点でもWG状態はIn WG Last Call、IESG状態はI-D Existsで、telechatの日付はない。これはWGが統合案を本格的に審査している証拠である。IESG承認、RFC刊行、BCPの置換を示す証拠ではない。

承認されれば、この文書はRFC 2026を含む複数の手続RFCを廃止・統合し、RFC 7475を更新する予定である。PROCONのcharterは、RFC 2026とRFC 2418が二十件を超えるRFCによって更新され、規則が分散したことを背景に挙げる。WGはそれらと確認済みerrataを統合する。追加の非編集的変更として明記された範囲は二領域で、それ以外を扱うにはrecharterが必要だ。

第11節はvarianceの構造を残している。ただし、これは2026年に新設された権限ではない。現行の公刊根拠であるRFC 2026は、1996年の第9節ですでに同じ骨格を定めている。統合案は用語と章番号を整えるが、変更履歴はvarianceを新政策として提示していない。

したがって、政策レジストリーには三つの状態が同時に必要になる。現在有効な公刊基準としてのRFC 2026、審査中の統合案としての2026bis-11、将来承認・刊行された場合の後継RFCである。草案を現行規則として扱うことは、この記事が警告するのと同じ誤り、すなわち限定された手続対象を完成済みの一般権限へ変えることになる。

勧告と決定を同じ印にしない

varianceの起点は担当WGである。WGが存在しなければ、アドホック委員会が勧告できる。技術と経緯を知る主体が、なぜ通常手続では扱えないかを説明する。一方、その主体だけで例外を確定することはできない。

IESGは、要件不遵守の費用よりインターネット共同体への利益が大きいと判断しなければならない。検討項目は、仕様の技術的価値、varianceを使わずに標準化手続の目的を達成できるか、他の選択肢、付随的影響、先例効果、そして例外を可能な限り狭くできるかである。

技術的に優れているという評価だけでは足りない。通常経路が使えない理由にはならないからだ。期限が迫っていることだけでも足りない。時間短縮の外部費用が隠れているかもしれない。過去に似た例があることも、今回の対象、条項、反対意見を自動的に処理しない。

IESGはvarianceを特定の規定に限り、追加制約を課すこともできる。一項目を外す決定は、手続全体の停止ではない。承認に近づくほど適用範囲が具体化し、境界条件が増えるのが健全な姿である。

公開記録が権限の鎖をつくる

variance案は、認識された問題、支障となる正確な規定、IESGの検討内容を示し、Internet-Draftとして発行されなければならない。その後IESGは、最低4週間の延長Last Callを行う。終了後に最終判断を下してIETFへ公表し、承認したvarianceはBCPとして刊行に送る。異議申立ての手続も適用される。

各段階の証明力は異なる。WG勧告は、責任主体が検討を求めたことを示す。Internet-Draftは、何がどの版で提案されたかを固定する。Last Callは公開審査の最低期間を示すが、沈黙を同意へ変えない。IESG発表は判断主体と結論を示す。BCP刊行は承認結果を安定させる。appealがあれば、その争点と処分が別に残る。

RFC 7282が述べるrough consensusは、人数の集計だけではない。異議の内容と、その異議がどう扱われたかが重要である。多数の短い賛成が一件の重大な構造的異議への回答を代替するわけではない。逆に、異議が存在するだけで自動的に否決になるわけでもない。記録すべきなのは論点と処分である。

最低4週間という摩擦は意図的だ。例外が通常経路より手軽なら、やがて第二の通常経路になる。公開時間と文書化の負担は、例外を必要な案件に限定し、範囲を縮小する方向へ関係者を促す。

免除できない手続の床

RFC 2026はvarianceの限界を列挙している。明示された待機期間を短縮できない。公開性、公平性、コンセンサスから免除できない。会議とメーリングリスト議論の適切な記録を外せない。さらに、BCP審査、手続開始、IESG審査、刊行、対立処理、appeal、variance自身を支える指定部分も保護される。2026bis-11は章番号を変えながら同じ床を維持する。

例外が自分を監査する仕組みまで免除できれば、最も慎重な検証が必要な場面で証拠が消える。名称だけは正式なvarianceでも、外から見れば非公開の裁量と区別できなくなる。

延長Last Callも単なる待ち時間ではない。WG外の参加者が、対象条項、代替策、波及効果、制限を調べる最低機会である。「急ぐから審査時間を外す」という論理を認めれば、急ぐという主張が、その妥当性を審査させない権限になってしまう。

この床は全員の納得を保証しない。IESGの判断を機械的な式にもしない。保証するのは、判断が可視で帰属可能であり、記録と申立ての経路を例外自身が消せないという点である。

例外票に残すべき項目

最初に必要なのは同一性である。varianceの識別子と版、対象仕様の名称・改訂・内容ハッシュ、担当WGまたはアドホック委員会、勧告と日付、免除対象のBCP規定を結び付ける。次に、行き詰まりまたは指針欠如、満たせない要件、通常経路が機能しない理由を記す。

判断部分には、技術的価値、利益と費用、検討して退けた代替策、波及効果と先例効果、正確な範囲、追加制約を残す。公開部分にはvariance Internet-Draftとハッシュ、Last Callの開始・終了日時、重要な異議とその処分を置く。

最後にIESGの決定と発表、承認時のBCP識別子、appealの状態と判断、一回限りの境界、終了条件を記録する。そして「後続仕様を承認しない」「外部導入を命じない」という二つの非主張を明示する。

承認されたvarianceがBCPとして刊行される点は、一般規則への昇格を意味しない。BCPという形式は決定を公開し、安定して引用可能にする。内容の射程は対象案件のままである。恒久的に再利用できる手続を変えるなら、通常の公開BCP改訂を通る必要がある。

標準化手続と導入判断の境界

IETF内部のvarianceは、特定仕様が標準化トラックへ入る、または進む際の手続状態を扱う。企業、通信事業者、政府、実装プロジェクトに採用を命令するものではない。

RFC 9281はWG、IESGその他の主体の役割を整理している。それぞれの権限は帰属可能であり、例外によって外部主体が文書状態を変更できるわけではない。RFC 3935は、IETF標準が準拠を主張するときの方法を記述する一方、利用を強制・監督するものではないと説明する。

運用採用には別の受領記録が要る。誰が、どの版を、どの検証結果に基づき、どの範囲で、いつ導入し、どの条件で戻すのか。varianceは検討材料にはなっても、その決定を代行しない。内部手続の出口を外部命令へ言い換えると、存在しない権限が流通する。

Heng Luの最小初期仕様、局所化された将来判断、自発的採用という枠組みも、共同決定の範囲と後続主体の判断を分ける。ここではIETFの手続資料を置き換える根拠ではなく、権限境界を読むための編集上の視点として用いる。

情報源