要約

  • revision 03 は、IESG 承認時点では prerelease のままの規範的 YANG モジュールを、RFC Editor の限定編集、最終 revision date と YANG Semver の決定、再検証を経て、RFC と IANA からほぼ同時に公開する流れを示す。
  • suffix の除去、pyang/yanglint の成功、RFC と IANA の byte equality は別々の受領証であり、意味の不変性、版番号の正しさ、取得、ロード、互換動作、導入成功をまとめて保証しない。
  • IETF-published module と companion registry から生成される IANA-maintained module は、更新の起点も責任も異なる。

この文書自身の位置を先に固定しておく必要がある。2026 年 9 月 11 日の Datatracker では、draft-ietf-netmod-iana-yang-guidance-03 は active な NETMOD WG Internet-Draft で、WG Document、I-D Exists、Intended RFC status は Informational である。revision 03 の本文日は 2026 年 7 月 6 日、有効期限は 2027 年 1 月 7 日。Last updated の 8 月 27 日は shepherding AD と intended status のメタデータ変更であり、latest revision の日付は 7 月 6 日のままだ。RFC 化、IESG 承認、IANA 実施、製品導入のいずれも示していない。

仮の版番号が編集の余白を宣言する

提案手順では、文書が将来 IESG に承認される時点でも、規範的モジュールは major 0、または draft 番号を含む suffix などの prerelease 版を使うのが通常である。これは未完成という侮蔑ではない。RFC Editor の処理中に内容が変わり得るため、公開済み revision の不変性をまだ主張しないという宣言だ。

RFC Editor は、意味を変えない説明の明確化、draft 参照から最終 RFC 番号への置換、誤植修正、書式統一を行える。意味を変える可能性のある修正は著者との調整が必要になる。BC、NBC、editorial の区分が曖昧なら、YANG Doctors などへ判断を戻す。編集者が触れたという事実ではなく、変更の性質が権限境界を決める。

最終候補では revision date を確定し、prerelease 表示を外し、release YANG Semver を選ぶ。既刊モジュールの更新なら前版と比較し、必要に応じて rev:non-backwards-compatible を付す。その後に bytes が変われば版判断もやり直す。最終番号は、最終候補に対する責任ある分類の記録である。

ツールの無音は限定された肯定である

revision 03 は編集と整形の後に再検証し、公開時には pyang と yanglint の双方を使うことを提案する。依存モジュールも入力の一部だ。同時公開される一群を別々の都合のよい dependency set で試せば、成功しても本来の候補を検証したことにはならない。

さらに草案は限界を明記する。description の変更が単なる明確化か意味変更かはツールだけで決められないことがある。比較実装には未対応の edge case や bug があり、false positive と false negative の双方があり得る。以前の版も prerelease なら次の正式版を自動提案できない場合もある。予想外の出力は自動化を強行する理由ではなく、追加レビューの trigger だ。

したがって validation pass は、特定の tool version、flags、bytes、dependencies を受理したという証拠である。semantic equivalence や全クライアントの挙動を証明するものではない。

IANA は最終 bytes まで待つ

中心となる引き渡しは時間の制御である。IANA は RFC Editor の編集完了まで規範的モジュールを公開しない。候補が確定してから、RFC に最終内容を載せ、IANA の YANG Module Names に対応版をほぼ同時に置く。狙いは両公開面を正確に一致させ、最終 RFC への参照を正すことにある。

監査では RFC から抽出した object と IANA object、URL、取得時刻、digest、revision、Semver を保存すべきだ。hash が一致すれば出版時点の二者一致は立証できる。mutable latest URL の cache、client が得た artifact、package resolution、process load、features/deviations、YANG Library、instance migration、datastore の変化はまだ立証されない。

既存 BTW 記事は filename と loader、schema comparison、version branch、package composition をそれぞれ扱っている。本稿の対象は、それらより手前にある final editing から二つの publication surface への custody である。

IANA-maintained module は別の起点から動く

草案後半の IANA-maintained module は、RFC に載る IETF module の単なる複製ではない。companion registry の enum や identity を machine-readable に表したものだ。新しい値は先に権威ある registry に入り、IANA が delta を特定し、module へ反映し、新 revision と version を付け、BC/NBC を確認し、検証して version/date 指定の artifact を公開する。

ここで得られるのは、ある registry change が特定の module edition に反映されたという限定証拠だ。常時 freshness、全 mapping の完全性、consumer retrieval、device load は証明しない。RFC 9907 の registry authority と freshness の論点とは隣接するが、同一ではない。

最終的に必要なのは連結可能な記録

最低でも、承認された prerelease candidate、editorial diff と相談、最終版判断、validation input と環境、RFC bytes、IANA bytes と取得時刻、client cache、device load と effective schema、datastore/protocol/traffic/service observation を分けて残す必要がある。

Heng Lu の Running-Code Primacy は IETF の意図を代弁するものではなく、この記事の読み方を規律する。coordination artifact は対象を示せるが adoption を実行しない。Minimum Initial Specification は、共通手順を必要最小限かつ local verification 可能に保つ意味を示す。Reality, Not Advocacy と Reality Layers は、documentary receipt を running result に変換しない。

二つの公開コピーが一致することは大切だ。大切だからこそ、その証明範囲を越えさせてはならない。

情報源

  1. revision 03 本文
  2. Datatracker 現在記録
  3. Datatracker 履歴
  4. RFC 9907
  5. RFC 9890
  6. RFC 7950
  7. YANG Module Versioning revision 17
  8. YANG Semantic Versioning revision 26
  9. YANG Schema Comparison revision 09
  10. YANG module filename revision 14
  11. IANA YANG Parameters
  12. Heng Lu — Running-Code Primacy
  13. Heng Lu — Minimum Initial Specification
  14. Heng Lu — Reality, Not Advocacy
  15. Heng Lu — Reality Layers