要約

  • RFC 9907では、IANA管理YANGモジュールは対応レジストリの表現形式であり、レジストリそのものが唯一の権威であり続ける。
  • 検証ツールは古いバイト列を正しく合格させ得る。レジストリ時点、モジュール版とハッシュ、検証条件、サーバーのYANG Library、実操作、観測結果を別々に証明する必要がある。

CIは成功していた。モジュールは読み込まれ、importは解決し、IETF向け検査にも重大な警告はなかった。ところが、配備判断に使った値は対応するIANAレジストリですでに更新されていた。検証器が誤ったのではない。構文検査に鮮度証明まで背負わせた側が、問いを取り違えたのである。

2026年3月の RFC 9907 はBCP 216で、RFC 8407を廃止し、RFC 8126を更新した。RFC Editorの記録はその位置付けを確定している。対象はYANGデータモデルを含む文書の執筆・レビュー指針であり、機器を遠隔変更する新プロトコルではない。

IANA管理モジュールについての規律は明快だ。IANAレジストリをYANGやMIBで表しても、それは別レジストリにならない。新しい値は対応レジストリに登録され、IANAが権威ある変更を保守対象モジュールへ反映する。IANA YANG Parametersには版付きの .yang ファイルと保守情報が並ぶ。モジュールはレジストリを映す側である。

RFC 9907は、公式文書に残りがちな危険なコピーも避ける。Internet-Draftの審査中は生成スクリプトと初期モジュール全文を添えてよい。しかしRFC公開前には、著者がRFC Editorへ初期モジュール付録の削除を依頼しなければならない。公開文書はそれが初版にすぎず、権威ある版はIANAから得ると示す。永久保存されるRFC内のコピーが、見た目の公式性だけで「現行版」に化けるのを防ぐ設計だ。

IANAから取得する場合も、証拠の種類を選ぶ。「latest」のURLは今の投影を取りに行く入口であり、版指定URLは過去の特定成果物を再現する入口だ。可変URLやファイル名だけでは、ある実行が何を読んだか確定できない。取得時刻、レジストリのスナップショット、モジュールrevision、URL、内容ハッシュを一緒に残して初めて、後日同じ判断をたどれる。

検証は依然として必須である。RFC 9907はモジュール検証を求め、pyang --ietfなどを例示する。YANG 1.1が言語規則を与える。ただし合格が証明するのは、特定ツール版・オプション・依存モジュールの下で、その入力が実行された検査を満たしたことだ。入力が最新か、対象サーバーが同じスキーマを持つかまでは証明しない。

サーバー側には別の観測面がある。RFC 8525のYANG Libraryは、モジュールセット、feature、deviation、データストアのスキーマを通知する。ライブラリ情報が変わるたび content-id も変わる。したがって、ローカル検証済みバンドルとサーバーが広告する集合を照合する工程は独立した統制になる。

さらに、スキーマと稼働状態も同じではない。RFC 8342はintendedとoperationalなどのデータストア像を分ける。NETCONFとRESTCONFはモデル化データへの操作とエラーを定める。要求が受理されても運用状態への反映は別問題であり、反映されてもサービス目標の達成は別に観測すべきだ。

実務の証拠束には、時刻付きレジストリ像、IANAモジュールのrevision・URL・ハッシュ、必要なら生成来歴、検証器版・オプション・依存集合、サーバーのモジュールセットと content-id、具体的操作と応答、前後のデータストア像、ロールバック状態、サービス試験を結ぶ。これは複数RFCの境界から導いた編集上の設計で、一つのRFCが指定する統一様式ではない。

Heng Luの最小初期仕様は共通層を薄く保ち、実装選択を責任ある現場へ残す。動くコードの優先は観測した層を超えて結論を膨らませない。現実のレイヤーはレジストリ、ファイル、検証、データストア、サービスを一個の緑ランプに畳まない。これらは明示した編集上の視点であり、IETFの追加要件ではない。

証明範囲を狭くすることは自動化を遅くしない。どの層が何を決め、何を運び、何を検査し、何を実行したかを追えるようにする。それが監査可能な速度である。

Sources