要約

  • BBF は WT-477i2 が IETF の BGP モジュールに依存すると述べ、目標公開日の情報を求めた。これは依存と照会の記録であり、IETF の公開約束ではない。
  • IDR は8月1日、草案が Working Group Last Call にあると答え、RFC Editor の公開キュー前に Area Director 審査、IETF-wide Last Call、IESG 審査が続くと区別した。
  • 8月21日に担当 Routing Area Director は WGLC がなお継続中であり、沈黙は公開準備完了を意味しないと書いた。
  • version 21 は Internet-Draft のままで、Datatracker には WG の「Waiting for Implementation」、IESG の「I-D Exists」、telechat 日なしと表示される。
  • 必要なのは日付の推測ではなく、BBF 文書、IETF 草案、レビュー、コンセンサス、後続の決定と RFC を別々に結ぶ状態記録である。

BBF が出したのは依存関係の通知である

2025年12月の BBF のフォローアップ・リエゾン は、WT-477i2 の YANG モデルが draft-ietf-idr-bgp-model-18 に示された ietf-bgp と関連モジュールに全面的に依存すると説明する。BBF は自身の作業版を添え、文書が完成に近いことを述べ、IETF BGP モデルの目標公開日について情報を求めた。

ここで確認できるのは、どの文書がどの版を必要としているか、そして BBF が何を質問したかである。IDR が日付を受諾したこと、RFC 番号が確保されたこと、モデルや WT-477i2 が実装済みであることは、この文書からは出てこない。下流の作業にとって依存が切実であっても、上流のレビューを終える権限まで移るわけではない。

別の標準化組織との関係を可視化することは、重複や不整合を減らす上で有益である。RFC 2418 も、他組織の関連作業と適切なリエゾンを考慮するよう求める。ただし、それは他組織が IETF の審査、コンセンサス、公開を代行できるという意味ではない。

IDR は日程ではなく手続の現在地を答えた

IDR の回答 は draft-ietf-idr-bgp-model が Working Group Last Call にあるとする。その後に Area Director の review、IETF 全体の Last Call、IESG による包括的 review があり、はじめて RFC Editor の publication queue に入ると列挙する。BBF の関係者には IDR メーリングリストで技術的なフィードバック、議論、明示的な支持を示すよう勧めている。

この参加経路は重要だが、公開結果を自動的に生むものではない。コメントは技術的な問題を示し、支持はレビューの材料になりうる。それでもコンセンサスの判断、IESG の行為、RFC 公開はそれぞれ別の記録である。IDR が参加を歓迎したことを、BBF の希望日を受け入れたことに読み替えることはできない。

8月21日のアーカイブ はより明確である。v21 は出たが、文書の大きさと IETF 週、北半球の夏休みを踏まえ WGLC は開いたままだと Area Director は述べた。コンセンサスを判断する際は積極的な支持と完了したレビューを見るのであり、沈黙を公開可能という証拠にはしない。また三人の IDR Chair が共著者であるため、この WGLC のコンセンサス判断は Area Director が行い、指定された shepherd がレビューを担うことも示されている。

これは不透明さではなく、著者、レビュー、判断を混同させない設計である。版があること、リストに投稿があること、反対が見えないこと、コンセンサスがあることは、同じ状態ではない。

Internet-Draft は未来の RFC を先取りしない

version 21 の Datatracker は、2026年8月14日付の Internet-Draft と明記し、Internet-Draft は更新、置換、廃止され得る working document であり、work in progress としてのみ引用すべきだと述べる。WG の「Waiting for Implementation」、IESG の「I-D Exists」、telechat 日なしは、キュー入りや RFC 公開と同じではない。

IDR charter は IPv4 と IPv6 のインタードメイン・ルーティングで BGP を開発・維持することを最優先目標に置く。これはグループの範囲であって、個々の草案の成熟証明ではない。RFC 2026 は標準化の成熟段階を示し、Proposed Standard への移行には IESG の具体的行為が必要だとする。経験によってその後の変更や撤回もあり得る。

したがって、公開の説明には少なくとも、BBF 文書と参照版、WGLC の開始・継続・終了、レビューとコンセンサスの処分、Area Director/IETF/IESG の後続状態、RFC Editor のキュー、最終 RFC という別々の欄が必要になる。どれか一つが他の欄を証明することはない。最終 RFC も、BBF 文書の出荷、ベンダー対応、運用ネットワークの利用を単独で立証しない。

状態を借用しないための小さな記録

公開の受領書には WT-477i2 の版、参照 IETF 草案の版、照会日と内容、WGLC 状態、完了したレビューとコンセンサス処分、後続の IETF/IESG 状態、キュー、RFC を結べばよい。各行には否定の範囲も必要である。依存は約束ではない。開いた WGLC は拒絶でも日付予測でもない。キューは公開でなく、RFC は導入証拠でない。

ここで使った資料は、相互運用試験、運用者の採用、ベンダーの対応、商業的影響、遅延の原因、対立や拒否権を示さない。示すのはより限定された事実、すなわち、当該レビューが継続中で、BBF が求めた日付が標準化判断として記録されていないことである。

情報源