要約

  • RFC 9890 は YANG モジュールとサブモジュールの初版名を一意にし、その後の改訂には同じ名前を要求する。モジュール改訂は初版の XML 名前空間も維持する。
  • 安定した組は出版上の系譜を示すが、同一バイト列、サーバーが実装する版、feature、deviation、設定反映、運用結果までは示さない。

監査表の二列は完全に一致していた。モジュール名も namespace も旧環境と新環境で変わらない。担当者は安心し、「変更なし」の欄に印を付けた。

変わらなかったのは系譜の鍵である。中身まで同じとは限らない。新しい revision はノードや制約を異なる形で持ち得る。別の装置は古い版を実装し、ある装置は同名モジュールを import-only として置くこともある。二つの文字列だけでは、その差を観測できない。

RFC 9890 は RFC 6020 の登録文言を実務に合わせる。旧文は IANA レジストリ内のすべてのモジュール名、サブモジュール名、XML 名前空間を一意とした。改訂行まで個別の対象と読めば、同じモジュールの新版が同じ名を使う正常な慣行と衝突する。

新しい規則は一意性の単位を明記する。初版のモジュール名とサブモジュール名は一意でなければならない。初版モジュールの XML 名前空間も一意である。その後のモジュールとサブモジュールの revision は初版の名前を保ち、モジュール revision は初版の名前空間も保つ。

別のモジュールによる名前の横取りを認めたわけではない。最初の登録が一つの系譜に長期の鍵を割り当てる。改訂はその系譜の成員であるため鍵を再利用する。

IANA の YANG Module Names レジストリでは、ietf-yang-types のような名前が日付の異なるファイルとともに複数回現れる。これは重複事故ではない。安定した入口から各 revision を取り出せるようにした履歴である。

名前はハッシュではない

モジュール名は系譜を選ぶ。XML 名前空間は XML ノードを修飾する。revision date は宣言された版を選ぶ。取得したファイルのバイト列が、実際に読んだ定義を確定する。四つは似て見えても代替できない。

名前だけの重複検査は正しい revision を拒み得る。名前だけの変更検査は本物の差を隠し得る。RFC 9890 はレジストリ側の前者を解く。後者は運用台帳が revision と source を保持して初めて解ける。

RFC 7950 の import は revision-date で対象版を指定できる。省略した場合、どの revision から定義を取るかは未定義である。異なる prefix を使えば同じモジュールの複数 revision を import することもできる。モジュール名だけの依存関係表からはビルドを再現できない。

記録すべきなのは revision statement、取得 URL、バイトハッシュ、import 元、版の制約である。固定されていない依存をツールが解決したなら、ツール版、利用可能だった集合、選択ファイルも残す。後日の成功は同じ意味を使った証拠にならない。

レジストリはサーバーを見ていない

RFC 9890 は IANA の手続きを更新し、新しい操作要件や管理要件は導入しないと明記する。登録行は名前の割当と revision の帰属を示すが、ルーターやコントローラーの実装を観測しない。

特定サーバーの宣言は RFC 8525 の YANG Library にある。module-set、schema、datastore に加え、revision、対応 feature、deviation、implemented か import-only かを報告できる。IANA と同名であることは照合の始点にすぎない。

content-id は特定サーバー上の現在のライブラリ情報を表し、情報が変われば変わらなければならない。世界共通のハッシュではなく、同じ内容から同じ値を作る義務もない。証拠としては、一回の取得を一つのサーバー状態に結び付ける。

一台のサーバーが実装する同名モジュールは datastore 全体で一 revision だが、import 用には複数 revision があり得る。「存在する」という報告だけでは、実装、依存、公開登録のどれかを区別できない。

スキーマの後にも現実がある

RFC 8342 の datastore schema は、対応モジュールに feature と deviation を適用したノード集合である。同じ revision を持つ二台でも、有効スキーマが同じとは限らない。

さらに <running> の値は変換を受けて <intended> になる。Intended はシステムが適用しようとする設定である。Operational は適用済み設定とシステム状態を組み合わせる。ハードウェア、隣接プロトコル、他装置、伝播時間が差を生む。

証拠は順序を保つ必要がある。IANA は出版系譜、revision とハッシュは読んだ source、YANG Library はそのサーバーの選択、datastore は意図と適用、サービス観測は結果を示す。

有効な登録は conformance 証明ではない。最新 library は設定の適用証明ではない。operational の一致も業務結果を自動的に保証しない。

最初の名前は戻しにくい

RFC 9907 は、公開済みモジュール名を、その RFC が Historic になっても再利用してはならないとする。名前を変えれば新しいモジュールである。公開内容を更新するときは固有の日付を持つ revision を追加し、以前の公開 revision を残す。

この永続性は import、ツール、文書を安定させる。一方、曖昧な初期名や不適切な namespace を後で安価に回収することはできない。最初の登録は技術だけでなく長期ガバナンスの判断である。

IANA は台帳を守り、著者は内容を定義し、実装者は対応を選び、運用者は展開と rollback を担う。自動化の所有者は、どの証拠で行動するかを決める。一つの「YANG 対応」表示にまとめると権限境界が消える。

名前は同じだった。それは系譜が同じだからである。モジュールは変わっていた。それは revision が系譜を前へ進めるからである。

出典