要約

  • RFC 9911は2025年12月のIETF Proposed Standardであり、ietf-yang-types と ietf-inet-types を改訂し、RFC 6991を廃止する。
  • モジュール名と名前空間は変わらないが、リビジョンは受理できる値、正規形、pattern、説明を変え得る。名前空間の一致だけでは互換性を証明できない。
  • 導入前に、実際に使われるリビジョンを棚卸しし、代表的なデータストア値とシリアライザー出力を複数実装で再生する必要がある。

仕組み：識別子は安定しても契約は固定されない

YANGのimportでは、チームがモジュール名を固定的な契約として扱いがちだ。しかし、リビジョン声明は別の境界を示す。同じモジュール識別子が新しいリビジョン日付を公開できるため、依存モデルのimport名を変更しなくても、typedefの値空間、pattern、正規化表現、説明文を引き継ぐことになる。したがって、名前空間の連続性が意味論的互換性を保証するわけではなく、RFC 6991の値がすべて無効になるわけでもない。

RFC 9911は二つの共通モジュールに、日付・時刻、duration、言語タグ、プロトコル番号、リンクローカルアドレス、アドレスとプレフィックス、ホスト名、メールアドレスなどの型を追加する。また、yang-identifier をYANG 1.1（RFC 7950）に合わせ、複数のpatternとdescriptionを訂正・改善する。文書だけを比較するツールには小さな差に見えても、サーバー、クライアント、構成データベース、コード生成器では検証結果や相互運用性の差になる可能性がある。

時刻型は特に試験対象にすべきだ。RFC 9557を取り込んだ date-and-time の意味では、Z と +00:00 はどちらもUTCを表す。しかし、Z はUTCを表す一方、+00:00 はUTCをローカルな基準点として明示する。両方を常に同じ文字列へ畳み込むパーサーは入力の意味を失う可能性があり、表示を変更するシリアライザーは署名、キャッシュ、比較、監査に差を生む可能性がある。これは特定実装が必ず誤るという主張ではない。アプリケーションが瞬時値、元の字句表現、または両方のどれを保存するのかを決める必要がある、という話だ。

アドレスとホスト名の変更も、単純なパッチ更新として扱えない。新しいlink-local、address-and-prefix、host-name、email-addressの型は、旧来受理された文字列の再確認を必要にすることもあれば、以前は拒否された入力をより明確に表現できるようにすることもある。RFC 9911は一部の型について、SMIv2 textual conventionとの同値・非同値も明示する。SNMP、YANG、変換ツール間の対応を型名だけから推測してはいけない。

移行面はどこに現れるか

影響はコンパイル時だけではない。サーバーの起動時に別リビジョンが選ばれ、保存済みの値が再ロード、編集、エクスポート時に再検証されることがある。NETCONF、RESTCONF、生成クライアントが異なる正規化規則を使うこともある。一つの実装が読めた値を別の実装が同じ字句で受理するとは限らない。あるserializerが +00:00 を出力しても、すべての利用者が Z と完全に同じ入力として扱うとは限らない。

これは普遍的な採用を宣言するものでも、一律の非互換を主張するものでもない。リビジョンを固定したクライアント、影響を受けないtypedefだけを使うモデル、変更されない保存データではリスクが低い可能性がある。どのサーバーが2025年リビジョンを採用したか、クライアントがリビジョンを固定しているか、どの既存値が新patternで失敗するかは、まだ個別に確認すべき未知数である。

出典