要約

  • draft-ietf-netmod-yang-next-agreement-00 は、次版に入れる論点、関心があれば検討する論点、次版より先へ送る論点、close 済みまたは close を提案する論点へ整理する。
  • その表は第 00 版に結び付いた分類の記録である。区分、GitHub の状態、WG Document は、最終採用、規範的意味、互換性、実装可能性、ツールの準備、運用採用までを証明しない。

バックログの整理は、しばしば設計の完成に見える。カードが「入れる」「検討」「後で」「閉じる」の四列へ移れば、未解決の問題が決定済みに見えるからだ。

第 00 版 YANG Next Agreement が行ったのは、まさにその四列を作ることだった。netmod-wg/yang-next の issue 群を WG の Internet-Draft に投影し、将来の YANG が何を解くべきかを先に議論できるようにした。これは言語機能の仕様ではない。仕様化する質問の境界を作る文書である。

文書の地位と本文の意図は別に読む

Datatracker は、同文書を NETMOD WG の active Internet-Draft、revision 00、最終更新 2026 年 6 月 23 日として示す。WG state は WG Document、IESG state は I-D Exists で、構造化された Intended RFC status は空欄だ。一方、本文ヘッダーには Intended status: Informational とあり、失効日は 2026 年 12 月 25 日である。

この二つを一つの承認表現にまとめてはならない。WG Document は議論の正式な器を示し、I-D Exists は草案が存在することを示す。ヘッダーは本文が想定する扱いを記す。どれも四区分や各 issue を IETF が承認したという意味ではない。

本文もその限界を明記している。目的は次の YANG の範囲と形について議論し、合意を見つけることだ。この文書自体を RFC として公開する目標はなく、issue 管理は GitHub dashboard へ戻る可能性がある。したがって、この草案は合意を記録した最終台帳ではなく、合意を探すための地図である。

四区分が抑えるのは機能ではなく膨張だ

草案によれば、当時の tracker には約 125 件の open issue と 35 件の closed issue があった。小さな明確化、互換性を壊す変更、プロトコル側の問題、言語を大きくする提案が同じ列に並んでいた。作業者が現れた順に採用すれば、共通目的より貢献可能性が優先される。

第一群は著者が次版へ入れるべきだと考える変更、第二群は十分な関心があれば検討する変更、第三群は次版では扱わず将来へ送る変更、第四群はこれ以上扱わない、または close を提案する変更である。

重要なのは「入れる」よりも「今は入れない」を可視化した点だ。最小の初期仕様を守るには、将来の選択を残し、実験可能な範囲を先に固定する必要がある。延期は問題の否定ではなく、意思決定を正しい時点へ置くことである。

ただし第一群も決定ではない。第 2 節は「著者が入れるべきだと考える」issue と表現し、明確化の中には審査後に変更不要と分かるものもあるとする。Appendix Issue 152 には別の分類案もある。分類そのものがレビュー対象なのだ。

closed の一語では理由が失われる

第 5 節は異なる判断を同じ closed 側に収める。GitHub で既に閉じた issue、まだ open だが著者が close を提案する issue、duplicate、YANG の誤解、有害と見なす変更、言語ではなくプロトコルで扱うべき課題である。低優先度、複雑さ、回避策も理由になり得る。

duplicate は課題が消えたことを意味しない。別の issue に統合された可能性がある。プロトコル側へ送る判断は責任の移動であり、技術的否定ではない。YANG 1.1 の互換性制約で閉じた案が、YANG 2.0 を考える状況で再検討されることもある。草案自身が、状況変化により closed issue が他のリストへ現れると説明する。

監査可能な記録には、issue 番号、時点、議論、正確な draft revision での位置、理由、後の WG 判断を結び付ける必要がある。closed だけを残せば、ワークフロー状態は残るが、技術判断は消える。

合意の証拠は別の場所にある

IETF 120 の NETMOD 議事録では、YANG Next への関心はあったものの、YANG 1.1、1.2、2.0 のどれを目指すかさえ明確ではなかった。議長は動機と目的の整理を求め、Git が WG の consensus process を置き換えないと述べた。

IETF 121 では、issue の scoring は公募された自己選択型チームの作業だった。結果は WG に戻すべきだとされ、まず高水準の方向と要約リストについて buy-in を得る案が議論された。WG 文書化は、その buy-in を求める手段であり、既に得た証明ではない。

RFC 7282 の rough consensus は投票数ではない。根拠ある異論を見つけ、理解し、対処したことを示す過程である。issue の分類に加えて、対象テキスト、異論、回答、議長による範囲付き判断が必要になる。

分類から導入までの七段階

第一は issue の同一性、提案者、例、状態、時刻。第二は第 00 版での区分、理由、代替案。第三は mailing list と会議に残る consensus evidence。第四は後続仕様の正確な規範文と依存関係である。

第五は旧・新の文法、意味、既存 module、extension、deviation、client/server を使う互換性検証。第六は独立した parser、compiler、negative test、interoperability。第七は段階導入、観測、rollback、実結果である。

第 00 版が強く提供するのは第二段階だ。そこを越える主張は、別の証拠を要求する。

YANG 2.0 草案は言語基盤、module versioning は revision と branch、schema comparison は差分分類、module filename は探索名、YANG Packages は module 集合を扱う。この四区分文書はそれらを定義せず、それらも分類の合意を証明しない。

ベンダーは「入れる」を実現性調査の開始点として読むべきだ。ツール管理者は実験 branch と corpus を作る。運用者は migration を始めず、仕様と実装の証拠を監視する。象徴層のラベルは注意を調整できるが、現実層はコードが動き、独立実装が一致し、結果を観測して戻せる時に始まる。

情報源

文書と履歴：YANG Next Agreement revision 00、Datatracker、履歴。

プロセスと技術背景：IETF 120 NETMOD 議事録、IETF 121 NETMOD 議事録、RFC 7282、RFC 7950、YANG 2.0 draft revision 00。

解釈枠組み：Minimum Initial Specification、On Reality Layers、Running Code Primary。