要約

  • RFC 6020は、レジストリにあるすべてのモジュール名、サブモジュール名、XML名前空間を一意にするという文言を置いていた。しかしRFC 9890第3節は、その文言が改訂版についてのIANAの実際の運用とは一致していなかったと説明する。
  • 更新後の規則では、モジュールとサブモジュールの初版の名前が一意であり続け、後続の改訂は初版と同じ名前を使う。初版のXML名前空間も一意であり、各改訂は初版の名前空間を維持する。
  • IANAはRFC 9890を追加の参照として掲げる。YANG Module Namesレジストリでの名前割り当てについて、その手続きが権威を持つからである。レジストリ識別子と、改訂を含む運用インベントリは同じ証拠ではない。

まず仕組みを見る：同じ名前でも同じ意味とは限らない

装置や管理システムから見ると、複数の改訂が同じモジュール名とXML名前空間を示すことがある。この継続性が守るのは初版登録の安定した識別であり、各改訂が別々の全世界一意名を持つという意味ではない。どの改訂を検証し、配備し、ロールバック用に保持したのかを答えるには、改訂情報と、当時のモジュール本文を再構成できるハッシュその他の明示的な証拠が必要になる。

RFC 6020の旧来の一意性文言は、すべての版について名前と名前空間の重複を禁じるようにも読める。RFC 9890は、改訂では初版の名前と名前空間を再利用するというIANAの既存実務を記録し、ポリシーをその実務に合わせる。名前を改訂番号へ変えることも、新たな管理操作を各実装に課すこともしていない。

IANAの権威性の範囲

ここでの権威性は、登録名を割り当てる手続きについてのものだ。IANAの登録表は初版モジュールまたはサブモジュールの名前と名前空間を記録し、RFC 9890を追加参照として示す。凍結したスナップショットが証明するのは観測時点のレジストリ状態だけであり、特定の改訂の実装品質、採用状況、ツール互換性、意味的正しさを証明しない。配備側の版管理の代わりにもならない。

登録識別子と改訂対応インベントリ

次はTheo Marchの分析であり、RFCの要件ではない。安定した名前をそのまま互換性の証明として扱うと、識別の曖昧さが生じる。名前だけでschemaをキャッシュする自動化は、まだ検証していない改訂を既知の入力として扱い、自動化ドリフトを招く可能性がある。ロールバック記録が名前と名前空間だけなら、後からどの意味的版へ戻したかも証明できない。名前、名前空間、改訂日または同等の版識別子、入手元、ハッシュ、検証結果、配備時刻を一つの改訂対応レコードに束ねるのが、分析上の堅実な境界である。

再現可能な検証フィクスチャ

以下は運用上の検証フィクスチャの例であり、RFCが追加した要件ではない。

  1. 同じ初版名とXML名前空間を持つ二つの連続改訂を用意し、本文とSHA-256を個別に保存する。レジストリ上の識別が同じでも、インベントリが二つを区別できることを確認する。
  2. 検証器にはモジュール名だけでなく改訂識別子とハッシュを入力し、入力、結果、ツール版、時刻を記録する。
  3. 配備シミュレーションで二つのファイルを意図的に入れ替え、改訂またはハッシュの不一致を拒否できるか確認する。ロールバックでは対象ファイルを記録から一意に再取得する。
  4. 凍結IANAスナップショットと現在の照会結果を分け、観測時刻を付ける。スナップショットを実装正しさの証拠にしない。

証拠集合から導けないことも明確にしておく。全改訂で名前の全世界一意性を想定したツールがどれだけあるかは測定されていない。運用事故、相互運用失敗、移行コストは確認されていない。RFCは連続する改訂の意味的互換性を検証しない。凍結スナップショットは観測後に変わり得る。ベンダーの対応状況と配備普及率も対象外である。

出典